#Java uuid generator code
But the risk then is that developers who later look at your code may not understand that your intent includes secure cryptographic random choice, and not just uniqueness. For example, if you're concerned that a malicious attacker who can request a lot of UUIDs in a short timespan might learn enough information to predict those given out to other users' requests.Īs it happens, Java's UUID.randomUUID() method does use a cryptographic RNG, so it should be safe in that regard. If #2 is a concern, I'd make sure to use a cryptographic RNG. Cryptographic RNGs promise unpredictability to a malicious adversary.UUIDs promise low probability of duplicates.Well, in principle, UUIDs and cryptographic RNGs promise two different things: If you're really worried, storage is cheap - store 256 bit strings that you generate with a SecureRandom and call it good, but make sure you have proper security around everything else, or it's useless. Ultimately, the difficulty of brute forcing doesn't matter if they can find another way in. That's getting to the territory of needing to worry more about hackers compromising the security of your storage more than brute forcing (and, honestly, even with UUIDs, you're going to have that problem). When you get to the point where brute forcing a collision would, on average, take longer than the time for the estimated heat death of the universe, it might be a little overboard.
Only you can really decide what's right for your use case. Now, is more bits going to make it harder for an attacker to brute force a collision? Sure! Is it worth it? Maybe. If these links are going to expire in, say, 24 hours, this is a very small thing to worry about, and that's only with 122 bits. To quote it:įter generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50% Wikipedia's article on UUID has a good description of the math behind it. The fact that you have 6 more bits does, technically, make it more difficult to brute force a duplicate. So, the 'quality' of your randomness isn't going to change. Looking at the source for Java's random UUID generation, you can see they actually utilize the SecureRandom class to generate the raw bytes. In terms of the raw amount of random bits, yes. These identifiers will also be persisted in a relational database as a fixed length CHAR type. The UUID is generated using a cryptographically strong pseudo random number generator." This code returns a 36 character string (e.g. UUID.randomUUID() is a "Static factory to retrieve a type 4 (pseudo randomly generated) UUID. String token = encoder.encodeToString(bytes) SecureRandom random = new SecureRandom() Įncoder encoder = Base64.getUrlEncoder().withoutPadding()
B-KEPLFdWNZ4JTUnnEq3Og) with 128 bits of randomness. This code returns a 22 character string (e.g. More specifically, a call to POST /items will return a 201 Created with a Location to the newly created /items/ is a random string and the URL is intended to be used by anonymous HTTP requests for a limited time window. In building a Java based system that needs unique identifiers on the URL, is UUID.randomUUID() or SecureRandom a better choice?
0 kommentar(er)
