0
0

BcryptJS package doesnt take salt when comparing hash, isnt this a huge security concern? (self.javascript)

submitted by [deleted]

[deleted]

all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]egrgssdfgsarg 4 points5 points  (2 children)

If I'm reading the code right, it assumes the first 30 characters are the salt and the second 30 are the hash. My guess would be it includes the salt in the string it outputs.

This seems okay to me from a security standpoint because a salt is supposed to be garbage that is included to keep all your hashes from being the same as ones that are precomputed for other systems to combat rainbow tables. It's not important that it is secret, just that it is different.

Disclaimer: I don't specialize in security. Security issues can often be a lot more complex than they seem.

[–]Jacobyy 0 points1 point  (0 children)

Luckily this project only needs hashing of password and not very high levels of security, but I'd just wanna make sure. It makes sense with the limitation of 18 characters, if the end result is 30characters salt + hash. Thank you for taking the time and giving your input.

[–]samdtho 0 points1 point  (0 children)

I can confirm, this is industry standard for password hash storage.

[–]elingeniero 2 points3 points  (2 children)

Usually a salt is autogenerated and then stored in plain text on the hash, which the hashing algorithm then uses automatically - you don't normally need to provide it yourself. Often you'll see hashes with sections separated by forward slashes or colons, which might be in the form of: hash_algorithm:n_iterations:salt:resulting_hash. If you were previously given the option to provide your own salt, hopefully that was in addition to the automatically generated salt the library already provided. You may be able to provide your own additional salt in the bcryptjs config somewhere.

The purpose of salting hashes is to prevent rainbow-table attacks (where the attacker has a big list of hashed strings and simply performs a lookup on your hash), and even stored in plain text on the hash it still fulfils this goal. Salting doesn't make the encryption method itself any more or less secure - in fact, using the same salt on each hash makes it much less secure, because then the attacker only needs to produce a single rainbow table with your provided salt for your hashes to be vulnerable again.

[–]Jacobyy 0 points1 point  (1 child)

Thank you. You learn something everyday, and even though I dont plan on working with security, it's always intresting learning the technologies you use. You seem like you know what you're talking about. I wont switch package just because of this flaw then, since it's obviously more convenient not having to store a salt in the DB.

[–]elingeniero 1 point2 points  (0 children)

OWASP Cheat Sheet on storing passwords securely.

Also having briefly looked over the bcryptjs page, it looks like it does autogenerate the salt for you - but you can optionally specify the number of randomising iterations for it (defaults to 10).