0

I know that MD5 is a poor choice for hashing passwords, but its not my ideia.

Imagine that we would use the username as a salting mechanism, wich is also bad idea, but just for an example. First, we md5 or sha1 this username and then concatenate with the password as a salt, then hash it: sha2(md5(username).password).

Is this more or less safe than just adding the username with the password: sha2(username.password).

I am asking because of the obvious size and randomness of an md5 compared to a username, but theres the downside of hash collision.

h0m3
  • 1
  • 3
  • it's a lot more safe since off-the-shelf ripping software would likely hit short UN+PW combos. it's still wide-open to a researched attack however, and there's plenty of other methods that aren't. – dandavis Aug 19 '17 at 11:51
  • Possible duplicate of [Is MD5 considered insecure?](https://security.stackexchange.com/questions/19906/is-md5-considered-insecure) – kenorb Oct 11 '17 at 21:59

1 Answers1

2

Is this more or less safe than just adding the username with the password: sha2(username.password).

There is no real difference. Both using plain username and md5(username) are bad ideas and show a missing understanding of what the salt is used for and how to generate and store it. A salt is used to drastically increase the search space for the attacker in that the same passwords will result in different hashed passwords and thus pre-computing lots of hashed passwords for easy comparison becomes infeasible.

If you use a non-random salt derived from the username (or the username itself) you still increase the search space but not as much as a pure random salt would be used. Since the salt for a hashed password is no secret anyway (see How to store salt?) there are no advantages in using a non-random salt derived from the username compared to a random salt but there are only obvious disadvantages. But, to come back to username vs. md5(username) - there is practically no difference in increase of search space because the probability of different usernames resulting in the same hash (i.e. collision) is practically zero. Still, don't use any of these but use a random salt.

Apart from that using sha2(salt,username) to compute the password hash is a bad idea too because SHA-2 is fast and thus brute-force attacks are easy compared to using a slower hash. See What is the specific reason to prefer bcrypt or PBKDF2 over SHA256-crypt in password hashes? for more details.

Overall, please don't invent yet another way to store passwords. Instead study How to securely hash passwords? to find out how to do it properly and also for explanations why it should be done this way.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Yeah, using username it was just a bad example actually, not the concept. I was thinking about the difference when using rainbow tables, a bad username + a bad password would be faster to hash than an md5 of that bad username??? It's a theoretical question. – h0m3 Aug 19 '17 at 12:06
  • @h0m3: to cite myself: *" there is practically no difference in increase of search space because the probability of different usernames resulting in the same hash (i.e. collision) is practically zero."* – Steffen Ullrich Aug 19 '17 at 12:57