How does node.bcrypt.js compare hashed and plaintext passwords without the salt?

From github:

To hash a password:

var bcrypt = require('bcrypt');
bcrypt.genSalt(10, function(err, salt) {
    bcrypt.hash("B4c0/\/", salt, function(err, hash) {
        // Store hash in your password DB.
    });
});

To check a password:

// Load hash from your password DB.
bcrypt.compare("B4c0/\/", hash, function(err, res) {
    // res == true
});
bcrypt.compare("not_bacon", hash, function(err, res) {
    // res = false
});

From above, how can there be no salt values involved in the comparisons? What am I missing here?

Solution 1:

The salt is incorporated into the hash (as plaintext). The compare function simply pulls the salt out of the hash and then uses it to hash the password and perform the comparison.

Solution 2:

I had the same question too as the original poster and it took a look bit of looking around and trying different things to understand the mechanism. As has already been pointed out by others, the salt is concatenated to the final hash. So this means a couple of things:

1. The algorithm must know the length of the salt
2. Must also know the position of the salt in the final string. e.g. if offset by a specific number from left or right.

These two things are usually hard coded in the implementation e.g. the bcrypt implementation source for bcryptjs defines the salt length as 16

/**
* @type {number}
* @const
* @private
*/

var BCRYPT_SALT_LEN = 16;

So to illustrate the basic concept behind the idea if one wanted to do it manually, It would look similar to the below. I do not recommend implementing stuff like this yourself when there are libraries that you can get to do it.

var salt_length = 16;
var salt_offset = 0;

var genSalt = function(callback)
{
    var alphaNum = '0123456789abcdefghijklmnopqurstuvwxyzABCDEFGHIJKLMNOPQURSTUVWXYZ';
    var salt = '';
    for (var i = 0; i < salt_length; i++) {
        var j = Math.floor(Math.random() * alphaNum.length);
        salt += alphaNum[j];
    }
    callback(salt);
}

// cryptographic hash function of your choice e.g. shar2
// preferably included from an External Library (dont reinvent the wheel)
var shar2 = function(str) {
    // shar2 logic here 
    // return hashed string;
}

var hash = function(passwordText, callback)
{
    var passwordHash = null;
    genSalt(function(salt){
        passwordHash = salt + shar2(passwordText + salt);
    });

    callback(null, passwordHash);
}

var compare = function(passwordText, passwordHash, callback)
{
    var salt = passwordHash.substr(salt_offset, salt_length);
    validatedHash = salt + shar2(passwordText + salt);

    callback(passwordHash === validatedHash);   
}

// sample usage
var encryptPassword = function(user)
{
    // user is an object with fields like username, pass, email
    hash(user.pass, function(err, passwordHash){
        // use the hashed password here
        user.pass = passwordHash;
    });

    return user;
}

var checkPassword = function(passwordText, user)
{
    // user has been returned from database with a hashed password
    compare(passwordText, user.pass, function(result){
        // result will be true if the two are equal
        if (result){
            // succeeded
            console.log('Correct Password');
        }
        else {
            // failed
            console.log('Incorrect Password');
        }
    });
}

Solution 3:

Bcrypt compare hashed and plaintext passwords without the salt string because the hashed password contains the salt string which we created at the time of hashing.

For example :

Take this Plain Password :

546456546456546456456546111

Hashed Password of above plain text using Bcrypt :

$2b$10$uuIKmW3Pvme9tH8qOn/H7uZqlv9ENS7zlIbkMvCSDIv7aup3WNH9W

So in the above hashed password, There are three fields delimited by $ symbol.

i) First Part $2b$ identifies the bcrypt algorithm version used.

ii) Second Part $10$ 10 is the cost factor (nothing but salt rounds while we creating the salt string. If we do 15 rounds, then the value will be $15$

iii) Third Part is first 22 characters (that is nothing but salt string) In this case it is

uuIKmW3Pvme9tH8qOn/H7u

The remaining string is hashed password. So basically, the saltedHash = salt string + hashedPassword to protect from rainbow table attacks.

Solution 4:

Because I had the same question myself, I know exactly what you are thinking about.

You have a misconception between "Secret Key" which is used in Cryptographic algorithms and "Salt" which is used to slow down the encryption process and make it harder for hackers to use brute force.

When you use the plain password and the salt to generate the hash, this hash uses as secret key the password itself! So the next time you will try to compare it with a plain password, this plain password must be the exact same one you used to generate the hash! So this is why you don't have to store it somewhere else because it is always provided by the user on both register and login steps!