Hot answers tagged

9

Variants and Versions: A UUID has variants and versions. The 4 in this case tells you, that it is the version 4. Other versions range from 1 to 5. Those versions have variants 8, 9, A and B, therefore the z in your UUID tells you which variant it is. The variant is used for telling which layout the UUID has. Variants are also important when it comes to ...


6

It would depend on the implementation of the GUID/UUID library. Determining the internal state of a pseudo-random number generator varies widely based on which one you're talking about. Many GUID/UUID libraries utilize a proper cryptographically strong pseudo-random number generator (CSPRNG) when generating v4 UUIDs. In those specific cases, when ...


5

It seems you could always need a bigger number. Not really. In theory perhaps, obviously there's always a bigger number, but you'll run into limits of physics pretty quickly. With a random 128 bit ID, you could store around an exabyte of IDs before running into problems with collisions. That's just storing the IDs, presumably you'll want to be storing data ...


5

UUIDs do not generally guarantee unpredictability or any security properties. As RFC 4122 says (section 6): Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation. What you require here ...


2

You're just describing a scheme where the UUID simply becomes a password. There's nothing especially secure or insecure about this, aside from no person ever going to be able to pick a "weak" password, but on the other hand, half of the people going to store their password unencrypted. I don't really see why you'd do this to people. You're not going to ...


2

I have one main concern with your setup: You should hash the UUID tokens! Otherwise, if your database leaks all accounts will be exposed. Given the amount of entropy in a securely generated UUID, a simple hash function as SHA-256 will do the job. A few minor points. Using a UUID as an authentication is not wrong from a security perspective, as long as you ...


1

Here is a list of tips/techniques that you can use: If users are authenticated and you assign a unique uuid, just allow one TCP/HTTP/HTTPS connection for a given uuid. By doing this, you will limit the number of connections to your service that can use the uuid. If somebody wants to reuse a uuid or do a "uuid attack" by flooding from requests you can use a ...


1

You're right that a GUID is unnecessary for security when proper access controls are in place. However, there are still reasons that a GUID can be useful: A GUID makes it somewhat more difficult for a malicious user to identify other file records, in case there are vulnerabilities. Given a pair of file identifiers, an incremental ID reveals which file was ...


1

Because generating a new GUID is trivially easy, whereas keeping track of which was the last sequence number issued and making sure that the next one is issued only once (no multi-user timing problems) is much more difficult. Also, a GUID leaks no data; a sequence number discloses the number of files being stored.


1

Given that you say the GUID is sequentially assigned and sent in network traffic, no, it is not suitable for use as a salt. While it will still prevent the typical scenarios of "attacker wants to crack all your passwords, so they build a rainbow table that can be used to look up any hashed password" and "two users used the same password, and you can tell ...


Only top voted, non community-wiki answers of a minimum length are eligible