Hacker News Reader

Comment by al_james | Hacker News Reader

Here's a (potentially stupid) idea:

The app provides a fixed 'secret key' that defines (somehow) a sequence of hashing and scrambling functions to apply to the password. So, for example, the secret key "df8dfuhuejew3" (or whatever) might be interpreted as '3 iterations of md5 hash followed by rotate hash 5 places to the left followed by 2 iterations of bcypt etc..'.

So, in effect, each app (with a different secret key) will have a different hashing process, but with the advantages that its repeatable and cross platform (reference implementations could be available in the major languages).

Of course, if your secret key is hacked you are in trouble, but at that point the hacker can probably get your source code for whatever hash system you use, and anyway, the combined hashing process is probably slow enough to prevent brute force attack.

Any thoughts?

Edit: Probably better to just use bcrypt with a larger work factor.

View on HN

Why is this any more secure than keeping a salt in your code?

bcrypt(password + hardcoded application salt + db-stored user salt) is far less complex and arguably just as secure, since your argument is predicated on "assume the source code is safe". bcrypt is tunable to be as slow as you want, even to account for hardware progress.

>bcrypt is tunable to be as slow as you want, even to account for hardware progress.

I did not know that. Can you expand on this point?

Part of the bcrypt process includes a "work factor", which is, crudely, "how many times do I run this?" What you can do is tune your work factor so that it takes a reasonably long time to hash a password (say, 0.05 sec on your webserver = 20 passwords/sec), which won't necessarily heavily impact the performance of your website, but which would be a significant impediment to anyone trying to brute-force those passwords.

As hardware improves, you just implement a system wherein when the user submits login information, you verify their password with your old work factor, and if it passes, re-hash with your new (slower) work factor and store the updated hash. This allows you to effectively use a progressively slower algorithm over the lifetime of your application to compensate for Moore's Law.

You obviously don't want to pick a work factor that's too high for your web server hardware, since that opens you up to DOS attacks, but a reasonable work factor can easily mitigate the weaknesses of MD5 and SHA1 - notably, that they can be computed by the hundreds of millions of second on the right harware.

Ok, got it. Thanks. Yes, much better. I was under the impression bcrypt was also a fixed cost operation.

If anyone else is wondering how to implement bcrypt with a cost parameter in PHP, see http://php.net/manual/en/function.crypt.php under CRYPT_BLOWFISH.

It's probably prudent for most developers to instead use phpass [0] rather than attempt to roll their own implementation.

[0] http://www.openwall.com/phpass/

PHK is not concerned with preventing precomputed (rainbow table) attacks. A salt is fine for that. He wants to make it harder to create special-purpose hardware for brute-forcing. Combining many different types of hashes is only intended to eat up die space.

Again, if you really need to use a secret algorithm, instead use a secret key with the known proven algorithm (see for example https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#...)

That the security of a cipher system should depend on the key and not the algorithm has become a truism in the computer era, and this one is the best-remembered of Kerckhoffs's dicta. ... Unlike a key, an algorithm can be studied and analyzed by experts to determine if it is likely to be secure. An algorithm that you have invented yourself and kept secret has not had the opportunity for such review.

http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle#Implic...

Moreover, you made the security of your system "key"-dependent: what if I generate such "key" that will only use 5 iterations of MD5 and 1 iteration of SHA-1? This would be a major failure. Imagine if the security of AES was not 2^128, but varied between 2^10 to 2^128 depending on what key you supplied -- would you use it?

>Moreover, you made the security of your system "key"-dependent: what if I generate such "key" that will only use 5 iterations of MD5 and 1 iteration of SHA-1? This would be a major failure. Imagine if the security of AES was not 2^128, but varied between 2^10 to 2^128 depending on what key you supplied -- would you use it?

Agreed. The unpredictability of the work factor would be a problem.

Reply on news.ycombinator.com