It's a bit confusing that the "Random hex" example contains characters such as "q" and "p".
My adventure in designing API keys
41–50 of 88 posts
Re: My adventure in designing API keys
#42I don't like giving away any information what-so-ever in an API key, and would lean towards a UUIDv7 string, just trying to avoid collisions. Even the random hex with checksum component seems overkill to me, either the API key is correct or it isn't.
Identifying an opaque value is useful for security analysis. You can use regex to see when they are committed to repos accidentally, for example.
Re: My adventure in designing API keys
#43This is a very good example of premature optimization.
Re: My adventure in designing API keys
#44It's a bit confusing that the "Random hex" example contains characters such as "q" and "p".
I don't understand your question :o
Re: My adventure in designing API keys
#45Presumably because API keys are n bytes of random data vs. a shitty user-generated password we don’t have to bother using a salt + can use something cheap to compute like SHA256 vs. a multi-round bcrypt-like?
I can't understand what you are trying to say :o
Re: My adventure in designing API keys
#46Re: My adventure in designing API keys
#47Re: My adventure in designing API keys
#48While it's true that API keys are basically prefix + base32Encode(ID + secret), you will want a few more things to make secure API keys: at least versioning and hashing metadata to avoid confused deputy attacks. Here is a detailed write-up on how to implement production API keys: https://kerkour.com/api-keys
I don’t understand your explanation on mitigating the confused deputy. If the attacker has access to the database, can’t they just read the IDs for the target row they are overriding first so they can generate the correct hash?
Re: My adventure in designing API keys
#49The purpose of the checksum is to help secret scanners avoid false positives, not to optimize the (extremely rare) case where an API key has a typo
I suppose there could be two checksums, or two hashes: the public spec that can be used by API key scanners on the client side to detect leaks, and an internal hash with a secret nonce that is used to validate that the API key is potentially valid before needing to look it up in the database.
That lets clients detect leaks, but malicious clients cant generate lots of valid-looking keys to spam your API endpoint and generate database load for just looking up API keys.
Re: My adventure in designing API keys
#50Hey OP, sorry for the negativity, I think most of these commenters right now are pretty off-base. My company is building a lot of API infrastructure and I thought this was a great write up!
It is alright, I am learning a lot from them as well, healthy criticism is always useful :)
I am very glad that you found this a great write up ^_^