A few days ago I had the pleasure of attending a local “digital creative” meetup B&Wmeet. It’s held at the Slug and Lettuce, a national pub chain in the UK. A number of us wanted food before the event, and I noticed an offer on their website of 25% off food if you sign up for an account. Money off food for a student always sounds like a good idea, so I signed up. Next thing I know, I have an email in my inbox… with my password in plain text. This resulted in an unhappy and slightly angry Ben.
UPDATE: We heard back from Aardvark Media “The Slug and Lettuce website does not store your password in plain text. At time of account creation, we send a one-time email with the plain-text password, as we’ve found sites that do this see a marked drop in the number of users of any “Forgotten password” facility they provide.” Well that’s a relief! For the full response, see the comments section below.
Anyone who works in web development (should) know about security issues when it comes to storing data—especially passwords! One of the simplest security errors is storing users’ passwords in plain text. That’s just stupid. Why would you store passwords in plain text? Plenty of Fish do, and as dspillett from hackernews puts it “My opinion? PoF stores password in plain text because it is an unprofessional outfit with no care for the security of its users or their data.” Storing a password in a retrievable encrypted format doesn’t cut it, either; it only takes one rogue or unhappy employee or your database stolen, and your passwords could be at risk.
Let’s admit it: the main problem here is password reuse. If you use a different password for every account you log into, having one password stolen (from the system with the weak link) will (hopefully) only result in a few random forum postings. If you have the same password to your bank account that you do for a random forum your friend made on a weekend, chances are your password is just waiting to be stolen, along with your money. Here is a comic from xkcd about password reuse.
Regardless of the reuse issue, when a website or webapp is storing your details, they have a level of responsibility to make sure it’s kept safe. If a website includes its own very clever way to store passwords, it’s probably broken and not very safe at all. Using already existing libraries to handle password hash storage makes sense. These libraries are generally open-source reviewed by people who understand them. As the saying goes, “If it ain’t broke, don’t fix it.” What happens when it does break, though? Crackers will always try to find quicker and slicker ways of cracking, and rainbow tables did just that (assuming they stole your database of hashed passwords). In the past, using an MD5 or SHA1 hash with a salt was good enough not to be cracked within a reasonable time.
Luckily, some clever folks came up with bcrypt, an (effectively) adaptable hashing algorithm that can keep up with Moore’s Law. It uses Blowfish at its core and salts, but the main benefit of bcrypt over something like SHA512 is it was designed to be slow; it’s not really a hashing algorithm. Hashing algorithms are designed to digest a large amount of data and provide a string which can be compared with another to check for message integrity. They are fast by design. Some discussion over which is better still remains, but from what I can tell, bcrypt is going to be secure longer.
We’ve established you should be using trusted, well-used code for authentication, and I hope I’ve made it pretty clear that it’s not acceptable (but unprofessional) to send users their passwords in plain text via email! There are ALTERNATIVE ways to do the whole “Forgotten Password” thing. I was sent my password in plain text after sign-up. Why? I can only assume because someone thought that convenience was better than security. They were wrong. They are wrong. Very wrong. Wrong wrong wrong.
To make sure it’s not just my opinion that it’s bad, I asked a few people on Twitter if there was ever a valid reason. Here are a few responses…
The trouble is, Graham is right. There are, and probably always will be, a number of systems and websites out there that do it wrong and either can’t or won’t ever be upgraded. A way you can deal with this, is to use different passwords for every account, which are impossible to remember. Personally I use LastPass, which is a very secure way of storing your passwords, and making them accessible. If you want to know exactly how it works, check out this transcript from an episode of Security Now (A fantastic and recommended security podcast). The main point, is they never store your decryption key, and you only ever send them encrypted data, as encryption and decryption is done client side. Plus, it has a few really neat extra authentication methods for the super paranoid.
A final note on password strength: I’m sick if seeing password requirements of “must include upper and lower case, must include 3 numbers and 2 special characters.” No. It DOES make it more secure if you don’t handle brute force attempts by not locking accounts, but there is a BETTER way, which makes brute force even harder, as this xkcd comic shows…
The next time you are responsible for implementing the authentication element of a website, think. Remember this comic. Suggest to your users not to reuse passwords. Explain to them that you won’t be sending them their password in an email for THEIR protection. If you fail to do these things, you really aren’t helping the current state of username and password authentication.
Developed an authentication system before? Let us know how and why in the comments below.