Hacker News Reader

Comment by NoPiece | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

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.

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

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?

Reply on news.ycombinator.com