I like to focus on the positive. But every once in a while a security implementation so far from “best practices” occurs that I can’t resist the urge to comment.
Lifeboat is a Minecraft community with millions of users. It provides custom multiplayer environments for Minecraft gamers. This April, over seven million of those gamers had email addresses and hashed account passwords leaked.
It’s not unusual for a password database to be leaked, which is exactly why they should be designed to be “leak proof”. Decent password storage implementations are designed so that the passwords can’t be read even if the password database leaks. The LastPass database leak from a year ago is a perfect example. LastPass’ servers were breached and the password database leaked, but because they were stored properly, there is almost no chance that the attacker discovered the passwords from the hashes in the database.
Lifeboat’s security implementation was not of that standard. In fact, the only way it could have been worse is if the passwords had been stored in plaintext.
Let’s take a look at where Lifeboat went wrong.
Recommending Short Passwords
As reported by Ars Technica, Lifeboat’s documentation recommended users choose “short but difficult to guess” passwords. While short passwords can be more or less difficult to guess — “loveyou” is easier than “fa!uw$” because the former is in the password dictionaries used by hackers — any short password is likely to fall quickly to a brute force attack.
Using MD5 Hashes
The MD5 hash algorithm still has respectable applications, but hashing passwords is not one of them. MD5 was designed to be fast to compute, which means it’s also fast to reverse. In fact, most of the recommended short passwords are in rainbow or lookup tables so the attacker wouldn’t have to compute the password from the hash. In many cases, they can just Google the hash to find the associated passwords.
Not Salting The Passwords
Salting is the appending of a random string to a password before it’s hashed. Lookup and rainbow tables work because the same password always produces the same hash. If app developers add a random string to each password, attackers can’t simply look up the hash and discover the matching password.
Failing To Notify Users Of The Breach
When the breach was discovered, Lifeboat implemented a password reset (although some users say that didn’t happen). However, they failed to inform users of the breach. Keeping security breaches secret for a short period might be reasonable — it gives a service time to make security improvements without having to deal with a deluge of copycat attacks. But not divulging a breach for months is unconscionable. Users need to know if their passwords and email addresses are public knowledge.
Lifeboat is just one service, but as anyone in the security world knows, there are probably thousands more that haven’t updated their password storage implementations to reflect modern best practices. If your web app does any of the things we’ve discussed here, it’s time to make some changes.