¿Qué usar para el hash de contraseñas? ¿Alguna razón para no usar jBCrypt?

Question

Estoy planeando usar jBCrypt para el hash de contraseñas en una nueva aplicación web, ya que se supone que es el mejor de lo que he leído. Como no lo he usado antes, estoy investigando si hay alguna razón para no usarlo.

tengo esto:

• no he encontrado que en el repositorio de Maven (buscado jbcrypt y bcrypt en mvnrepository.org), que es una decepción ya que me gusta tener mis dependencias gestionan mediante un repositorio de Maven si es posible. Si jBCrypt es la mejor solución para la creación de contraseñas, tendré que configurar mi propio repositorio local y tenerlo disponible de esa manera. ¿O simplemente me lo perdí? Tal vez está allí en alguna parte?
• Está solo en la versión 0.2, pero ¿tal vez es estable de todos modos y el motivo de un número de versión bajo tiene alguna otra causa?

Answer 1

jBcrypt está probablemente bien como algoritmo de cifrado para sus contraseñas; pez globo es relativamente fuerte. Aunque se han reportado fallas de implementación en Blowfish, no encuentro mucho reportado sobre jBcrypt. Por otro lado, Blowfish no se ha probado con tanta intensidad como otros algoritmos, y un ataque de texto plano conocido como crack a menudo funciona mejor de lo esperado, lo que sorprende a los geeks de crypto.

Así que aquí es lo que me gustaría sugerir:

• seguir adelante y utilizar jBcrypt pero proteger sus archivos de contraseñas cifradas en la medida en que razonablemente puede - como se puede usar/etc/shadow en un sistema UNIX.
• Contrariamente a la sugerencia de Nikhil, I inserta las fuentes en el control de su versión, por dos razones: (1) ¿dónde más podría guardarlas, ya que las necesita cada vez que construya, y (2) porque siempre oportunidad la persona que hace jBcrypt pasará a otras cosas, y no querrá encontrarse colgado justo antes de una entrega (que es inevitable cuando lo descubriría). En este tipo de situación, me gustaría ponga las fuentes en el control de su versión como si fueran su código, y luego podrá insertar cualquier cambio como si hubiera creado una nueva versión usted mismo. No es necesario que sea más complicado de lo que normalmente sería.

Answer 2

Dudo que la estabilidad vaya a ser un problema, ya que el bcrypt en sí mismo es maduro y sus envoltorios pequeños y estandarizados no hacen nada extraordinario. Estoy contento con el otro envoltorio bcrypt de Damien Miller, python-bcrypt, que solo está en la versión 0.1.

No estoy familiarizado con Maven, pero (¡alerta de herejía!) Dudo que necesites el control de versión para un componente tan simple como bcrypt. Para citar el sitio, los cambios de v0.1 a v0.2 fueron "correcciones, errores tipográficos y de API (completamente compatibles con versiones anteriores)", y la lista de TODO está vacía.

Answer 3

En cuanto a su preocupación de que no es maduro, yo iba a sugerir que configure sus propias pruebas JUnit que comparan los resultados de jBcrypt y la Bcrypt más probada, para ver si se obtienen los mismos resultados, y luego, contribuya con aquellos al proyecto jBcrypt.

Pero eso ya se ha hecho:

...se envía con un conjunto de unidades JUnit pruebas para verificar el funcionamiento correcto de la biblioteca y la compatibilidad con la implementación C canónica del algoritmo 0cbcrypt.

Examinando las pruebas JUnit para ver si cumplen con su nivel de satisfacción es donde me gustaría empezar ...