Hacker News Reader

Comment by acqq | Hacker News Reader

Storing SHA in the database or anything not produced by PBKDF2, bcrypt or scrypt is wrong and doesn't help you much "minimizing damage." Advising SHA doesn't seem to come from a real professional.

View on HN

I don't think you understand the distinction here, this is a random key, not a user generated password. The purpose of using something like bcrypt is to protect against brute forcing hashed passwords.

You cannot brute force search against a large random number that is hashed with unsalted SHA or the like. This would require you to guess the number, hash it and check to see if the hashes match. A large random number encoded as a 64 character string is simply too big to guess, even at millions of guesses per second.

Thus using bcrypt to protect your api keys does nothing but impose a serious bottleneck in how many api requests per second you may authenticate.

Exactly!

SHA is OK, if you have a long random key. I forget the numbers, but a decent random key (100 chars?) becomes impossible to crack before the heat death of the universe. The exponential growth of the password space eventually defeats the weakness of SHA.

The reason you need bcrypt is that user supplied passwords are crap, and can be cracked very quickly.

Yes, I agree that the length of the key and the real randomness are the most important points and that when those are fulfilled the recipe has sense. Neither explicit length minimality nor real randomness of the key were mentioned but the SHA advice was explicit to the 256 bits.

EDIT: To make it clearer: "Long" is not explicit. 256 bits is. The difference between real randomness and for example output of RND in your favourite language is also nowhere to be seen. Moreover the use of the "key" is dubious as it's not an encryption key at all.

From the comment you initially replied to:

"Only use the users password to obtain a long random key" (emphasis mine).

So it was part of the initial recipe.

Someone can do the math but I expect a 64 character long random string is more than sufficient.

Storing the SHA-2 hash of a 256-bit random key obfuscates the API-key, so an attacker with access to the DB can't use it, but is fast to check so will remain performant.

It doesn't matter how many machines you have or how fast you can compute the SHA. An attacker will not find the API key (work out the math).

Sorry I was a little inexact, when I said SHA-2 256 I meant specifically the SHA-2 256 bit (SHA-256) hashing algorithm as opposed to SHA-1 which is considered weak. Not the key length. Though I suspect a 64 character long random string has sufficient entropy.

Reply on news.ycombinator.com