alt Hacker NewsWhile 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
Replies
jeremyloy_wt • last Wednesday at 10:02 AM
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?
➕ show 1 reply
vjay15 • last Wednesday at 9:10 AM
Thank you! I will definitely look into it!
Interesting read, I do have some questions though and hope you could answer them:
1. Why do you use the API key ID AND the organization ID, and not just one of them, to prevent the confused deputy problem?
2. Why is not necessary to use something like Argon2id for hashing? You say "our secret is already cryptograhically-secure", but what does this mean exactly? Is it due to the fact that the secret is already very high entropy and cracking it, even if we use much faster hash functions like the ones mentioned in your article, it would practically not be possible even PQ with highly parallelized hardware?
Anyways, very interesting read, thank you!