1

Instead of creating a separate salt generator for each user, can't I just use their username as a salt? It would be unique for everyone, and achieves the purpose of the salts.

    <?php   
$hashedpass = sha1($username.$password)
 >?

If the username is too short to be used as a salt, I can just add a global string to the username.

$salt =$username.'asdf1234'
$hashedpass = sha1($salt.$password)

Would this be sufficient for security? It still creates a unique salt for each user and prevents rainbow table attacks.

Kunal Chopra
  • 169
  • 6

1 Answers1

1

User names are predictable. I would prefer using random value as a salt. An attacker could begin the generation of precumputed hash table targeting one user (admin?) even before obtaining the hash&salt to crack.

So, you should NOT.

Edit:

The main purpose of having a salt is that rainbow tables are useless. From my point of view, using a guessable value (even with static value added) as salt is bad practice as you allow an attacker to "prepare" the hashes before obtaining your database.

In some scenarios : if you distribute your code and you have a default "admin" account, an attacker will be able to reuse the rainbow table against all the installations of your software.

Other example from @Anti-weakpasswords : Pyrit, "a WPA/WPA2 cracking tool, tool advantage of the WPA/WPA2 protocol using the SSID (username equivalent) as the salt to allow the precomputation of reasonably sized dictionaries against common SSID's - linksys, dlink, 2WIRE047."

r00t
  • 1,104
  • 8
  • 16
  • What about mixing up, or adding a string to, the username? – Kunal Chopra Jun 21 '15 at 17:40
  • You may want to explicitly state that you shouldn't use usernames as passwords. While I understand the risk of precomputation attacks, the OP might not get that from your answer. – Neil Smithline Jun 21 '15 at 17:40
  • 1
    @KunalChopra - what is the problem with using the built-in, well-tested functionality of PHP? – Neil Smithline Jun 21 '15 at 17:41
  • @r00t - an example you can add to your repertoire is that of [pyrit](https://code.google.com/p/pyrit/), a WPA/WPA2 cracking tool that took advantage of the WPA/WPA2 protocol using the SSID (username equivalent) as the salt to allow the precomputation of reasonably sized dictionaries against common SSID's - linksys, dlink, 2WIRE047, etc., just like an attacker could precompute an attack again common usernames like jsmith, joesmith, joes, joe.smith, etc. – Anti-weakpasswords Jun 21 '15 at 17:53
  • @Anti-weakpasswords - Yes I added it to the answer. Thanks, that's a good "real-life" example. – r00t Jun 21 '15 at 17:57
  • It doesn't matter if the salt is guessable. It only matters that it's computationally in-feasible to pre-compute the hashes, and that there's no commonly used set of salts. You could randomly pick a 128 bit number as an initial sequence, and then just increment a counter each time you wanted to create a new salt. That would be just as impossible to pre-compute as randomly generating each salt. The salt is guessable, but extremely unlikely that anyone else has started at the same 128 bit counter as you have. – Steve Sether Jun 21 '15 at 18:48
  • I'd STILL recommend random generation, simply because it's easier, but this scenario is just as secure. There may be some scenarios where generating a random number is difficult (embedded environments with no random source?). – Steve Sether Jun 21 '15 at 18:50