Mathew J. Schwartz
Password Police Cite Evernote Mistakes
More evidence of that fact came to light this week with the announcement from online note-taking service Evernote that attackers had breached its systems and stolen email addresses, usernames, as well as hashed and salted versions of customers' passwords. As a result, the company opted to proactively reset all 50 million users' passwords, and apparently did so before attackers were able to use the stolen data to access any accounts. Furthermore, Evernote says it will accelerate plans to offer users optional two-factor authentication.
- Emerging Security Trends and Risks. Insights for the Security Executive
- A successful SAST tool implementation
Those may be strong measures, but then time wasn't on Evernote's side. Notably, Evernote used the MD5 cryptographic algorithm to secure its passwords, despite numerous security experts saying that MD5 isn't fit for that purpose -- no matter how well it might be salted. That's because MD5 is a cryptographic hash designed for quick data verification, which makes it child's play for an attacker to compromise through brute-force guessing. "When you can do five billion [guesses] per second on one GPU [graphics processing unit], the salting doesn't make that much of a difference," Adam Caudill, a security consultant and software developer, told Ars Technica. "You need something else, something like bcrypt, scrypt, or PBKDF2 to slow things down so you can't do 5 billion [guesses] per second."
Caudill's reference to password hashing refers to the fact that websites don't store encrypted copies of passwords. Instead, they need to run the password -- after adding random data called a salt -- through a one-way cryptographic password hashing algorithm that produces a hash value, which gets stored. The original copy of the password is then discarded. Whenever a user later enters their password into a website or application, the input gets run through the password hash, and the resulting hash is compared to what's been stored. If they match, it means the password entered by the user is legit.
When Evernote CTO Dave Engberg was presented with criticism in 2011 that using MD5 wasn't a secure way to handle passwords, in response to a blog he'd posted about Evernote's security architecture, Engberg disagreed, saying that "we salt the passwords with a large random value, but the MD5 flaws aren't really relevant to internal password storage," and noting that "the hashed password is never exposed outside of our data center." Except, of course, if attackers breach Evernote's website or database and steal them. At that point, MD5-hashed passwords are trivially easy to crack.
Cryptography may be sexy, but password security too often remains an abstract concept -- until it's too late. As Mozilla software engineer and architect Ben Adida noted on Twitter, "Evernote story is critically important in one respect: security doesn't matter until all of a sudden it does, and then it *really* matters." Indeed, once attackers come calling, any password-implementation failure can facilitate a complete password-security compromise.
More confirmation that password security is routinely mishandled abounds. In June 2012, for example, both LinkedIn and Last.fm disclosed breaches in which attackers obtained their users' passwords, which the sites hashed using SHA1 and no salt. In the case of LinkedIn, of the 6.5 million password hashes obtained by attackers, they'd reported being able to quickly crack 163,267 of them, and were hard at work on the rest.
In January 2012, meanwhile, Zappos warned its 24 million customers to reset their passwords, warning that their personal details and account information, including passwords, had likely been stolen by attackers. But the company said the passwords had been stored "cryptographically scrambled" -- a phrase that security experts dismissed as marketing-speak. A Zappos spokeswoman, however, declined to specify exactly how the passwords had been secured.
"Nobody gets this right," password expert Thomas H. Ptacek, a security researcher with Matasano Security, told security reporter Brian Krebs last year. "I think it's a problem of generalist developers writing password storage systems. They may be good developers, but they're almost never security domain specialists."
What's the problem? "In LinkedIn's case, and with many other sites, the problem is they're using the wrong kind of algorithm," Ptacek said. "They use a cryptographic hash, when they need to use a password hash." Cryptographic hashes are designed to secure environments in which data must move at ultra-fast speeds, for example with IPsec, which encrypts individual packets. In those situations, latency isn't tolerable.
But when it comes to password security, some latency -- even if only measured in milliseconds -- is acceptable, because it means that even if it slightly slows a website's password-verification process for users, it can completely deny an attacker's attempt to decrypt stolen passwords.
"For data integrity, fast algorithms are preferred to allow quick verification," said security architect Brian Keefer (aka Chort) via email. "For password storage there needs to be [a] defense against offline cracking, which means the algorithm needs to be slow."
For attackers, "if you make a password hash take longer, that's murder on them," Ptacek said.