Risk
3/7/2013
03:37 PM
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
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-1449
Published: 2014-12-25
The Maxthon Cloud Browser application before 4.1.6.2000 for Android allows remote attackers to spoof the address bar via crafted JavaScript code that uses the history API.

CVE-2014-2217
Published: 2014-12-25
Absolute path traversal vulnerability in the RadAsyncUpload control in the RadControls in Telerik UI for ASP.NET AJAX before Q3 2012 SP2 allows remote attackers to write to arbitrary files, and consequently execute arbitrary code, via a full pathname in the UploadID metadata value.

CVE-2014-3971
Published: 2014-12-25
The CmdAuthenticate::_authenticateX509 function in db/commands/authentication_commands.cpp in mongod in MongoDB 2.6.x before 2.6.2 allows remote attackers to cause a denial of service (daemon crash) by attempting authentication with an invalid X.509 client certificate.

CVE-2014-7193
Published: 2014-12-25
The Crumb plugin before 3.0.0 for Node.js does not properly restrict token access in situations where a hapi route handler has CORS enabled, which allows remote attackers to obtain sensitive information, and potentially obtain the ability to spoof requests to non-CORS routes, via a crafted web site ...

CVE-2014-7300
Published: 2014-12-25
GNOME Shell 3.14.x before 3.14.1, when the Screen Lock feature is used, does not limit the aggregate memory consumption of all active PrtSc requests, which allows physically proximate attackers to execute arbitrary commands on an unattended workstation by making many PrtSc requests and leveraging a ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.