How Long Should I Make My API Key? | Hacker News Reader

How Long Should I Make My API Key?

blog.learnphoenix.io

59 pointsokket34 comments

I see some confusion both in the article and in the comments.

If we're talking about an API key, then the issue isn't collision and there's no relationship with hashing or uuids except the recommended final length.

A key should be a random 128-bit string (or 192, or 256 if you need additional security).

If you need to generate a key from a passphrase, use a key expansion function, not an hash just because the length is the same.

I don't know if there's any proof of randomness for uuid, the risk (in absence of a proof) is that to provide uniqueness the bit distribution is uneven, which could leak some information to an attacker, thus reducing the real bit strength of the key.

Most programming languages do not use secure random number generators. As you suggested it is not always wise to use UUIDs for API keys if you are not sure about the nature of the PRNG.

Python for example uses os.urandom for random UUID generation (uuid4), as can be seen in the source: https://github.com/python/cpython/blob/3.5/Lib/uuid.py#L603

The standard library guarantees that os.urandom is "[...] suitable for cryptographic use." (https://docs.python.org/3.5/library/os.html#os.urandom)

I'm not sure about other languages, so it might always be a good idea to look it up in the source code.

In Ruby you should use the SecureRandom module, but even that has had issues in the past.

http://ruby-doc.org/stdlib-2.3.1/libdoc/securerandom/rdoc/in...

https://news.ycombinator.com/item?id=11624890

Seems like it still has issues? The bug is still open. Embarrassing but entertaining.

This is not very well thought out.

1) If you are generating API keys, those are presumably used to make API calls, and every such call has to verify that the API key exists so it can deny or allow the request, which means that doing a lookup on any API key has to be an extremely cheap operation.

So do the lookup after generating each and check for collisions. If you hit the jackpot and actually managed to randomly create a duplicate, generate another. Problem solved, and you don't have to worry about the collision frequency of your hash algorithm as a weird workaround for skipping a single extra lookup at API key creation.

2) Use GUIDs. It's what they're for. It's in the name. Globally Unique Identifier. This is the problem they solve.

GUIDs are Microsoft's implementation of UUIDs. UUIDs are long enough (128 bits) that you can generate them randomly and be confident in never getting a collision.

That's what UUID4 is -- all but six bits (that's 122 bits) are completely random. Checking for UUID4 collisions is the height of paranoia. It's basically checking whether your PRNG broke.

So your second recommendation is basically the same as the article's, and contrary to the first. Comparing UUIDs is not that expensive, but as expensive as it has to be for a key that will never collide.

You'll never know if your PRNG is broken if you just assume it's not and don't check. Well, you might find out later, and have a lot of tricky cleanup.

Comparing UUIDs is cheap, but avoiding non-constant-time compares is a necessity. So the usual for loop with an early exit when two bytes don't match up is poison. A web application could become susceptible to timing attacks.

This is a good article that helped me understand and mitigate the vulnerability: https://codahale.com/a-lesson-in-timing-attacks/

You also have to protect against an attacker guessing your next PRNG output, which is highly likely for non-crypto PRNGs even if they'll never collide with themselves. So always use the secure RNG from your language or OS for generating UUIDs.

For those who are not sure about the difference UUID vs. GUID

UUID = Universally Unique Identifier, RFC 4122 (https://tools.ietf.org/html/rfc4122.html)

GUID = Globally Unique Identifier, the (mostly) Microsoft flavored version of UUIDs, used in partition tables as well

Both of them consist of 128 bits, and both use 6 bits to denote the way the ID was generated, e.g. using the NIC MAC or timestamps.

An overview over the different RFC 4122 UUID flavors can be found here: https://en.wikipedia.org/wiki/Universally_unique_identifier#...

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).

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.

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.

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....

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.

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.

"Hashing" and "random keys" are different. The author keeps mentioning "hashing" but it's "number of true random bits" that matters.

If the generation of those keys uses pseudo random data, time, etc, the risk of collision goes up.

Read 16 bytes from /dev/urandom and stuff them into base64encode and you have a pretty good random API key in readable ASCII.

I usually try to avoid base64 when encoding data/password/keys to users. Due to it's large/"odd" charset. I would recommend using binary to hex (base16) notation or base32.

Why is it bad to use case sensitive alpha plus digits plus two punctuation? The article already uses 62 chars (minus the two punctuation.)

If you encode fewer bits per character, you get a longer key but no more security.)

Raw binary: 16 bytes Base64: 22 bytes Base32: 26 bytes Base16: 32 bytes

The only reason to use base 32 is codes that a human may enter (promo, verification, serial) to remove case and O/0 ambiguities.

The only reason to use base 16 is laziness (some APIs generate this for you.)

API keys are presumably copied from the generation page and pasted into the local app config file.

You need the API key to be long enough to be unguessable. Otherwise, I could get free stuff by just guessing someone else's key.

This is significantly longer than what you need to avoid a collision. The idea of having a three-character key is just crazy.

I thought he was just using that as an example to see what the risk of collision was - not actually suggesting that they be used.

I am confused about the hash function involvement in this. I just use a random number generator to give me one of the 62 possible values. Why do I need to bash something?

https://news.ycombinator.com/item?id=12327215

Reply on news.ycombinator.com