I was having a discussion with someone who suggested that due to the random component these were difficult to guess, and suitable for use as a token to access a resource. My initial reaction from reading the spec is that these would be highly vulnerable to enumeration since if I have access to some ULIDs, I can easily check +/- 1 for other ULIDs generated within the same millisecond.
Namely, if the same millisecond is detected, the random component is incremented by 1 bit in the least significant bit position (with carrying).
However, I noticed that this Go implementation specifically increments by a random amount on each millisecond collision, by default from 1 to MaxUint32:
https://pkg.go.dev/github.com/oklog/ulid@v1.3.1#Monotonic
This seems like it would be useful to document the risks associated with incrementing by 1 and tradeoffs of how much additional entropy you add to each increment of the random component.
I was having a discussion with someone who suggested that due to the random component these were difficult to guess, and suitable for use as a token to access a resource. My initial reaction from reading the spec is that these would be highly vulnerable to enumeration since if I have access to some ULIDs, I can easily check +/- 1 for other ULIDs generated within the same millisecond.
However, I noticed that this Go implementation specifically increments by a random amount on each millisecond collision, by default from 1 to
MaxUint32:https://pkg.go.dev/github.com/oklog/ulid@v1.3.1#Monotonic
This seems like it would be useful to document the risks associated with incrementing by 1 and tradeoffs of how much additional entropy you add to each increment of the random component.