Hacker News Reader

Comment by poutine | Hacker News Reader

Because if someone gets access to your database somehow you're not exposing all of the keys for all of your users.

While you're likely in serious trouble if someone gets your DB this helps minimize damage. Besides to authenticate a request you dont need the plaintext of the key, a hash is fine.

View on HN

Ah, that's fair

I guess the trade-off is here that the api key cannot then be retrieved from a GUI either (because the server doesn't actually know the original key!) .. from a UX perspective, most companies show your active keys in a GUI with ability to selectively remove or replace.

Though I can't think of a mainstream API that hasn't let me retrieve api key from GUI

Indeed, this is where common usage hasn't really caught up with best practice. It really is no better than showing the user their cleartext password.

Ideally you'd regenerate the key each time the user wants to show it or just use OAuth 2.0 (it's not as bad as everyone says it is).

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.

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!

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.

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.

Reply on news.ycombinator.com