Making Beautiful API Keys • Hacker News Board

Re: Making Beautiful API Keys

#81

Post by skerit » Fri, Jan 10, 2025, 3:18 PM UTC

What's up with these comments? Let these folks format their keys the way they want.

Re: Making Beautiful API Keys

#82

Post by progforlyfe » Fri, Jan 10, 2025, 3:19 PM UTC

theamk wrote: post #2

One of the best things you can do to your API key is to give it a fixed prefix. Makes it very easy to tell that you have the right string, to detect accidental secret leakage, etc... IMHO this makes key much more beautiful than any internal structure.

actual functional features in API keys! How dare you! aesthetics over all!!

Re: Making Beautiful API Keys

#83

Post by majkinetor » Fri, Jan 10, 2025, 3:19 PM UTC

progbits wrote: post #51

majkinetor wrote: post #37

Earlier quoted context omitted.

Crockford has a checksum though

https://github.com/agentstation/uuidkey/blob/master/uuidkey.... They don't appear to check validity though? I haven't tested it so maybe someone else can double check.

yes they do. We use it in prod

Re: Making Beautiful API Keys

#84

Post by jaccola » Fri, Jan 10, 2025, 3:20 PM UTC

robertclaus wrote: post #10

This type of key editing always makes me nervous. I know how uuids behave. I'm not a security expert, but I'm 99% sure the formatting steps here don't increase the chance of key collisions or security implications significantly. Is that 1% risk worth it?

I agree - the reformatted IDs are shorter than the originals, so by the pigeonhole principle you are increasing the chance of collision.

I doubt this matters in reality for this case, but the number of comments stating "there is no difference" or something to this effect shows how any added step can easily be misunderstood and could (in the worst case) introduce a fatal security flaw.

Re: Making Beautiful API Keys

#85

Post by alt227 » Fri, Jan 10, 2025, 3:23 PM UTC

benterix wrote: post #72

moebrowne wrote: post #70

Earlier quoted context omitted.

They use Crockford Base32 encoding which does exactly that.

I don't think so since the sample key they present in the big image contains many of these. The caption is "An example API key generated by github.com/gofrs/uuid and encoded with github.com/agentstation/uuidkey." - so something is wrong.

You need to look harder at the encoding standard. After generation all o are mapped to 0 and all l are mapped to 1 so yes there are 0 and 1 but there are never o and l.

Re: Making Beautiful API Keys

#86

Post by stby » Fri, Jan 10, 2025, 3:23 PM UTC

benterix wrote: post #59

The author mentions readability - if they care about it, they should eliminate all ambiguous characters like 0Oo1l.

Base 32 does that for them, it excludes the lower case letters and I L O U.

Re: Making Beautiful API Keys

#87

Post by alt227 » Fri, Jan 10, 2025, 3:24 PM UTC

> Overall, developers like to use UUIDs - they just don't like how they look.

I have never ever heard a developer even mention the way api keys look before.

Re: Making Beautiful API Keys

#88

Post by xdennis » Fri, Jan 10, 2025, 3:24 PM UTC

> uppercase letters and numbers for "blocky" aesthetics and readability

I'm not sure if this is meant to be read as "uppercase (letters and numbers)", but it is effectively what he's referring to.

Lowercase digits do exist[1], but there's no Unicode encoding for them and fonts typically have to choose to support one or the other.

[1]: https://en.wikipedia.org/wiki/Text_figures

Re: Making Beautiful API Keys

#89

Post by bkummel » Fri, Jan 10, 2025, 3:25 PM UTC

a12k wrote: post #23

This is the very definition of bikeshedding. It should be included as a reference in any definition of that term.

+1

Re: Making Beautiful API Keys

#90

Post by bkummel » Fri, Jan 10, 2025, 3:28 PM UTC

I'm not sure whether the result is more readable than a UUID. With a UUID you at least know that it can only be [0-9A-F]. Besides, who on earth _types_ API keys? You should copy/paste them and store them in a password manager. So they don't _need_ to be readable.