JBCrypt is a serious problem with checkpw (return true if it is not?)

Question

EDIT: Okay, so I found the answer here BCrypt says that long similar passwords are equivalent - is it a problem with me, a gem or a cryptography field?

A new question, however, how can someone recommend using bCrypt for hashing if you need to limit the length of a user's password in a world where we are trying to educate users to choose more complex passwords, even a passphrase, saying that your password should be shorter than n characters seems like a way to get into thedailywtf.com screenshots Friday :)

Original question below:

I was reorganizing the old login page for the application and decided to give bCrypt a whirlwind using the java implementation of JAVA ( http://www.mindrot.org/projects/jBCrypt/ ) and ran into one major show stop.

The problem is the checkpw method, which always returns true when using a very long seed. I was about to salt the user's password with {InternalSalt} {username} {password}, ​​and then the hash using bCrypt.

So I have the following code (split it as much as possible to isolate checkpw).

public class Test { public static void main(String[] args) { String plaintext = "jw~ct/f61y1m7q458GiLVQpiqDK|8kG=d368Id: D@ $^_80I{qrn1HM6423{FtestAccountO1nu3jKN"; String pw_hash = BCrypt.hashpw(plaintext, BCrypt.gensalt()); if (BCrypt.checkpw("jw~ct/f61y1m7q458GiLVQpiqDK|8kG=d368Id: D@ $^_80I{qrn1HM6423{FtestAccountO1nu3jKN", pw_hash)) System.out.println("It matches"); else System.out.println("It does not match"); } 

}

It will, as it should be, type "It Matches."

The problem I am having is that you add say aaa to the password you pass to checkpw, making it

BCrypt.checkpw ("jw ~ ct / f61y1m7q458GiLVQpiqDK | 8kG = d368Id: D @ $ ^ _ 80I {qrn1HM6423 {FtestAccountO1nu3jKNaaa", pw_hash)

He is still returning the truth! Not quite what I expected. I do not see the password length limit in the document, but I cannot play it with a smaller password seed, it also looks like if I change anything else than the end of the line, it works, as expected, returns false.

Did I miss something important? I know that I should not be the only one using jBcrypt in this forum, as I have seen BCrypt recommended in many posts while doing some research.

EDIT: Windows 7 64 bit - Java (TM) SE runtime (build 1.6.0_24-b07)

Answer 1

Okay, so the wording of the question gave me enough to actually find out what I was looking for (cheers for the rubber duck ). Now the field of cryptography is safe!

an Xrypt BCOR implementation using P_orig, which is 18 4 bytes, until it reaches the end, which limits your encryption key to 72 bytes. Eveyrything after 72 bytes is ignored (warning would be nice).

What seems to be an accepted compromise is not to limit the user's password to 72 characters or less, but simply to let it pass in silence. The idea behind this is that 72 characters of bCrypted password is better than an alternative to fast hashing.

Source: BCrypt says long similar passwords are equivalent - is it a problem with me, a gem or a cryptography field?

Answer 2

Actually your own answer is excellent and helped me find an annoying problem;) there is a hint for people who added some kind of application secret to the regular one before hashing (even if they limit the password length): include the application secret at the end , especially if the application secret - 72 characters long - otherwise each click will return true !

so instead:

String hashed = BCrypt.hashpw(APP_SECRET + plain, BCrypt.gensalt()) hit>

using:

String hashed = BCrypt.hashpw(plain + APP_SECRET, BCrypt.gensalt())

Even if checkpw is checkpw , the result of checkpw will be valid!