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

41–50 of 107 posts

Re: Making Beautiful API Keys

#41

Post by dspillett »

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.

I would agree with that.

Also, I don't really want API keys and such to be generally pretty. If things that have no business being end-user facing are ugly then they are less likely to be allowed to accidentally become end-user facing.

If being pretty or otherwise user-friendly is a priority, then I'd go with trying to make them readable/pronounceable rather than shorter, even if that actually makes them longer. There are numerous projects out there¹²³ for doing just that. You could even use the 256-word example³ with multiple small dictionaries, and give people a choice from various possibilities that map to the same number.

----

[1] https://github.com/Debdut/uuid-readable

[2] https://github.com/Martichou/uuid-readable-rs

[3] https://github.com/anton-bot/guid-in-words

Re: Making Beautiful API Keys

#42

Post by smashed »

I don't quite understand the need for a timestamp. This only reduces entropy? You wouldn't think of using the current date in a password prefix for example.

Aren't you going to track the keys in a database, where you can keep the tenant id and creation time, scope of the key and any other significant metadata anyway?

A static prefix + checksum, maybe a version number so you can future-proof the system sounds like best practice. For example `ASKEY1-(128bit random base32 encoded)-(chksum)`.

Re: Making Beautiful API Keys

#43

Post by fusspawn »

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... )?

multiple dependencies,

Also requires two other packages to run its 3 lines of code.

"dependencies": { "@scure/base": "^1.1.7", "uuidv7": "^1.0.1" }

Re: Making Beautiful API Keys

#44

Post by hombre_fatal »

a12k wrote: post #25
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…

I totally agree. This looks like a pretty new startup too. I would be livid if my team had spent so much time on this instead of building capabilities to get the startup traction.

Yall are so dramatic.

It's a trivial library to write. 99% of it is just deciding what you want the output to look like + writing the blog post.

Re: Making Beautiful API Keys

#45

Post by xirdstl »

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.

They realized that and were pleased with themselves.

> The dashes do remove easy double-click copying, but we think this a fine trade off for readability. We don't want users copying and pasting them everywhere, in fact we want them to be handled with care. Ideally, users copy each key exactly once - when they generate the key from our dashboard - so we added a copy button to our UI to solve that case

Don't even think about copying/pasting that key, you rube!

Re: Making Beautiful API Keys

#46

Post by tzury »

API keys and UUIDs serve fundamentally different purposes, even though they may look similar as random strings:

1. API keys are security credentials: - They are meant to be secret and revocable - They often encode metadata about permissions and identity - Compromised API keys must be invalidated and replaced - They function like passwords for authentication/authorization

2. UUIDs are identifiers: - They are designed to be globally unique but not secret - They contain no inherent permissions or privileges - There's no security risk if others know a UUID - They function like serial numbers for identification

To use an analogy: An API key is like the key to your house (needs to be kept secret, grants access, can be changed if compromised), while a UUID is like your house's street address (can be public, just identifies the location, doesn't grant any access by itself).

Thinking they're equivalent is like saying your house key and address are the same thing just because they're both strings of characters. This misconception could lead to serious security vulnerabilities if API keys are treated with the same casualness as UUIDs.

PS, we all liked this site, right? https://everyuuid.com/

Re: Making Beautiful API Keys

#47

Post by bArray »

> The dashes do remove easy double-click copying, but we think this a fine trade off for readability. We don't want users copying and pasting them everywhere, in fact we want them to be handled with care. Ideally, users copy each key exactly once - when they generate the key from our dashboard - so we added a copy button to our UI to solve that case.

Or, just ignore the dashes? It's not that difficult, we have the technology.

Re: Making Beautiful API Keys

#48

Post by dietr1ch »

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.

This is the only annoyance with UUIDs, I won't be typing it because its 5 characters shorter. Separators are nice because I can try to visually compare Ids, but it needs to be a visual separator that won't break a `word`/`WORD` (whatever boundary that is by default on most terminals and browsers) select by double clicking.

I want to just double click and copy, dragging is annoying.

Re: Making Beautiful API Keys

#49

Post by kqr »

tommica wrote: post #18
anticorporate wrote: post #6

I love the throwback reference to the Diablo II CD key. There are some CD keys that will be forever etched in my brain, no matter how many PINs I struggle to remember. I suspect a good number of you know far too much of a certain string that starts with FCKGW.

For those who don't know: https://scribe.rip/@cristian.nedelcu/fckgw-rhqq2-yxrkt-8tg6w...

Full article: https://archive.is/TDE9g

Re: Making Beautiful API Keys

#50

Post by jalk »

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'm 99.9999% sure that your 1% risk is incorrect, given they are just reformatting UUIDv7
Post reply on HN