Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My adventure in designing API keys

vjay15.github.io

Post reply on HN
Print view View original

51–60 of 88 posts

Re: My adventure in designing API keys

#51

Post by vjay15 »

petterroea wrote: post #37
vjay15 wrote: post #27

Earlier quoted context omitted.

Hello bob! the checksum is for secret scanning offline and also for rejecting api keys which might have a typo (niche case) I just was confused regarding the JWT approach, since from the research I did I saw that it's supposed to be a unique string and thats it!

I may be naive but I can't imagine anyone typing an api key by hand. Optimizing for it sounds like premature optimization, surely stopping the less than one in a million HTTP request with a hand-typed API key from reaching the db isn't worth anything

if not for typo, then I can use for secret scanning then :)

Re: My adventure in designing API keys

#53

Post by numbsafari »

vjay15 wrote: post #45
tlonny wrote: post #22

Presumably 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

How are you storing the API key in your database?

Re: My adventure in designing API keys

#57

Post by hk__2 »

> I didn't proceed with this approach since I don't want the API keys to have any info regarding the account, but hey it is all just a matter of preference and opinion.

Well I would have done that and saved half the blog post.

Re: My adventure in designing API keys

#58

Post by vjay15 »

bob1029 wrote: post #40
vjay15 wrote: post #27

Earlier quoted context omitted.

Hello bob! the checksum is for secret scanning offline and also for rejecting api keys which might have a typo (niche case) I just was confused regarding the JWT approach, since from the research I did I saw that it's supposed to be a unique string and thats it!

The neat thing about JWT is that there are no secrets to scan for. Your secret material ideally lives inside an HSM and never leaves. Scanning for these private keys is a waste of energy if they were generated inside the secure context.

Ideally API key shouldn't contain anything regarding the account or any info right? it's meant to be an opaque string, is what I found in most of the other articles I read. Please do let me know if I am wrong about this assumption

Re: My adventure in designing API keys

#59

Post by petterroea »

vjay15 wrote: post #51
petterroea wrote: post #37

Earlier quoted context omitted.

I may be naive but I can't imagine anyone typing an api key by hand. Optimizing for it sounds like premature optimization, surely stopping the less than one in a million HTTP request with a hand-typed API key from reaching the db isn't worth anything

if not for typo, then I can use for secret scanning then :)

Good point!

Re: My adventure in designing API keys

#60

Post by randomint64 »

jeremyloy_wt wrote: post #48
randomint64 wrote: post #19

While 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?

The attack would be like: attacker has read/write access to the database but not to the code of the backend service. Attacker swaps the hash of a targeted API key with the hash of their own API key. Attacker has now access to the resources of the targeted organization when using their own API key.
Post reply on HN