2

I know there are various questions that seem similar, for instance, this one. However, it does not answer my question.

I'm creating a signup/login system (with node.js to be particular), and I'm trying to hash the user's password (with bcrypt), as well as use aes-256 for the rest of the user information. I've been told that I should use a different salt for each user.

My problem is when a user creates an account, his password is hashed with a special salt and stored inside a database along with other user information. When the user logs in, I hash this password with the salt I assigned it when he signed up. However, how do I know which salt to use out of all the salts in my database?

There's also this option out there (comparing a plain text to a hash):

bcrypt.compare(myPlaintextPassword, hash, function(err, result) {
    // result == true
});

But how do I know which hash (of all the other hashes in the database) to compare to the user input? Also, if bcrypt could check if it matches without a salt, couldn't anyone do that?

I believe there must be a better implementation of this... is there?

ublec
  • 23
  • 4

1 Answers1

2

But how do I know which hash (of all the other hashes in the database) to compare to the user input?

Each user has a row in your database with entries for columns: (1) username; (2) bcrypt output.

Also, if bcrypt could check if it matches without a salt, couldn't anyone do that?

bcrypt can not check without the salt.

However, how do I know which salt to use out of all the salts in my database?

The brcypt output looks like this:

$2b$[cost]$[22 character salt][31 character hash]

So, the bcrypt salt and the bcrypt hash are both stored in the bcrypt output entry that is in your database (and associated with a given username by row).

hft
  • 4,910
  • 17
  • 32
  • I didn't know that that was the bcrypt output. But then what's the use of the salt if once the hacker gets the hashed password, he gets the salt? That would just make everything easier... – ublec May 05 '21 at 05:01
  • Because it protects against "rainbow table" attacks. These are attack where the attacker can PRE-COMPUTE lots and lots of hashes. This is not possible when you salt the hash. – hft May 05 '21 at 05:02
  • 3
    In other words, the hacker has to recompute hashes for every user in the database that he or she wants to attack. bcrypt is a slow hash function so as long as your password policies are reasonable the attacker will not have time to computer enough hashes. – hft May 05 '21 at 05:04