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

31–40 of 88 posts

Re: My adventure in designing API keys

#31

Post by vjay15 »

swiftcoder wrote: post #23
fabian2k wrote: post #9

Earlier quoted context omitted.

You don't need any encryption or signing for API keys. Using JWTs is probably more dangerous here, and more annoying for people using the API since you now have to handle refreshing tokens. Plain old API keys are straightforward to implement. Create a long random string and save it in the DB. When someone connects to the API, check if the API key is in your DB and use that to authenticate them. That's it.

> Plain old API keys are straightforward to implement This is pretty much just plain-old-api-keys, at least as far as the auth mechanism is concerned. The prefix slug and the checksum are just there so your vulnerability scanner can find and revoke all the keys folks accidentally commit to github.

yes this is the approach!

Re: My adventure in designing API keys

#32

Post by vjay15 »

Savageman wrote: post #18

Side note: the slug prefix is not primarily intended for the end-user / developer to figure out which kind of key it is, but for security scanners to detect when they are committed to code / leaked and invalidate them.

Ahhhh I see, I didn't think about it that way too, this could help us a lot yea!!!

Re: My adventure in designing API keys

#33

Post by arethuza »

vjay15 wrote: post #27
bob1029 wrote: post #8

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire 512 bit token still fits in an x86 cache line. Comparing the whole sequence won't show up in any profiler session you will ever care about. If you want aspects of the token to be inspectable by intermediaries, then you want json web tokens or a similar technol…

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!

"for rejecting api keys which might have a type" - assuming that is meant by to be "typo" - won't they get rejected anyway?

Re: My adventure in designing API keys

#34

Post by vjay15 »

pdhborges wrote: post #25

I don't even understand what approach 3 is doing. They ended up hashing the random part of the API key with an hash function that produces a small hash and stored that in the metashard server is that it?

yea... sorry I still am not the best explainer but that is the approach, I just wanted to have a shorter hash in the meta shard that is it. The approach 3 is an attempt by me to generate my own base62/base70 encoder ;-;

Re: My adventure in designing API keys

#35

Post by vjay15 »

arethuza wrote: post #33
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!

"for rejecting api keys which might have a type" - assuming that is meant by to be "typo" - won't they get rejected anyway?

it's just an added benefit, I don't have to make a DB call to verify that :)

Re: My adventure in designing API keys

#37

Post by petterroea »

vjay15 wrote: post #27
bob1029 wrote: post #8

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire 512 bit token still fits in an x86 cache line. Comparing the whole sequence won't show up in any profiler session you will ever care about. If you want aspects of the token to be inspectable by intermediaries, then you want json web tokens or a similar technol…

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

Re: My adventure in designing API keys

#40

Post by bob1029 »

vjay15 wrote: post #27
bob1029 wrote: post #8

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire 512 bit token still fits in an x86 cache line. Comparing the whole sequence won't show up in any profiler session you will ever care about. If you want aspects of the token to be inspectable by intermediaries, then you want json web tokens or a similar technol…

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.
Post reply on HN