Open theboolean opened 6 years ago
Depends whether it's just a matter of also recognizing 2b
as a valid hash or if it's necessary to polyfill a bug, which I'd rather avoid.
@dcodeIO, The code here is based on JohnTheRipper, which is already compatible with $2b$. The code should work fine if you just recognize 2b
as valid.
The bug is specific to OpenBSD implementation only, which is used by bcrypt
.
So it should be enough just to accept 2b as identifier? No other code/algorithm changes?
isn't this alrady covered by:
Despite this not being relevant to 2b
minor types, it would still be useful to be able to generate salt specific to 2b
to keep some records consistent if used with other software (eg. saved and used with same OpenBSD)
bcrypt
module has minor
option for this. https://www.npmjs.com/package/bcrypt#api
Not sure how different the salt gen is between the two, I suspect it's exactly the same and only hashing potentially would differ.
2b is the correction for the bcrypt wrap-around bug. If you have insanely long passwords > 255 chars, you will get the same hash if two of them have the same 255 char prefix.
Rest things are same, including salt generation and format specifiers.
So there is no reason not to allow 2b
salt generation by the library then as it would just be changing a single letter.
I see that if you pass it a salt with a 2b setup it works correctly, but is there a way to select the appropriate format (2a or 2b) when using generated salts? One of the advantages is to allow the algorithm to generate salts for you rather than having to manage that by hand and either introduce another library or risk making a mistake and creating an insecurity with your custom salt generation solution...
Since a bug in the implementation of
2a
hash was found (as you can see here) I was wondering if there is plans for this library to support the2b
hash.Thanks!