vercel/uid-promise

Creates a cryptographically strong UID

uid-promise

Creates a cryptographically secure UID with a 62 character range that can be safely used in URLs.

Usage

Install the package:

npm i uid-promise

Then import it:

import { uid } = from 'uid-promise';

Finally, call it:

await uid(20);

API

uid(Number len) => Promise

• Return a Promise that resolves with a string of random characters of length len
• len must always be provided, else the promise is rejected
• Under the hood, crypto.randomBytes is used
• Character set: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789

Authors

• Guillermo Rauch (@rauchg) - Vercel
• Leo Lamprecht (@notquiteleo) - Vercel

uid-promise's Issues

Length of UIDCHARS makes uid's biased

The length of UIDCHARS is 62, which doesn't divide 256, the amount of possibilities of a byte from crypto.randomBytes. Therefore, the first 8 characters ("ABCDEFGH") will be chosen somewhat more often than the rest.
The rest of the characters each have 4/256 ~= 1.56% chance to be chosen, while the first 8 have 5/256 ~= 1.95% chance – an extra 0.39%.
I don't know exactly how this should compromise security, but I doubt the generated UID's can be rightfully called "cryptographically secure", since bias in a random generator is always bad.

There are two ways to deal with this:

• Add two characters to UIDCHARS (for example, - and _, since they too are unreserved in URI's according to the RFC), to make its length 64, which divides 256;
• Reject values >=248 from crypto.randomBytes. This effectively reduces its range to 248 choices, which 62 divides. When using this, one can't simply request the required amount of bytes from crypto.randomBytes and be done with it; a reasonable strategy would probably be to request some more bytes, making sure that in the overwhelming majority of cases, there are still enough bytes to cover the UID. In the case that there are not enough, you'd need to ask for more crypto bytes.

You can fix this or not fix this. The current code is probably fine for what you're using it for, but if you leave it like it is, I suggest changing the wording of the readme.

(node:15610) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1)