JRuby and MRI give incompatible results about bcrypt-ruby HOT 10 OPEN

Is your base64 encoding/decoding necessary to make this work? Does this give the same behavior?

plaintext = "%t/)Wz`^$C7]'"
hashed = BCrypt::Password.create(plaintext)
BCrypt::Password.new(hashed) == plaintext  # => true

from bcrypt-ruby.

Yes, the Base64 encoding appears to be related -- that code works in both
JRuby and MRI. The value that is Base64 encoded came from a HMAC, the
submitted code is a simplification of some code derived from
https://github.com/fwenzel/django-sha2.

Thanks
Dave

On Tue, Nov 5, 2013 at 3:56 PM, T.J. Schuck [email protected]:

Is your base64 encoding/decoding necessary to make this work? Does this
give the same behavior?

plaintext = "%t/)Wz`^$C7]'"hashed = BCrypt::Password.create(plaintext)BCrypt::Password.new(hashed) == plaintext # => true

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/82#issuecomment-27811478
.

from bcrypt-ruby.

Yep -- took me a minute to install JRuby, but the above code (without the base64ing) definitely works on JRuby 1.7.3, and confirmed that the base64 version does not.

from bcrypt-ruby.

For another failing test case, from the BCrypt test strings at: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john/src/BF_fmt.c?rev=HEAD

BCrypt::Password.new("$2a$05$/OK.fbVrR/bpIqNJ5ianF.swQOIzjOiJ9GHEPuhEkvqrUyvWhEMx6") == "\xaa"*72

returns true on MRI, and false on JRuby (1.7.4 in my case)

from bcrypt-ruby.

I wonder if the change in jBCrypt 0.3 (http://mindrot.org/files/jBCrypt/internat.adv -- 92c8e4e) affects this at all...

@djmdjm, any ideas?

from bcrypt-ruby.

I don't fully understand this issue... does it only come into effect if Base64 is involved?
What I'm worried about: I have a bunch of hashes being created using this library running under JRuby. I'm going to be migrating to MRI later this year. Is there a chance some of my users will be locked out if I migrate due to this bug?

from bcrypt-ruby.

Base64 itself is unrelated, but it may have to do with UTF-8 or other
non-ascii characters in the source material.

Yes, the transition from JRuby to/from MRI is exactly the scenario that I
was testing when I encountered this issue.

I haven't yet tested Reed's suggestion around the jBCrypt 0.3 fix, it
certainly does look potentially relevant.

Thanks
Dave

On Wed, Jul 23, 2014 at 1:43 PM, zofrex [email protected] wrote:

I don't fully understand this issue... does it only come into effect if
Base64 is involved?
What I'm worried about: I have a bunch of hashes being created using this
library running under JRuby. I'm going to be migrating to MRI later this
year. Is there a chance some of my users will be locked out if I migrate
due to this bug?

—
Reply to this email directly or view it on GitHub
#82 (comment).

from bcrypt-ruby.

What is the probability of an incorrect hash being generated? For every say, million hashes generated by this library in JRuby, how many should we expect to be incorrect when transitioning to MRI?

from bcrypt-ruby.

Have done a bit of work on this recently. There are two key issues: a) when using 8-bit characters, the JRuby -> Java conversion and the jBCrypt use of .getBytes("UTF-8") ensure inconsistent results compared with the native implementation; b) the native implementation can't handle strings containing "\0" null values because it assumes null-terminated strings, whereas jBCrypt doesn't pay attention to those.

Long story short, make sure your input to the bcrypt is all ASCII values between 1 and 127 (7-bit clean, no zeroes) and I believe you'll be safe.

from bcrypt-ruby.

Somewhat related, especially to \0... http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html

from bcrypt-ruby.