Bcrypt not that secure at hashing passwords?

Question

I am using bcrypt to generate salts and hash passwords, but I do not think that it is doing it very securely. When I use the following code:

bcrypt.genSalt(10, function(err, salt) {
  user.salt = salt;
  bcrypt.hash(password, salt, function(err, hash) {
    user.hashed_password = hash;
    console.log(user.salt);
    console.log(user.hashed_password);
    user.save(function(err) {
      if (err) console.log(err);
      console.log("saved");
    });
  });
});

In one example, the salt is: $2a$10$mFFjRpY1Vrq7Fy1fFp0fMO and the hashed_password is: $2a$10$mFFjRpY1Vrq7Fy1fFp0fMOVnlv9cKgAFdCQ5xdtlP6UoKz90i1FMu

The beginning of the hashed password is the exact same as the salt. If an attacker has access to the salt, can't he just remove the salt from the hashed_password and either brute force or use a table of predetermined hashed values to determine the password?

I always thought this should be the order of hashing a password:

hash(salt + password)

Not:

salt + hash(password)

Answer 1

The beginning of the hashed password is the salt because you need access to the salt in order to verify the password.

The data you see is neither hash (salt + password) nor salt + hash(password) -- it is of the form

salt + hash(salt + password)

If an attacker gains access to this data, then:

• They can of course (theoretically) brute force the password -- no technique can prevent this, but rate limiting renders the attack impractical. The hash function used in this instance is specifically designed to take a long time to run, indirectly rate limiting the attack.
• They cannot use a standard table of hashes to find out the password -- that's because the hashed value also contains the unique salt. Of course the salt is out there in the clear so a table can be calculated, but since the salt is also unique to each hashed password this is no better than a brute force attack.