Repository navigation
JRuby and MRI give incompatible results #82
Description
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
require 'rubygems'
require 'bcrypt'
require 'base64'
b64h = "BqvyJXQvnL3CKVd6pAv25giyYNEGXg4k5UOwkTeYXZo=\n"
password = "$2a$12$BaVII7NCCtTxF4BKdjPy2.IkvEG4X4/CRhDvmenQKm2r/6pIoW..q"
BCrypt::Password.new(password) == Base64.decode64(b64h)
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.
Activity
tjschuck commentedon Nov 5, 2013
Is your base64 encoding/decoding necessary to make this work? Does this give the same behavior?
dgolombek commentedon Nov 5, 2013
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 notifications@github.comwrote:
tjschuck commentedon Nov 5, 2013
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.
Oscil8 commentedon Nov 5, 2013
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
returns true on MRI, and false on JRuby (1.7.4 in my case)
reedloden commentedon Mar 11, 2014
I wonder if the change in jBCrypt 0.3 (http://mindrot.org/files/jBCrypt/internat.adv -- 92c8e4e) affects this at all...
@djmdjm, any ideas?
zofrex commentedon Jul 23, 2014
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?
dgolombek commentedon Jul 23, 2014
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 notifications@github.com wrote:
zofrex commentedon Jul 30, 2014
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?
Oscil8 commentedon Jan 18, 2015
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.
reedloden commentedon Mar 13, 2015
Somewhat related, especially to \0... http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html