0

I learned that I need to use salt so that same passwords won't show in database.

But where to get the salt? I cannot use one for all as it wouldn't help anything. I can generate a random one, but then the hash would be different every time and nobody would log back in.

So I found suggestion to use cryptographically safe RNG and store the salt with user.

But I would have to make the table larger for that. Can't I use the same hashing function to hash the username and use that as the salt for password? It should be cryptographically safe since I use cryptographically safe hashing function for hashing passwords right?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Tomáš Růžička
  • 513
  • 7
  • 15
  • 2
    Does this answer your question? [How to generate a good salt - Is my function secure enough?](https://stackoverflow.com/questions/4099333/how-to-generate-a-good-salt-is-my-function-secure-enough) – Nico Haase Apr 21 '21 at 20:00
  • 3
    Or this? https://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software – Nico Haase Apr 21 '21 at 20:00
  • well in terms of best practices yes, interms of the generation from the username no, but thank you – Tomáš Růžička Apr 21 '21 at 20:50
  • Why do you **want** to generate a salt "from a username"? That does not sound like a totally random salt. Why do you even care about that? – Nico Haase Apr 22 '21 at 07:19
  • well because if you generate a completly random salt you have to store it next to the password and it just seems a bit of a waste of space to me that's all. So i asked if it's plausible or if there is some safety issue – Tomáš Růžička Apr 22 '21 at 16:26
  • Security is never a "waste of space". Also, why not use any of the common password algorithms that do store everything in one value? – Nico Haase Apr 23 '21 at 07:06
  • I know security is never waste of space that's why i'm asking if it is a vulnerability. Also i don't wanna send the password from frontend to backand (even via https) because than i'd be able to get the passwords from users if i had malicious intent. I want to hash the password in the frontend, send it to backend, hash the hash and store it. Also i want to use hash algorithm that takes quite long on the frontend and some simple (yet secure, eg sha-256) on the backend so potential bruteforce attacker has to do the work instead of simply ask my api and wait for response. – Tomáš Růžička Apr 24 '21 at 13:27

1 Answers1

0

Typically you generate a different (not necessarily random) salt for each password once and store it alongside the hash.

Generating the salt from the username to generate the salt is sufficient if the usernames are unique. You don't really gain anything (but you don't really loose anything either) by using a cryptographic hash function to generate the salt, uniform distribution is sufficient. Even just using the usernames as is will prevent the same passwords showing up in the database, but it will not harden it against rainbow table attacks as much as a salt with a wider distribution would.

Wolfgang Brehm
  • 1,491
  • 18
  • 21
  • If there is any chance that the salt can be "generated" from the username, this weakens the security. Why not use a totally random salt? – Nico Haase Apr 22 '21 at 07:20
  • @NicoHaase I don't see how knowing how to generate the salt from the username weakens the security. OP does not want to store the salt to save space. I agree that that's not a good reason, but maybe he really has to work with very limited space. – Wolfgang Brehm Apr 22 '21 at 18:21