Repository navigation
JRuby and MRI give incompatible results #82
Description
Activity
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
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
DaveOn Tue, Nov 5, 2013 at 3:56 PM, T.J. Schuck notifications@github.comwrote:
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
.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.
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"*72returns true on MRI, and false on JRuby (1.7.4 in my case)
I wonder if the change in jBCrypt 0.3 (http://mindrot.org/files/jBCrypt/internat.adv -- 92c8e4e) affects this at all...
@djmdjm, any ideas?
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?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
DaveOn Wed, Jul 23, 2014 at 1:43 PM, zofrex notifications@github.com 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).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?
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.
Somewhat related, especially to \0... http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html
Running the following code in MRI 1.9.3 and REE 1.8.7 returns true, while running in JRuby (1.6.7.2, 1.7.3, and 1.7.6, in both 1.8 and 1.9 modes) returns false
I've run all the testcases from http://www.mindrot.org/projects/jBCrypt/ and they produce the same results on MRI and JRuby, so this isn't an across-the-board incompatibility, but something about password makes it unhappy. I haven't yet run this in other Bcrypt impls in other languages to see what they return.