Can you link the upstream source for the new code?

Sure... Basically, upgrading from http://openwall.com/crypt/crypt_blowfish-1.1.tar.gz to http://openwall.com/crypt/crypt_blowfish-1.2.tar.gz

The jBCrypt implementation doesn't support versions other than '2' and '2a', so tests fail. Also, due to issue #82, there are going to be other test failures between the MRI and JRuby implementations. I could just either break out those tests to a separate MRI-only block or just add a new field that says whether a testcase is jruby-friendly or not. Thoughts?

/cc @github/security

Hey guys, any way I can help with this? We're trying to auth against a PHP db that's using 2y. Getting bcrypt-ruby to handle 2y would really help.

Is this blocked waiting for a jBcrypt fix?

bump

Is this blocked waiting for a jBcrypt fix?

It's definitely not helping.

Any thoughts on what to do with the jBcrypt failures?

Optimally, the Java version could be updated to also account for 2x and 2y prefixes.

A "fork" of jBcrypt exists in the form of spring-security's BCrypt.java, but the changes have mostly just been to align it with Spring's styles, and not functionality updates.

Perhaps someone over there would be more willing to update the Java implementation (since Spring has some corporate backing), although I don't know that the original author has been contacted about updates either (unfortunate side affect of not being on GitHub for issues/PRs).

Also, unrelatedly, crypt_blowfish version 1.3 has since been released.

I've updated this PR to include crypt_blowfish v1.3

What's blocking this?

We just had the issue with reading data from PHP using 2y as well. It'd be nice to fix this.

What's happening here? This has been open for almost three years. What's going on?

@bf4 I'd love to help. What can I do?

@reedloden Are you still working on this?

@tmm1 @tjschuck Can one of you check and give some direction on what needs to be done to close this? I know it's super stale.. but it's

Guys, what needs to be done for this? I help in anyway I can. I need this!

I am also curious what the hold up is. I had to create my own fork/release of the gem with just this fix in and dropping support for jruby / rbx so that I could get this to work. I would much rather it be in the original gem

@dissolve From the sounds of this answer on stack overflow: https://stackoverflow.com/a/20981781 it sounds like you can just replace $2y with $2a and it will validate accordingly.

I gave it a quick test as I've just come across the same issue (migrating to ruby from a php app which stored the hash with a $2y prefix) and it seems to work. Code isn't pretty, but maybe this will tide people over for another 4 years...

  def password_correct?(password, current_passsword_hash)
    current_passsword_hash = current_passsword_hash.sub(/^.../, '$2a')
    BCrypt::Password.new(current_passsword_hash).is_password?(password)
  end

that works if its your code, the problem was that it was not my code and not something I wanted to delve into. it was far easier to change the installed gem to bcrypt4. still not something I should have to do.

Done in #182