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

81–88 of 88 posts

Re: My adventure in designing API keys

#81

Post by phire »

ben-schaaf wrote: post #75
phire wrote: post #74

Earlier quoted context omitted.

You don't have to use a publicly documented checksum. If you use a cryptographically secure hashing algorithm, mix in a secret salt and use a long enough checksum, attackers would find it nearly impossible to synthesise a correct checksum.

I don't follow. The checksum is in "plain text" in every key. It's trivial to find the length of the checksum and the checksum is generated from the payload. Others have pointed out that the checksum is for offline secret scanning, which makes a lot more sense to me than ddos mitigation.

I'm not sure it's a good idea.

But it's trivial to make a secret checksum. Just take the key, concatenate it with a secret 256-bit key that only the servers know and hash it with sha256. External users might know the length of the checksum and that it was generated with sha256. But if they don't know the 256-bit key, then it's impossible for them to generate it short of running a brute force attack against your servers.

But it does make the checksum pretty useless for other usecases, as nobody can verify the checksum without the secret.

Re: My adventure in designing API keys

#82

Post by ben-schaaf »

phire wrote: post #81
ben-schaaf wrote: post #75

Earlier quoted context omitted.

I don't follow. The checksum is in "plain text" in every key. It's trivial to find the length of the checksum and the checksum is generated from the payload. Others have pointed out that the checksum is for offline secret scanning, which makes a lot more sense to me than ddos mitigation.

I'm not sure it's a good idea. But it's trivial to make a secret checksum. Just take the key, concatenate it with a secret 256-bit key that only the servers know and hash it with sha256. External users might know the length of the checksum and that it was generated with sha256. But if they don't know the 256-bit key, then it's impossible for them to generate it short of running a brute force attack against your serve…

Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)

Re: My adventure in designing API keys

#83

Post by vjay15 »

stanac wrote: post #73
vjay15 wrote: post #54

Earlier quoted context omitted.

hash of the API key just like passwords

I think they are saying passwords are salted and we use multiple rounds of hashing to prevent rainbow tables and slow down brute-forcing the password (in case of db leak). We don't need to do that for randomized long strings (like api keys), no one is guessing 32 character random string, so no salt is needed and we don't need multiple rounds of hashing.

OHHH that makes sense!

Re: My adventure in designing API keys

#84

Post by vjay15 »

tjarjoura wrote: post #67

I've always been interested in the technical distinction between an API "key" and an API "token". And the terminology of "key" used to confuse me, because I associated that with cryptography, and I thought an API key would be used to sign or encrypt something. But it seems that in many cases it's basically just a long, random password.

Yes, it's just a random long password used to access public APIs

Re: My adventure in designing API keys

#85

Post by phire »

ben-schaaf wrote: post #82
phire wrote: post #81

Earlier quoted context omitted.

I'm not sure it's a good idea. But it's trivial to make a secret checksum. Just take the key, concatenate it with a secret 256-bit key that only the servers know and hash it with sha256. External users might know the length of the checksum and that it was generated with sha256. But if they don't know the 256-bit key, then it's impossible for them to generate it short of running a brute force attack against your serve…

Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)

I don't think it counts as a signature, because it can't be verified without revealing the same secret used to create it.

Re: My adventure in designing API keys

#86

Post by ben-schaaf »

phire wrote: post #85
ben-schaaf wrote: post #82

Earlier quoted context omitted.

Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)

I don't think it counts as a signature, because it can't be verified without revealing the same secret used to create it.

You're right, the correct term seems to be MAC (Message Authentication Code).

Re: My adventure in designing API keys

#88

Post by out_of_protocol »

matja wrote: post #52

What if the "slug" was a prefix for the API key revocation URL, so the API key was actually a valid URL that revoked itself if fetched/clicked? :)

i suspect a lot of tools will try to fetch the url without explicit user action (e.g. messengers do that kind of crap). Gotta be hard to keep keys non-revoked, which is a nice side-effect
Post reply on HN