Node.bcrypt.js: where is salt stored?

[marialovesbeans]

If i run this package on different machines and at different time, it should give the same salt, right? So the salt must be hardcoded somewhere to so the value is consistent. Where is it stored?

[piemonkey]

The generated salt should be different, but the salt used when verifying the password should be the same, otherwise it would never match, I assume that's what you mean?
The salt is stored in the hash that is output, taking the example from wikipedia:

For example, the shadow password record $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy specifies a cost parameter of 10, indicating 2^10 key expansion rounds. The salt is N9qo8uLOickgx2ZMRZoMye and the resulting hash is IjZAgcfl7p92ldGxad68LJZdL17lhWy.

[recrsn]

bcrypt uses the modular crypt format, as @piemonkey explained, the salt is stored as the part of the generated hash itself.

[marialovesbeans]

If salt is revealed in the hashed form of password, isn't that insecure? Aka, in a normal hashing algorithm, the attacker would have to guess the salt, right?

[piemonkey]

Salting isn't done for that purpose. You need to know the salt to check the password, so even if it was stored separately the code to verify the password would need to have both the hash and the salt and an attacker could almost certainly get the salt if they can get the hash. Most password hashing algorithms either produce a modular format or expect the random salt to be stored alongside each hash e.g. in another field in the same DB table.

Salting is done to prevent attacks such as the use of rainbow tables. If the salt wasn't included, any 2 users with the same password would have the same hash and an attacker could hash a list of common passwords and discover what passwords people have used. When salting is used you'd need to generate one of these 'rainbow tables' of common password hashes for each salt, which would be slower than just using brute-force to try all of the common passwords.

To be secure the salt needs to be random and long, but doesn't need to be any more secret than the hash of the password.

[vancouverwill]

good question, I was under the impression that the salt would be stored alongside the hash of the password too but this solution is very elegant and avoids mis-implementation 👍

[ManBearPigg]

I was going to ask, how does your bcrypt.compare know the correct number of hashing iterations to perform? I know that the salt is stored in the produced hash, so I figured the number of iterations probably is too.

In your example above, if I remove the hash and the salt from the shadow password, I'm left with
$2a$10$

Presumably the '$' are delimiters so you can parse out the numbers, the '10' means 10 salt rounds, and I imagine the 2a has to mean that we are doing 2^[salt rounds] hashing iterations.

Is that right?

[piemonkey]

There are more details on the format on Wikipedia, either on the page I linked or for the origin of the format in the C standard library.

In short, 2a is the algorithm used.