11

I'm using coldfusion and I would like to generate a random salt field for my passwords. I was wondering if a CreateUUID() function is useful here. I found many examples which use a seperate function to create the salt string; but why do this when you could use rand() or CreateUUID() functions instead? I'm not sure.

Is it an overkill or a good idea? Or should I use rand() or a timestamp instead?

Mohamad
  • 34,731
  • 32
  • 140
  • 219
  • see also: http://stackoverflow.com/questions/1194318/is-a-guid-a-good-salt-is-my-register-login-process-got-any-flaw – Kip Feb 28 '13 at 21:00

1 Answers1

11

This is not a good idea - CreateUUID guarantees uniqueness, not randomness; if you did a statistical analysis of CreateUUID, it most likely wouldn't be a distribution considered sufficiently random for cryptography, because it wasn't explicitly designed that way.

For example, the first n bytes of CreateUUID is your MAC address - i.e. always the same for every salt. By doing that, you've significantly decreased the amount of entropy that your salts have, thereby making them easier to crack. Use libraries to handle the whole auth scenario if at all possible, and if not, use a real rand() function.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • 3
    I'm not sure that anything you've said would make the case that a UUID is a bad salt. Uniqueness for a salt is actually more important than randomness. The whole point of a salt is to prevent rainbow table hacks. – Kip Feb 28 '13 at 21:00
  • 4
    @Kip If you can predict the salt for a new user (or for an existing user), you can significantly lower the key space of things you have to brute force. That's Bad™ – Ana Betts Feb 28 '13 at 22:10
  • Am I missing something? What is the purpose of limiting key space against brute force? AFAIK, only moment salt become relevant is the moment whole user database dumped on public forum, including clear salts and hashed passwords. Salt is protecting hashed password from being reversed into clear form by forcing hackers to compute separate rainbow table for each unique salt (for each user). So, computational requirements approximates to infinity for userbase-wide reversals and only thing hackers can becomes picking of most-important people and creating special rainbow tables for their salt. – ufukty Aug 13 '22 at 11:57