Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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!
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8720
PUBLISHED: 2020-08-13
Buffer overflow in a subsystem for some Intel(R) Server Boards, Server Systems and Compute Modules before version 1.59 may allow a privileged user to potentially enable denial of service via local access.
CVE-2020-12300
PUBLISHED: 2020-08-13
Uninitialized pointer in BIOS firmware for Intel(R) Server Board Families S2600CW, S2600KP, S2600TP, and S2600WT may allow a privileged user to potentially enable escalation of privilege via local access.
CVE-2020-12301
PUBLISHED: 2020-08-13
Improper initialization in BIOS firmware for Intel(R) Server Board Families S2600ST, S2600BP and S2600WF may allow a privileged user to potentially enable escalation of privilege via local access.
CVE-2020-7307
PUBLISHED: 2020-08-13
Unprotected Storage of Credentials vulnerability in McAfee Data Loss Prevention (DLP) for Mac prior to 11.5.2 allows local users to gain access to the RiskDB username and password via unprotected log files containing plain text credentials.
CVE-2020-8679
PUBLISHED: 2020-08-13
Out-of-bounds write in Kernel Mode Driver for some Intel(R) Graphics Drivers before version 26.20.100.7755 may allow an authenticated user to potentially enable denial of service via local access.