3 ms·
I also don't get it. The article seems to be about IDs or serial numbers, and to make these unique I'd assign them consecutively like so: 1, 2, 3, 4, 5, 6, 7, .
by JohnStrange 10y ago
I also don't get it. The article seems to be about IDs or serial numbers, and to make these unique I'd assign them consecutively like so: 1, 2, 3, 4, 5, 6, 7, ...
For GUIDs, on the other hand, I'd probably just use a good standard cryptographic hash function like SHA3 rather than assuming that there will be no more than n "clients". But it depends on the purpose, of course.
- freshhawk 10y agoThese are API keys, so they need to be both unique and hard to guess. First line of the article.
- JohnStrange 10y agoSure, but that sounds like bad design out of the box. I'm still trying to find a reasonable use case for these "public keys" (quote from the very first line, too) One would assume that public keys are always easy to guess, because they are public? Hopefully they are not used for any sort of public authentication protocol...?
- tofflos 10y agoAPI keys are not always (rarely?) intended to be public. Some (most?) solutions are based on always using TLS. In that scenario the API key alone is sufficient to identify and authorize the user, so the user must prevent the API key from becoming known to others. Some (few?) solutions allow for communication without TLS. In that scenario the API key is usually paired with a shared secret used for signing all messages, so the user is under no obligation to prevent the API key from becoming known to others.