Believe it or not there are still companies emailing users with plaintext passwords. Worse yet, some systems are storing plaintext passwords in the database. Storing or emailing plaintext passwords can increase security vulnerabilities by as much as 10x.
CU Boulder, a premier university, still emails their passwords in plaintext. Regardless of how complex a password is, if it is stored or emailed in plaintext, that password is easily accessible to anyone and security is compromised at a glance.
Bottom line. Do not store or email your passwords in plaintext. It’s a horrible idea. Here’s why:
Storing plaintext passwords
- If the database is compromised, the hacker now has access to everyone’s password. That means people who use the same password across sites are in jeopardy of having their bank accounts drained or their identities stolen.
- If there are vulnerabilities that would allow SQL injection, hackers don’t even need access to the database server to get passwords.
- Database backups are also vulnerable. A hacker can now attack a backup server and get access to passwords.
Emailing plaintext passwords
- Emails can be forwarded accidentally. This could mean a password might be leaked by a user that mistakenly forwards the email to their team or the whole company.
- Some email servers aren’t secure. Emails are stored plaintext on most email servers, so if a hacker gets access to the server, they can just run a script against the email database and find plaintext passwords.
- Emails aren’t always encrypted on the wire (when they are sent from your computer to the SMTP server or between SMTP relays). A simple packet sniffer can intercept emails and be trained to look for plaintext passwords. If you are sending emails from a hosting provider that supports multiple companies (like AWS or Rackspace), a hacker can put a packet sniffer on the same network and read your emails.
- Emails aren’t a direct communication. Emails bounce between servers on their way from your outbox to someone’s inbox. Emails are rarely encrypted and therefore might be intercepted as they bounce around and are easily readable by a machine.
- Strong encryptions. Passwords should always be hashed using a strong, one-way hash algorithm. In addition to using a hashing algorithm, you should also be salting the password and performing multiple hash passes. This will prevent brute force or lookup attacks on passwords. In the event that the user database is compromised, it will still be nearly impossible to reverse engineer a user password from the stored hash.
- Verification ID. Never email a plaintext password. If a user forgets or needs to change their password, send a link (with a random verification ID) that allows the user to securely change their password within a set time period. The company should never know the user’s password.
- Multi-factor authentication. If the above fail and the password has been compromised, using MFA or 2FA keeps the user account secure. Two-factor authentication enhances user login security by requiring something the user knows (password) with something the user possesses (their cellphone for example).
- Password invitations. If you are manually creating user accounts and need users to set their own passwords, avoid sending a random or temporary password via email. Instead send the user an email or push notification allowing them to set the password themselves.
Inversoft is a security company, focusing on identity and user management. Our product, Passport ships with code based 2FA, brute force login detection, password hashing, forgot password, email templates and more. See our free Guide to User Data Security for more suggestions on Password Security.
Recently, I was working with a customer that had a URL slip through CleanSpeak’s URL filter. The URL looked something like this:
The trick this user employed to get around our URL filter was using the Unicode character “ 。”(code point 0x3002 or UTF-8 0xE38082). This character looks like a period but wasn’t in the list of valid URL separators that CleanSpeak handles.
My initial thought was to simply add the character to the list. That required me to look up the Unicode code point for it first. I then realized that there were a ton of other characters that also looked like periods. In order to properly handle this, I’d need to add all of them to the list. I also noticed that there were numerous other characters someone could use to trick the URL filter like arrows, pictures and symbols.
With the number of apps and mobile users projected to increase exponentially, developers who create the most advanced technology fastest will gain the competitive edge needed to stand out amongst competition.
The software industry is ever-changing. The field is highly dynamic, focused on building and changing the way we live, work and play. 2015 was a tumultuous year for developers.
IT was impacted by innovations from within as well as external factors, such as increased government regulations and cyber-crimes originating both in the U.S. and abroad.
I’ve been working to convert a bunch of our database columns from integers to UUIDs. I was having a hard time figuring out how to handle this conversion easily in PostgreSQL. For some reason, the PostgreSQL developers decided that the int data type was not converted to UUID automatically. This is somewhat shocking because both of these data types are binary types with different lengths (int being 4 and UUID being 16),. Since I couldn’t submit a feature request and wait 2-3 years to have it implemented, I had to find a solution that worked in an SQL script easily.
After some playing around and hacking in sql, I figured out the solution. Here’s a little snippet of my solution:
CREATE TABLE foo (
ALTER TABLE foo ADD COLUMN new_id UUID NULL;
UPDATE foo SET new_id = CAST(LPAD(TO_HEX(id), 32, '0') AS UUID);
ALTER TABLE foo DROP COLUMN id;
ALTER TABLE foo RENAME COLUMN new_id TO id;
ALTER TABLE foo ALTER COLUMN id SET NOT NULL;
The trick here is you need to convert the integer column to a hexadecimal string and then pad it with zeros. Since PostgreSQL happy converts strings to UUIDs, you can just cast the string to a UUID. Simple!
New Zealand recently enacted a bill that will make cyber-bullying illegal and punishable for the bully and the company that hosts the application used for the bullying.
Though there were a few legislators that voted against the bill, the vote was an overwhelming 116 to 5.
Opponents believe that this will impact free speech and that determining if specific user-generated content is in fact cyber-bullying could be difficult or impossible.
From my perspective, I don’t feel this bill impacts free speech. It is similarly illegal to harass or threaten someone in person, so why should it be any different online?
Furthermore, identifying user-generated content that is cyber-bullying shouldn’t be overly difficult. If someone feels cyber-bullied and reports the issue, that should be enough to investigate. Likewise, companies can also use automated solutions like CleanSpeak to help get alerts when conversations look like they contain cyber-bullying. Companies can let moderators make the final judgement and remove the content from their applications and/or kick the bully out as well.