Hacker News Reader

Comment by mrb | Hacker News Reader

A good cryptographer assumes that a custom hash function does not prevent rainbow table attacks, because he should not assume the algorithm will remain secret (security by obscurity, yadi, yada).

The right way to prevent a rainbow table attack is to computationally prevent it via unique salts.

View on HN

Unique salts are absolutely the correct way to rainbow-proof a database of hashes[1]. But a novel hash function will still do the trick and isn't comparable to using a single salt across the entire database, as you originally claimed.

Reverse engineering a novel hash function, while theoretically possible, isn't a capability possessed by the folks dumping passwords from LinkedIn or Riot. And even if it were, doing so would cost more than would be gained by compromising those passwords[2].

Thus, in practical terms, a novel hash function is a great way to undermine attackers, not unlike using Linux or opening files in non-standard viewers (LibreOffice, Nitro PDF Reader, etc.).

1. And if you have access to a good cryptographer, you should absolutely roll a novel hash function as well. Security through obscurity is the proverbial cherry on top of your defensive sundae, i.e. it's only a bad thing if you rely on it exclusively.

2. Not to mention that the whole point of rainbow tables is that they've already been computed. If an attacker has to reverse engineer a hash function to create a rainbow table, that largely defeats the rainbow table's purpose.

1. No. A good cryptographer will tell you to not re-invent crypto and to use existing peer-reviewed hash functions. This is why the NIST is hosting an open competition for selecting the future SHA-3.

2. This is exactly what happened with the custom proprietary "obscure" GSM A5/1 encryption algorithm. First it was reverse engineered (based on a leak), then David Hulton and Steve Muller created rainbow tables for it. The fact that it was a custom algo did not defeat the rainbow table's purpose.

There are many ways a custom hash algo designed by a company could end up being used across multiple of its password databases, and could subsequently be leaked, making the generation of rainbow tables possible and valuable (by rogue employees or hackers), that relying on the obscurity of a custom algo is a bad idea. As you recognized, salting is the ultimate protection. So there is no point in talking about alternatives.

But a novel hash function will still do the trick and isn't comparable to using a single salt across the entire database, as you originally claimed.

I'm not sure I understand this point, what is the criteria for a function to be novel?

This function produces different hashes from most other hash functions, eg, it is new and possibly novel, but is equivalent to using a single salt across a database:

    function novelHash(password) {
        return md5("novelHash" + password);
    }

Yes but it's not like the random hacker has a 600 gig rainbow table for MD5('DATSALT' + PW). If you REALLY want to do the right thing when it comes to storing passwords, you need to use a hash algo that is computationally hard enough to brute force, it should take at least .5 sec on a good computer to compute. Every couple years, you should add another pass of the algorithm, ie. F(F(X)), to compensate for faster computers. By adding the extra pass, you won't need the original password to generate the new, revised, stronger custom hash algo. If you do this, in 10 years your passwords will still be secured. Also, salt your passwords with each a unique at least 100 random bytes, shouldn't need to be said.

Not an expert, but I believe rehashing the hashes is a good way to decrease entropy.

As long as the salt is added for each recursive iteration, it should destroy any kind of cryptographic hints given by hashing a hash. So you shouldn't be doing F(F(F(X))) rather it should be F(SALT + F(SALT + F(SALT+X)))

But anyhow, I was talking about increasing the security of an already-existing hash algorithm. Even if the recursive hashing isn't that much more secure, it definitely isn't less secure than one pass...

Reply on news.ycombinator.com