3
$\begingroup$

Quote:

Most of these answers are a bit misguided and demonstrate a confusion between salts and cryptographic keys. The purpose of including salts is to modify the function used to hash each user's password so that each stored password hash will have to be attacked individually. The only security requirement is that they are unique per user, there is no benefit in them being unpredictable or difficult to guess.

[...] Random 64-bit salts are very unlikely to ever repeat even with a billion registered users, so this should be fine.

Since a salt needs to be unique and a GUID is unique as well as long enough (128-bits):

Would it be secure to have GUIDs as a salt instead of a CSPRNG?

(The only flaw I could think of was if the generation of a GUID would somehow be flawed.)

Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ A point could be made (and indeed has been made in recent password-authenticated key exchanges) that leaking (which includes picking predictable values) the salt is bad insofar it allows an attacker to pre-compute possible password hashes before the actual database is leaked, giving users of the service less time to react and change their password on this and other services. $\endgroup$
    – SEJPM
    Oct 16, 2018 at 11:32
  • $\begingroup$ Not sure that GUIDs are really 128 bits, but probably long enough. $\endgroup$
    – Paul Uszak
    Oct 16, 2018 at 11:55
  • 2
    $\begingroup$ There are quite some ways to generate GUID's, have a look here. They do generally not have 128 bits of security, although, as Paul indicated, they probably have enough. But this article shows that GUID's could possibly be predicted - so they can become known even if they are not published (they are not secret, after all). Just using a random salt, stored next to the hash value, seems less error prone and more secure. (I'd still prefer a strong pw and weaker salt over a weak pw and strong salt, of course, better make both strong) $\endgroup$
    – Maarten Bodewes ♦
    Oct 16, 2018 at 12:03
  • $\begingroup$ A related question: Do I need to use a CSPRNG when creating salts for user accounts? $\endgroup$
    – kelalaka
    Oct 16, 2018 at 12:55
  • 1
    $\begingroup$ I'm still a little bit confused. I found different answers about this subject, i.e. this answer clearly states, that using a UUID (=GUID) would have no security-related disadvantages, because the salt apparently "only" needs to be unique. If a salt is unique per user then everything is fine. I'm not saying that any comments here or the linked answer is wrong, it's just irritating to have different "answers" to this... Seems to me like that answers on this subject are partially opinion based. $\endgroup$
    – AleksanderCH
    Oct 16, 2018 at 14:34

1 Answer 1

Reset to default
6
$\begingroup$

Most systems which generate Type 4 UUIDs, aka “random GUIDs” generally already use a CSPRNG to generate them. This is necessary to prevent collisions in the generated output; generating thousands UUIDs from a random number generator that has a small state or is seeded weakly from the system time would quickly start generating non-unique type 4 UUIDs, and hopefully fail unit tests.

Examples which use a CSPRNG include the UUID generation functions in Java, Microsoft .net, and most databases.

However, this is not always the case and shouldn’t be relied upon unless you can verify that the implementation uses a CSPRNG for generating type-4 UUIDs.

I have actually encountered two separate home-grown UUID generators which used Math.random() in JavaScript. Both generated collisions after <= 100k UUIDs in testing (and were also generating collisions in the production application which was fun to debug).

In short, salts need to be unique, so use a CSPRNG directly for generating 16-byte salts if you can. If you have to use a UUID function, ensure that it is not going to generate collisions via reading the low-level docs and direct testing (generate millions of UUIDs and check for duplicates).

Counter/time based UUIDs can also reasonably be used for salts, but again verify the implementation’s uniqueness via direct testing. I have encountered one time-based UUID generator which generated duplicates if called in a tight loop due to an insufficiently large counter wrapping.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.