Hacker News Reader

Comment by jnbiche | Hacker News Reader

Why would you use a hash function here? What are we hashing? The username and password? If so, that means you can't revoke the API key without revoking the password. Since you're storing the username and password anyway, an API key should just be a long random string, generated using a CSPRNG, base64-encoded. Also, by generating the API key yourself, you're not depending on the security of the user's password (which you would if you're hashing it).

View on HN

I also don't get it. The article seems to be about IDs or serial numbers, and to make these unique I'd assign them consecutively like so: 1, 2, 3, 4, 5, 6, 7, ...

For GUIDs, on the other hand, I'd probably just use a good standard cryptographic hash function like SHA3 rather than assuming that there will be no more than n "clients". But it depends on the purpose, of course.

These are API keys, so they need to be both unique and hard to guess. First line of the article.

Sure, but that sounds like bad design out of the box. I'm still trying to find a reasonable use case for these "public keys" (quote from the very first line, too)

One would assume that public keys are always easy to guess, because they are public? Hopefully they are not used for any sort of public authentication protocol...?

API keys are not always (rarely?) intended to be public. Some (most?) solutions are based on always using TLS. In that scenario the API key alone is sufficient to identify and authorize the user, so the user must prevent the API key from becoming known to others.

Some (few?) solutions allow for communication without TLS. In that scenario the API key is usually paired with a shared secret used for signing all messages, so the user is under no obligation to prevent the API key from becoming known to others.

If you want to support communication over non-secure connections, you'd want to provide a "secret" key, and an ID for that key. Then you'd create an HMAC hash with the secret key, rather than actually sending the key.

Doing that securely and protecting against replay attacks is non-trivial though.

For an example of just how non-trivial this is, take a look at the version history of how AWS requires signing API requests.

Version 1 had a serious flaw [0] related to how the string to be HMAC'd was constructed. It used an appropriate and well-studied cryptographic building block (HMAC-SHA1) and is an excellent case study in why using the right building blocks isn't sufficient to have a secure protocol.

Version 2 fixed the issues with version 1, but it in turn has been superseded by v4 [1] (no idea what happened to v3). A v4 signature uses a derived key for the HMAC, and included in the derivation is the current date as well as the AWS region you're making the call to. Beyond time-based replay attacks, this also prevents an attacker from capturing a valid request to eg US-EAST-1 and replaying that request in a different AWS region.

0: http://www.daemonology.net/blog/2008-12-18-AWS-signature-ver...

1: https://docs.aws.amazon.com/general/latest/gr/sigv4_changes....

This seems like something we're not supposed to do... why not just use tls or ssh?

TLS client authentication (which I think is what you're getting at) is a pain in the ass to implement clients for properly - OpenSSL is dreadful to use, and for many HTTP client libraries you'll need to use it (or a very thin wrapper) to set X.509 client certs, if you even can. On the other hand, there's decent libraries and plenty of information on how to generate and verify an HMAC, and avoid replay attacks.

No that's not what I'm getting at. I'm saying the design of secure protocols is best left for smart people. Every time you post on HN, you're using cookie auth, but you don't have to worry about replay attacks because everything runs inside TLS. Any environment that has HMAC libraries also has the libraries one would need to do the right thing.

HMAC is useful for expiring, limited-use tokens without having to store every single token, just the base key. It's used by CloudFront, for example.

Oh definitely, just pointing out that TLS client certs are used only rarely.

As far as I can tell, that's the usual way to do it these days: make the API HTTPS-only, and stick the auth token in each request. Using secure connections isn't expensive anymore.

Indeed, hence my comment about it being non-trivial.

Regardless, there are many possible cases where you wouldn't be able to use TLS for whatever reason, though it's very rare.

He's talking about generating random hashes.

Edit: Parent is asking "What are we hashing?", but the article says "Every language has a decent crypto package for generating random hashes".

Hash functions are used as a one-way transform for some string of data. By definition, they require an input. You can't just run a hash function and get a random string. You can supply a random string and then get a hashed random string. But why do that here? I'm guessing he's referring to hashing a username and password, but since he also refers to them as "public keys" (no API key should ever be public), it's not clear at all what is being discussed.

Yes, supplying a random string to a hash function to get a hashed random string is what I am inferring is the author's intent. Why do that? To get a unique ID that can be used as an API key, as opposed to using a GUID for example. And sometime you need public API keys, for example the browser keys you need to use google maps.

Reply on news.ycombinator.com