Risk
3/7/2013
03:37 PM
Connect Directly
RSS
E-Mail
50%
50%

Password Police Cite Evernote Mistakes

Evernote used the wrong security method to store passwords, cryptography experts say. Unfortunately, it's a common error.

Anonymous: 10 Things We Have Learned In 2013
Anonymous: 10 Things We Have Learned In 2013
(click image for larger view and for slideshow)
Cryptography warning: Knowing how to secure passwords remains tough. Really tough. As in: Businesses should seek ultra-professional help whenever they approach password storage.

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.

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
macker490
50%
50%
macker490,
User Rank: Ninja
3/12/2013 | 1:14:32 PM
re: Password Police Cite Evernote Mistakes
ROFLMAO
real problem is hacker got into database in the first place. usually by SQL injection -- which -- by now -- is a beginner's mistake
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
3/8/2013 | 10:27:49 PM
re: Password Police Cite Evernote Mistakes
I hope that other companies are seeing Evernote's troubles and reviewing their own customer password security set-ups. It's probably a naive hope, but there it is.

Drew Conry-Murray
Editor, Network Computing
criticalthinker
50%
50%
criticalthinker,
User Rank: Apprentice
3/8/2013 | 10:06:16 PM
re: Password Police Cite Evernote Mistakes
That should be SOME websites don't store their passwords as encrypted, because mine sure does!
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2009-5142
Published: 2014-08-21
Cross-site scripting (XSS) vulnerability in timthumb.php in TimThumb 1.09 and earlier, as used in Mimbo Pro 2.3.1 and other products, allows remote attackers to inject arbitrary web script or HTML via the src parameter.

CVE-2010-5302
Published: 2014-08-21
Cross-site scripting (XSS) vulnerability in timthumb.php in TimThumb before 1.15 as of 20100908 (r88), as used in multiple products, allows remote attackers to inject arbitrary web script or HTML via the QUERY_STRING.

CVE-2010-5303
Published: 2014-08-21
Cross-site scripting (XSS) vulnerability in the displayError function in timthumb.php in TimThumb before 1.15 (r85), as used in multiple products, allows remote attackers to inject arbitrary web script or HTML via unspecified vectors related to $errorString.

CVE-2014-3562
Published: 2014-08-21
Red Hat Directory Server 8 and 389 Directory Server, when debugging is enabled, allows remote attackers to obtain sensitive replicated metadata by searching the directory.

CVE-2014-3577
Published: 2014-08-21
org.apache.http.conn.ssl.AbstractVerifier in Apache HttpComponents HttpClient before 4.3.5 and HttpAsyncClient before 4.0.2 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.