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?

1 Answer 1

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).

3
  • 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 5, 2021 at 5: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 5, 2021 at 5: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 5, 2021 at 5:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.