0

I am learning about hashing and encryption and can’t seem to understand this:

Client: New user logs in => Creates password => Sent to a server in plain text

Server: Server generates a random "salt" => plain text and salt are unified => Hash function (e.g. SHA-3) hashes the password+salt into a hash => Hash is stored in DB.

Client: Same user logs out and logs in => Password sent to a server in plain text.

Server: Password needs to re-add the same salt it generated when creating the account to get the same hash.

How does the server generate that same random and unique salt? Is the salt stored on a different DB altogether? If a DB is compromised the hackers would also gain access to the salt and just brute force rainbow tables with the salt and unhash them.

Walter Monecke
  • 2,386
  • 1
  • 19
  • 52
  • 1
    The salt is stored together with the hash, and just pulled from this when validating against the hash – Ebbe M. Pedersen Feb 19 '21 at 13:04
  • 1
    A subtlety which is often missed by beginners is that building a rainbow table is *much more* work than brute forcing the same password space. Thus rainbow tables are only useful when that extra work can be amortized over multiple password attacks. A unique salt per user forces the attacker to build a different rainbow table per user, thus making the rainbow table attack worse than a straightforward brute-force. – President James K. Polk Feb 19 '21 at 13:26
  • 1
    @PresidentJamesK.Polk Yes, this is what made it confusing to me. Basically salting is just compensating for the laziness of people not generating a strong password in the first place. – Walter Monecke Feb 19 '21 at 13:30

2 Answers2

1

The salt that was randomly generated must be stored in the database and linked to the user that logged in. It could be simply added as another column in the user table.

In a typical setting, the salt and the password (or its version after key stretching) are concatenated and processed with a cryptographic hash function, and the output hash value (but not the original password) is stored with the salt in a database

Source: https://en.wikipedia.org/wiki/Salt_(cryptography) retrieved 19/02/21

The generation of the salt depends on which technology you are using. The following stack overflow answer has an example for PHP:

Can we use uniqid() to generate a unique Salt in PHP

The password should also never be sent in plain text to the server. This can be done via HTTPS for example

pm101
  • 1,309
  • 10
  • 30
  • But then the salt is stored on a different DB altogether? If a DB is compromised the hackers would also gain access to the salt and just brute force rainbow tables with the salt and unhash them. – Walter Monecke Feb 19 '21 at 13:07
  • @WalterMonecke - the point of the salt is so that *different* users with the same passwords get different hashes. Different users have different salts and so rainbow tables aren't feasible. – Damien_The_Unbeliever Feb 19 '21 at 13:10
  • The common and simplest method is to store the salt as another column in the user table. I guess the salt could also be stored elsewhere for further 'protection' but there will be advantages/disadvantages of doing so course. The idea is that it will take a much longer time to brute force a single user as opposed to every user at once. – pm101 Feb 19 '21 at 13:13
  • 1
    If the password is stored with AES256 it will take a single PC more years than the age of the universe to brute force. https://scrambox.com/article/brute-force-aes/ – pm101 Feb 19 '21 at 13:17
  • 2
    @WalterMonecke - yes, but you have to do it for each account separately, due to different hashes. The usual concern with unsalted password hashing and rainbow tables is that you only have to do it once and you get all password for *all* account simultaneously. – Damien_The_Unbeliever Feb 19 '21 at 13:17
  • @Damien_The_Unbeliever if you have access to both - the used salt and hash - by breaching a DB, couldn't you just brute force and get the plaintext? Apparently, you could just brute force it, but the cost is the main issue to recreate rainbow tables with specific hashes: https://security.stackexchange.com/questions/16686/recompute-rainbow-table-with-salt – Walter Monecke Feb 19 '21 at 13:26
  • @Damien_The_Unbeliever Thank you for the explanation, I understood it now :) – Walter Monecke Feb 19 '21 at 13:27
0

When the user logs in again. The password is sent to server side along with email.

The email is used to fetch the user record and then the Hash value saved against that email is compared with the new hash (salt + password entered).

The validate function method matches the 2 different hash values and checks if password entered was same or not.

For example, I am using bcrypt in Node JS and it has a method compareSync which matches the entered password with the saved hash bcrypt.compareSync(password, databaseHash);

Danyal Sandeelo
  • 12,196
  • 10
  • 47
  • 78