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

Making Beautiful API Keys

docs.agentstation.ai

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Making Beautiful API Keys

#91

Post by thiht »

wink wrote: post #52
alt227 wrote: post #29

Earlier quoted context omitted.

Agreed. I cant see why anyone thinks this was worth spending time on rather than just using the standards which everybody else does. Nobody types out api keys so there is no need to make them friendly to say or remember. After you have copied and pasted them once into your db, you are never going to seee or use that string again!

Totally worth spending a single day at some hackathon or slack time event... but not more. And it looks like a lot more.

Does it? We once discussed making our ids (UUIDs) prettier, came to the same conclusion of using some base64 variant in 5 minutes, and came across base32 10 minutes later, and the final implementation is pretty trivial.

This is a 1 day job at most to get something polished (assuming there’s no migration/retrocompatibility constraints)

Re: Making Beautiful API Keys

#93

Post by verdverm »

dewey wrote: post #64
stitched2gethr wrote: post #21

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…

Sometimes spending engineering time for content marketing is worth more than implementing some feature that's not needed for the early adopters.

content marketing can demonstrate orgs you don't want to work for and can therein be counterproductive

Re: Making Beautiful API Keys

#94

Post by verdverm »

noman-land wrote: post #26
lovasoa wrote: post #15

Dashes in API keys are really annoying. Double-clicking doesn’t select the full key, which just adds extra hassle. It would be much better if they used a continuous string without any separators. Makes copying and pasting way easier, and doesn't affect security at all.

Double click and drag is your friend.

you're my hero today

Re: Making Beautiful API Keys

#95

Post by verdverm »

dewey wrote: post #14
notpushkin wrote: post #8

Earlier quoted context omitted.

I’ve made a library for that! https://codeberg.org/prettyid

Why should anyone vendor a dependency in a critical functionality for three lines of code ( https://codeberg.org/prettyid/js/src/branch/master/lib/index... )?

only if I can leftpad it first?

Re: Making Beautiful API Keys

#96

Post by hdjjhhvvhga »

alt227 wrote: post #85
benterix wrote: post #72

Earlier quoted context omitted.

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.

Ah, so you need to know that first, otherwise it's still ambiguous to people reading them.

Re: Making Beautiful API Keys

#98

Post by kennu »

lovasoa wrote: post #15

Dashes in API keys are really annoying. Double-clicking doesn’t select the full key, which just adds extra hassle. It would be much better if they used a continuous string without any separators. Makes copying and pasting way easier, and doesn't affect security at all.

Whenever I have created API keys for a product, this is the #1 feature I want: easy copy-pasteability. Just letters and numbers, no special characters that break double-click-selecting the key.

Re: Making Beautiful API Keys

#99

Post by ramchip »

jaccola wrote: post #84
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.

UUIDs are longer because they use a less efficient encoding (base16 vs base32), not because they contain more entropy.
Post reply on HN