If you haven’t hard by now Evernote was popped over the weekend. Information that the attackers may have had access to included usernames, email addresses, and hashed passwords. At the time we weren’t really sure of the hashing algorithm used however Evernote did disclose they were at least salted. Then this morning we noticed a tweet from @troyhunt pointing to a 2011 Evernote blog post by Dave Engberg describing their architecture and mentioning the use of MD5. Here’s the offending section.
UserStore: While the vast majority of all data is stored within the single-tier NoteStore shards, they all share a single master “UserStore” account database (also MySQL) with a small amount of information about each account, such as: username, MD5 password, and user shard ID. This database is small enough to fit in RAM, but we maintain high redundancy with the same combination of RAID mirroring, DRBD replication to a secondary, and nightly backups.
In the comments of this post there are some complaints about using MD5 and instead suggesting SHA-1 or SHA-2. Dave responded essentially saying it doesn’t matter since the hashes are never exposed outside of their datacenter.
Since the hashed password is never exposed outside of our data center, we don’t think that the differences between MD5 and SHA-1 are relevant. I.e. the risks for MD5 are about producing two inputs that match the same output. In the case of a purely back-end MD5 hash, any hypothetical attacker doesn’t have access to either the output (the MD5 hash) or the original input (the user’s password and our salt), so there really isn’t any productive attack based on MD5 vulnerabilities.
He makes a good point however unfortunately the base of his argument is wrong about the password hashes never leaving their datacenter (e.g., the breach this past weekend). Of course Dave wrote this post almost two years ago and guidance has generally migrated from suggesting salted and hashed passwords to more appropriate password-based key derivation functions such as PBKDF2, SCrypt, or BCrypt.
Enter Dan “@dakami” Kaminsky … and the overnight Twitter discussion of whether Dave was actually right for using a plain old salted MD5 over the current suggested best practice of SCrypt or BCrypt.
@dakami: It’s actually bad security advice for websites to hash their passwords w/ bcrypt/scrypt. We forgot slow DoS. #
The basic theory is that because memory hard password-based key derivation algorithms like SCrypt and BCrypt require a lot of resources, an attacker can bring a site to it’s knees with a slow rate of incorrect password guesses. Administrators can counteract this attack, such as by rate limiting or captchas, but then you starting entering cat-and-mouse game territory. The real effect of this whole debate according to Dan boils down to:
@dakami: At the point where scrypt gets strong enough to really inconvenience brute forcers, it seems to help DoS’ers #
Just something interesting to start your week off…
Are the current best practice recommendations of using BCrypt or SCrypt wrong? Let us know in the comments below. Today’s post pic is from Time as Money. See ya!