Hacker News Reader

Comment by jgrahamc | Hacker News Reader

Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.(http://en.wikipedia.org/wiki/Salt_(cryptography) ))

That's great. But to really reassure people they would do best to reveal the algorithm. After all, DES-based password hashes are both 'hashed and salted' but are easily broken with JtR.

View on HN

Curious, if the attacker knows what the encryption algorithm is, does it help them at all in breaking it? I.e., does it potentially delay breaking it by not revealing it?

In theory, yes, in practice it is fairly obvious how something is hashed just by eye. Different hash algorithms produce different output (lengths, starting character, and spread).

So with some experience you can often tell (or guess and test) what something is hashed with.

I would say that's not really true. The output hash will look the same if I apply a simple salted SHA-1 with a salt or if I apply 500 MD5's followed up followed up with 200 SHA-1's, each salted differently. I'm not a security expert, but I think this is closer to best practice these days.

That said, revealing the exact algorithm would basically be throwing people with weak passwords to the wolves while really only supplying the rest of us with a false sense of security (because it will probably be cracked anyway).

We'd also be better off if they didn't announce the algorithm if the passwords get leaked (like with LinkedIn).

For practice, see if you can't identify the hashing algorithm for the following stored passwords:

    $6$AhHvI8ay$I0ED2wWVU9eheJKvCxzcbc/ZYRoN60q5XNHruYp8yFlQvEOjJ1WtIHUwjG6L4ZGntf3ei8osB7s2GYdkN01gx1
    dGhpcyBpcyBzdHVwaWQKCg==
    286755fad04869ca523320acce0dc6a4
    some_salt:ac01346ad1553221506dd091800a1974
    c8fed00eb2e87f1cee8e90ebbe870c190ac3848c
    6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e
    /5L0cR/wpFqSA

Note how they don't look the same, so it's quite easy for an attacker to tell the difference.

Want to see how you did? Here's the answer key, in base64:

    MTogTW9kZXJuIGNyeXB0LCBsaWtlIHRoZSBraW5kIHlvdSdkIGZpbmQgaW4gL2V0Yy9zaGFkb3cK
    MjogSnVzdCBiYXNlNjRpbmcgdGhlIHJhdyBwYXNzd29yZCAoc3R1cGlkKQozOiBVbnNhbHRlZCBt
    ZDVzdW0KNDogbWQ1c3VtLCB3aXRoIHNhbHQgcHJlcGVuZGVkCjU6IFVuc2FsdGVkIHNoYTFzdW0K
    NjogVW5zYWx0ZWQgc2hhMjU2c3VtCjc6IE9sZCBVTklYIGNyeXB0KCk=

The definition of a symmetric cipher requires the cipher text to be (practically) indistinguishable from random. Length is not particularly useful (multiple blocks, different block ciphers with equal block length).

Lots of developers who read "Learn PHP in 24 Hours" and similar texts use md5 (32 chars) or sha1 (40 chars). If you're an attacker and see a hex string that's 40 chars long, that gives you a great place to start since you know it's likely to be a naïve SHA1 hash.

If Evernote is not using a key derivation function, I don't know what to say.

No, it's usually known by the format, or even stored together with the password

Example: crypt stored the password in the format: $id$salt$encrypted

But this is why we do one or both things: strip obvious things from hashed password and store them separately or add a trivial character reshuffling algorithm. The point is that hacker would not only have to steal your hashed passwords, but also steal and understand your code. Makes it more complicated.

The security of your system can never depend on an attacker not knowing the implementation.

Or: Security through obscurity (is no security)

Using gimmicks like for example shuffling some characters in the hash may delay some attacks. But the problem is that these techniques are usually done on systems that have no sufficient security.

Have a big salt and use PBKDF2 or Bcrypt and you know the exact difficulty of getting the passwords.

If you need a citable name, taking the transparency of the cryptosystem as an assumption is called Kerckhoffs's principle.

IMO, you should be doing both. People should use strong bcrypted passwords, with a salt, then ALSO a 'secret' pepper value (long value stored in app code). This adds additional security in the case of a db-only dump being released, and doesn't harm the strength or a full code+db release at all either.

Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but instead makes it another thing to figure out by an attacker. At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.

Security is about depth, not putting 100% of your trust in a single algorithm. Even if that algorithm is well trusted. It's simply not an either/or.

Indeed, the assumption is that attacker has limited window of opportunity to grab the data. Taking that as a base assumption, it would make sense two store parts of the hashed password in two separate databases on two separate machines. Hacker would have to gain access to both. My initial alternative was to add some trick inside of the code, like a simple shuffling of characters. Assuming that code is not stored on the same machine as DB that should increase security considerably. But either concept would work. Of course it does not remove the need for higher degree of difficulty for hashing itself.

With publicly creatable accounts by the potential hacker, a pepper is just another password.

Leaving identifiable bits in the hash makes it easier to do things like

if pass_type ($1$) { on_logon $upgrade_to_pass_type$6$)

> At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.

If you ever know at all.

Better to use 'not fast' hashes like bcrypt, scrypt, or PB(something) that requires far more work and far slower cracking.

Re pepper: It's a STRONG password. It turns '12345' into 64 random characters + '12345'. Meaning that you can't brute force against a dictionary, unless you have that pepper value. Which is only stored on the production system. This turns a well-known attack vector of "developer loses a data dump" into something that won't expose passwords.

Re hash: yeah, use a strong hash function. Never advocated otherwise.

Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.

Let me try to explain this better

Suppose you're doing the byte shuffling right? Or you split the hash value in two and you concatenate them in the reverse order, something like that.

Now here's the thing: if you have a determined attacker, they will figure out your code does that. So you gain no extra security from it

For a casual attacker this may be a bigger deterrent. Now, this casual attacker may try to create (or already has) an account, for which the password is known. So he goes and compares it trying to figure out your encryption mechanism

It's slightly more difficult than the guy that just used MD5 to hash the passwords (let's assume that's the minimum security people use - "in theory")

So, it's all fine and dandy until you have another 'increase the security' idea that actually decreases the security. And this is more common than you think.

Example: taking the hash and encrypting it (for some choices of hash and encryption)

(Not to mention when people think that because they use this 'improved security scheme' that they invented they can be lax in security elsewhere in the chain)

You're right. Throwing shit at the wall can screw things up, and you must still be using a proper full-strength hash, and not just throw crypto primitives at it.

What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach.

What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump.

So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'.

And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem.

That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production.

So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.

Using a big salt is essentially the same as using a secret character shuffling algorithm. The difference is that the salt value is thought to be on the 'data side' and not in the code side, so it's allowed to be secret. The distinction is pretty arbitrary, though.

If someone can steal your passwords, doesn't it follow that they'd more than likely also have stolen your code?

For public service like Evernote attacker can usually create own accounts with known passwords before stealing database and then try to found algorithm and salt by brute force hashes against known password.

It's MD5 with a salt.

"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.

Of course, if someone has your original password and our salt, they might be able to come up with a SECOND synthetic password that hashes to the same value. (Since we constrain password characters that we accept, that might not be possible, but let’s assume it is…) The attacker could theoretically use this second password to access your account. But that same attacker could just use your original password, so I don’t see a real-world attack that would be improved with SHA1.

(Before Evernote, I spent five years building high-end cryptographic systems for government customers [e.g. http://www.isto.org/ose-site/file-fix/Public/corestreet-secu..., so I get to make use of my old crypto knowledge from time to time…)"

http://blog.evernote.com/tech/2011/05/17/architectural-diges...

Agreed, it would be nice to know they are using something reasonable, like bcrypt.

Their description would satisfied by a simple MD5 + salt, which wouldn't be very good for password storage.

From the Evernote support pages:

What type of encryption does Evernote Use?

If you encrypt text within a note, we derive a 64-bit RC2 key from your passphrase and use this to encrypt the text. This is the longest symmetric key length permitted by US Export restrictions without going through a complex process to gain export approval.

We do not receive any copy of the key or your passphrase, or any escrow mechanism to recover your encrypted data. I.e., if you forget your passphrase, we can't recover your data.

User authentication (i.e. username + password) is always performed over SSL when you communicate with Evernote. This uses 1024-2048 bit RSA keys and a symmetric session key that's negotiated between your client/browser and our server.

The data in user notes is also transferred via SSL.

Several of the company's founders come from a strong encryption background (founders of CoreStreet, recently acquired by ActiveIdentity). For Evernote's consumer product, the current encryption algorithms are chosen more for exportability under the Commerce Department rather than strength, since our software permits the encryption of arbitrary user data with no escrow.

We'd be interested in offering something stronger in the future when we have the staffing to fight the lengthy export battle, but Premium users can currently use an external encryption solution to encrypt important files and then add these encrypted into Evernote.

That still doesn't tell you how the password is hashed though.

Can anyone tell me why they're using RC2 and not AES? Does the export restriction even disallow that? Seems a bit disingenuous if that is the case.

Your average user has no idea what a hash nor a salt is. There's really no reason for them to include their hashing algorithm in an email like that.

Technology-savvy users want to be informed and assured as well. Why would they not include it?

Situations like these specifically call for not leaving things up to the users' imagination.

The recent Facebook incident (well, one of them) created a big scare. Better to control the narrative, before others decide to tell their version of the story.

Where 'their version' == some made up bullshit that sounds good.

Also the email doesn't talk about the time-frame: when exactly did Evernote discover this activity and how long might they have been compromised for.

It doesn't really matter what they used, as hashing speeds improve so quickly. You have to assume that the password you were using on evernote will be cracked, so to be safe you have to change it everywhere you were using it. Given that most people reuse passwords i expect a lot of follow-on exploiting of other systems with the passwords retrieved from evernote.

IANASE (I am not a security expert): Would the following service work:

Assume a central account/profile service. This service would allow you to have a single login to this service, with a directory of pretty much any/all sites and services online.

The external services would receive a hashed token of your account/authorization. They would check for the validity of the token each [interval|day|time-the-service-was-accessed] to determine if the token/auth is still valid.

They would also be able to tell the central service whether or not they require an updated token/auth, for circumstances just like this.

Further, form data could be stored on the central service, like mailing, shipping, billing, etc info. A log of all sites/accounts that request/require/use this information is kept.

Access to this and all other profile information can be reviewed/revoked by the user at any time.

Groups and layers of account information would be something that could alternately be added to the central service. I.E. - you could have a first level login to get to your dashboard, but additional security could be required to change various portions of your profile details (one passwd for address info, another for accounts)....

Avatar galleries would be available and you could tell each service which avatar to associate with what.

While it would work in the sense that compromising the other systems wouldn't compromise anything else. It does leave that central service as a very very very big and attractive target. It introduces a single point of failure (security wise) that lets someone compromise everyone at everything all at once. It would also make it a good target for warrants and subpoena to be sent to gather information about people without their knowledge (less of an issue, but still a concern for privacy).

If this were true, there would be no reason to hash passwords.

There are hashing algorithms (bcrypt, scrypt, PBKDF2) that are specifically designed to be slow to prevent these attacks.

PBKDF2 is not memory hard, so even with known technology it can be broken relatively easy. Bcrypt seems secure for now, but you shouldn't rely on security through obscurity, which is essentially what putting faith in the irreversability of a hash is. The reality is that if a hashed password leaks, you should assume it will be broken. It's like with bank vaults. They're not designed to withstand attack, just to delay it. Well-hashed passwords delay attack, but they do not prevent it.

Hashes are mathematically proven to be irreversible except through rainbow tables (easily beaten with salting) or brute force. There's no faith needed (well, I suppose that non-mathematicians like myself have to put faith in the math, but I trust the hundreds of independent studies of these algorithms quite well), and it's not anything close to "security through obscurity".

That said, you are right. You should always change passwords that are leaked. This, however, is due to the poor security practices of most companies, not some bizarre distrust of hashes.

Brute force was exactly what i was talking about. It doesn't matter whether a hash is broken through a mathematical flaw, or through improvements in the brute forcing process, if in practice it still gets broken. Once a hash is leaked brute force becomes possible in theory, and what is possible in theory is usually possible in practice with sufficient dedication.

There have been such huge improvements in hashing through tools like hashcat and hardware implementations that i don't think it's unreasonable to distrust hashes. Once a hash is leaked you're essentially hoping that brute forcing it is too high of a cost. Given the history of order of agnitude improvements in hashing speed, i consider it unreasonable to believe that any password database remains safe indefinitely once leaked.

I find your trust in the difficulty of brute forcing a hash just as bizarre as you seem to find my distrust of hashes.

Reply on news.ycombinator.com