In Brief: Many Websites are Visibly Vulnerable

While I’ve discussed how absolute security is impossible, there’s a difference between building a secured website that may be breached by a concerted and resourceful effort and building a website that advertises potential attack vectors. Several websites are guilty of this and do things like email plaintext passwords or use unnecessarily restrictive password rules; these problems tend to make it much easier for an attacker to compromise user credentials.

For a more detailed look into the problem and ways to begin mitigating it, read on.

Raising Awareness: Plain Text Offenders

I discovered an excellent website the other day called Plain Text Offenders that catalogs websites caught storing passwords in plaintext. Websites like this deserve to be shamed because it’s a potentially serious security issue: look at the recent Yahoo account password breach that caused quite a stir; this attack was at least partially facilitated by username/password credentials collected from other websites that happened to be reused for Yahoo email accounts. Often when username/password combinations are seized from unsecured websites the attackers either reuse them for further attacks as was the case with Yahoo, sell them, or publish them publicly (this is trivially available through a search for ‘pastebin username password combinations’ and is an excerpt of releases from the 2012 Twitter password breach).

A website storing plaintext passwords is also likely to have weak security leading up to access to their database itself so these websites are potentially easy and lucrative targets for attackers. It’s like a bicycle thief: even if they have the means to break through a bike locked with both a U-lock and chain lock, if there’s another bike of similar value with just a rusty old chain lock why bother stealing the first one?

Know Your Hashing

For the following discussion I’m going to assume a basic working knowledge of what a cryptographic hash function is and its basic properties; the uninitiated might want to consult the Simple Wikipedia article; otherwise, I’ll try to give a brief rundown.

A cryptographic hash function is a way of converting some data — for our purposes this data will be a plaintext password — into a fixed-length string called the hash value. For instance, one of the older hash functions (which, for the record, should never be used for passwords) is called MD5, and MD5(“123456”)=e10adc3949ba59abbe56e057f20f883e. A hash function should have these properties:

1. It can be easily computed in less than a second (note: for passwords, faster isn’t better)
2. It is extremely difficult (computationally and ultimately financially expensive) to reverse engineer, or invert, the plaintext password from the hash value
3. It is extremely rare for two distinct inputs to give the same hash value (known as a collision)

When it was made in 1991 MD5 seemed like a fine hash function, but these days it’s very trivial to invert MD5 hashes and there are modern alternatives much more appropriate to current needs.

The Red Flags

Plain Text Offenders performs what I consider to be an important public service by calling out these websites that store passwords in plaintext. With a basic understanding of hashing in hand, let’s look into why this is an issue and also consider some other common practices that may be troublesome and at the very least merit vigilance.

Password Recovery Emails Containing Plaintext Password

This case is the focus of Plain Text Offenders. Some websites allow you to “recover” your password which results in receiving an email containing the plaintext password itself. If you registered with a password of “123456” then you receive that exact string in the email. There are two important issues with this.

First, if a website’s security is compromised then there’s nothing in the way of the attackers immediately commandeering every account. Keep in mind how there is no such thing as perfect security; given enough motivation and effort, any website will be able to be compromised. The likelihood of developers properly securing the website and then leaving passwords stored in plaintext is effectively zero; if you’re able to receive an email like this, be worried and do not share that password with any other accounts — delete the account if possible.

If passwords are even weakly hashed then attackers will have to expend some time and effort to determine the plaintext; if the website administrators happen to be on their toes and the breach is detected then this gives them time to reset passwords and notify their users. If passwords are properly strongly hashed then attackers may not be able to determine the plaintext at all unless they’re very well-funded, and even then it can take a very long time.

Second, email is inherently insecure as it’s an unencrypted form of communication susceptible to man-in-the-middle attacks. This is a less likely avenue of attack since it typically requires some sophistication; the NSA has been impersonating Google servers to do this for example, but “average” attackers are less likely to try.

Password Reset Emails Contain the New Password

Sometimes when you use a website’s password reset functionality this results in receiving an email containing the new password. This doesn’t necessarily mean that the website isn’t hashing this new password as they could have stored the hash value after sending the reset email, but that’s still a real concern.

Beyond this we return to the insecurity of email described in the previous paragraph: the new password can still be intercepted by a determined attacker. Last but not least this leaves a copy of your plaintext password in your email; if you leave your email open and leave the room and a physically-nearby attacker searches your email for “password” then suddenly they have your login credentials.

Registration Limits Password Length and/or Punctuation

It’s the norm for there to be some limits on the length and acceptable characters for a password; this is smart since it would be unwise to allow arbitrarily long form inputs with an uncertain character set that could cause problems with your system. However, the problem comes with overly restrictive limitations. The worst I’ve seen has been forcing passwords to be 6-12 characters and alphanumeric only (no punctuation or spaces). This is a very bad practice.

1. If repeated login attempts aren’t properly limited then a short upper limit makes brute force guessing of a password trivial
2. Restrictive limitations on length and accepted characters means that an attacker has far fewer possibilities to deal with when trying to determine the plaintext; if the website doesn’t use a hashing procedure that defeats brute force attacks then these passwords aren’t secure
3. Restricting punctuation brings into question whether the website is cleansing user input to prevent SQL injection attacks
4. Restrictions like this make one question how the website is storing passwords in the first place; some websites might restrict the length because they’re storing these passwords in plaintext in their database with a fixed-length storage type

While these problems are just speculative, they’re all possible inferences based on these restrictions and a malicious attacker will take this into account. I genuinely put on a wide smile when I encounter a website that allows a 100+ character password using any character on a standard QWERTY keyboard.

Conclusion: Education is Key

I can only imagine that the website administrators just aren’t aware of either the implications of their password storage practices or the ease of implementing a decent hashing algorithm. Plain Text Offenders has a section dedicated to praising former offenders who reformed their ways and secured user passwords. Contacting website administrators when you notice poor practices with a constructively written suggestion is a good way to help.