Hacker Newsnew | comments | show | ask | jobs | submitlogin

> Best practices say to encrypt your passwords in the database to limit a potential data breach. This increases overhead for each request when authenticating a user. Unique API keys authentication skips the hashing step and therefore speeds up your calls.

Wait, why can you can skip the hashing step and still be secure? Because hashing is only neccesary if you call it a 'password', but not if you use it in the same way but call it an 'api key' instead?

I guess it depends on the purpose for hashing. If it's just about 'data breaches', then maybe it doesn't matter if your api keys get out... because they at least won't grant access to any _other_ systems, since they weren't manually entered by users and re-used accross systems. Is that what you're thinking?

But don't you still want to avoid a data breach like this for your _own_ service?

And, I think, isn't the other reason hashed passwords are used, to make it harder to do a brute force attack? Ie, it's quite intentional and deliberate that it increases request overhead. And doesn't this still apply to an api key, possibly even MORE so when you have a single api key instead of a username/pass combo?




If you lose the database for your own service, it does not matter how you authenticate to that service. Attackers have already fatally bypassed your credential system. At the same time, API credentials should by definition be single-use.

-----


> At the same time, API credentials should by definition be single-use.

Could you spell this one out a little bit more? Do you mean only a single session should be able to use an API credential?

-----


I mean the credential should only be relevant to the service, never shared across multiple services, because the API generates it for you.

-----


HMAC authentication requires both the client and the server to have a shared secret (or more likely a derived key based on a shared secret). The secret cannot be saved as a one-way hash (as might be common for a password). So you couldn't use BCrypt or SCrypt to hash the shared (or derived) secret since the server would never be able to acquire the value to calculate the same digest.

You can still encrypt the secret, e.g. using AES 256 bit encryption with secure random Initialization Vectors and rolling keys. This too is not easily 'brute forceable', but is very fast to decrypt compared to a BCrypt comparison (key storage should also be in a separate location than the main data store).

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: