jBCrypt problema grave con checkpw (return true cuando no debería?)

Question

EDIT: Ok, así que he encontrado un poco una respuesta aquí BCrypt says long, similar passwords are equivalent - problem with me, the gem, or the field of cryptography?

Nueva pregunta, sin embargo, ¿cómo puede alguien recomendar el uso de Bcrypt de hash si tiene limitar la longitud de la contraseña del usuario en un mundo en el que tratamos de educar a los usuarios para elegir contraseñas cada vez más complejas, incluso frase de contraseña, diciendo que su contraseña debe ser más corta que n caracteres parece una manera de terminar en thedailywtf.com capturas de pantalla del viernes :)

pregunta original a continuación:

estoy refactorización una vieja entrada página para una aplicación y decidió dar un vuelco a bCrypt usando la implementación de JAVA jBCrypt (http://www.mindrot.org/projects/jBCrypt/) y se encontró con un stop show importante.

El problema está en el método checkpw que siempre parece ser cierto cuando se usa una semilla muy larga. Iba a saltear la contraseña del usuario con {InternalSalt} {username} {password} y luego hash eso con bCrypt.

Así que tengo el siguiente código (desglosado tanto como sea posible para aislar 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"); 

} 

}

Esto, como debe ser, de impresión "de que coincide".

problema que estoy teniendo es que dice que dice Añadir aaa con la contraseña que pasan a checkpw por lo que es

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

¡Sigue siendo cierto! No es exactamente lo que esperaba. No veo ninguna limitación de longitud de la contraseña en el documento, pero no puedo reproducirlo con una contraseña más pequeña, también parece que si modifico algo más que el final de la cadena funciona como se esperaba devolviendo el valor falso.

¿Echo de menos algo importante? Sé que no debo ser el único que use jBcrypt en estos foros, ya que he visto que BCrypt recomendaba en muchas publicaciones mientras hacía una investigación.

EDIT: Windows 7 64 bits - Java (TM) SE Runtime Environment (build 1.6.0_24-b07)

Answer 1

Ok, así que la cuestión redacción me dio lo suficiente como para entender realmente lo que estaba buscando (hurra para rubber ducking). ¡El campo de la criptografía está a salvo por ahora!

Implementación de BCrypt XOR usando P_orig que es un entero de 18 4 bytes hasta que llega al final, lo que limita su "clave" de cifrado a 72 bytes. Se ignora todo después de 72 bytes (una advertencia habría sido agradable).

lo que parece ser aceptado el compromiso no es limitar la contraseña del usuario a 72 caracteres o menos, sino simplemente dejarlo pasar en silencio. La idea detrás de esto es que una contraseña de 72 caracteres bCrypted es mejor que la alternativa de hash rápido de todos modos.

Fuente: BCrypt says long, similar passwords are equivalent - problem with me, the gem, or the field of cryptography?

Answer 2

En realidad su propia respuesta es gran y me ayudó a encontrar edición molesta;) hay algunos consejos y recomendaciones para las personas que añade algún tipo de de aplicación secreto a simple antes de hash (incluso si limitan la longitud de la contraseña): incluya la aplicación secreta en el extremo, especialmente si el secreto de la aplicación es de 72 caracteres de longitud; de lo contrario, cada acierto devolverá true.

así que en vez:

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

uso:

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

Incluso si el recorte de Bcrypt se producirá el resultado checkpw será válido!