IDs are predictable, should clarify in README

[paralleldrive]

IDs are predictable, should clarify in README

[fta2012]

The older PRNG is easier but the new one is similarly vulnerable. You need to switch to crypto.getRandomValues if you really want it to be unpredictable.

[ericelliott]

This should be fixed now.

[seangenabe]

FYI crypto is already available in most browsers.

[nealoke]

@fta2012 just out of interest, if you can't know the timestamp portion can you ever crack the whole thing?

[fta2012]

You just need to search upwards from the last known timestamp. Also if it's a batch insert the next id is likely to be within the same millisecond as the others.

[ericelliott]

I'm open to a PR, with a caveat. For such an attack to work:

1. You'd need to be running an old/buggy PRNG
2. The thing you're searching for would need to be generated by the same client, during the same runtime instance as the known IDs. You'd also need to be able to search the ID space to land on the right millisecond.

Some older apps may be vulnerable to an ID guessing attack.

[ericelliott]

Agreed. Open to a PR.

[fta2012]

If it's just replacing Math.random with the crypto version it should be a small change. I probably won't get to it so this is up for grabs for anyone who wants to contribute.

[ericelliott]

The crypto API is not in the browser.

[MarkHerhold]

I don't think that cuids being predictable is necessarily a bad thing.

[ericelliott]

@MarkHerhold For some apps, it could be a security risk.

[ericelliott]

I'm open to a PR that uses the crypto API if it's available. Note that it is available in IE11 with the ms prefix, so fallback to that if you can.

In Node, we'll have to use the Node crypto API to avoid this vulnerability... note that it is NOT compatible with universal JS, so we'll have to continue to use different builds for Node and Browsers. We could write a facade around the different APIs using a getRandomValues() function and import a different implementation depending on the build.