Evernote Breach Promoting Salted MD5 Over SCrypt/BCrypt

“At the point where scrypt gets strong enough to really inconvenience brute forcers, it seems to help DoS’ers.” – Dan Kaminski

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!

4 comments for “Evernote Breach Promoting Salted MD5 Over SCrypt/BCrypt

  1. March 4, 2013 at 12:15 pm

    @pueblokc https://t.co/jSF7d2u1eb There’s this…

  2. March 4, 2013 at 12:52 pm

    Evernote Breach Promoting Salted MD5 Over SC… https://t.co/IXfIMm7Ilw

  3. March 4, 2013 at 3:47 pm

    There’s been huge arguments over that point going on now for probably over a year.

    My take is that site passwords should have a “secret salt” in addition to the salt used to compute the password stored in the password database. This “secret salt” should be stored on another server than the one holding the password database. should only be stored in memory of that server and used solely for computing the eventual hash by a compiled executable running on that server, and that server should have no other connection to anything except the server requesting the password hash.

    This means that if the database server is hacked and the database downloaded, they only get the hashes which cannot be cracked with any known salt because there’s an entirely different salt added to the mix on a server which is less easily accessed. At the very least, the hackers now have to both access a second server, and search that server’s memory for the (possibly encrypted until used by the password executable) secret salt in order to have ANY chance of cracking the password database.

    With this system, one can use faster (and less secure) hashing algorithms such as the SHA’s and still maximize security.

    Yes, it’s more complicated and complication is frequently the enemy of security. But sometimes it’s not. The goal here is to not just make the Web site designer’s life complicated but also the hacker’s.

  4. March 4, 2013 at 4:02 pm

    Richard: Yeah, I seem to recall discussions of this several months ago but this is the first time I remember someone saying that SCrypt, BCrypt, and the like are “less secure” (whatever that really means) than something like salted MD5s or SHA-1/2s. Anyway, your suggestions will definitely raise the bar but it just doesn’t seem as eloquent as the classical approach of having an open system with the only the password being unknown.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.