Comprobación de Hash BCrypt

Para ayudar con los pasos de mitigación de CVE-2022-xxxx, puede utilizar esta herramienta para revisar su base de datos en busca de hashes que necesiten actualizarse.

Después de haber integrado la aplicación con su base de datos, la herramienta funciona en dos pasos.

Para demostrarlo, se utiliza una aplicación de muestra en memoria. En esa aplicación de muestra, puede ejecutar el paso check, así:

./mvnw spring-boot:run@check

Esto revisará la base de datos de muestra para detectar cualquier hash BCrypt que necesite actualizarse.

Luego, puede ejecutar el paso update, así:

./mvnw spring-boot:run@update

Esto intentará actualizar cualquier hash vulnerable que detecte en la base de datos de muestra.

La aplicación de muestra utiliza la clase proporcionada VulnerabilityCheck para verificar y actualizar cada hash de contraseña.

Configurando para su base de datos

ADVERTENCIA: Continúe con estos pasos solo después de haber actualizado su aplicación para usar un número de rondas inferior a 31. OWASP recomienda actualmente un valor de 10, aunque en algunos sistemas de alta potencia se utilizan valores de hasta 16.

La herramienta incluye una muestra en memoria con fines de prueba. Deberá reemplazarla con clases propias que se integren con sus datos.

Para ello, primero clone este repositorio.

Luego, reemplace el código en el paquete sample con código que pueda acceder a los datos de contraseñas en su aplicación. Es posible que desee escribir código que verifique las contraseñas existentes para ver si son vulnerables. Querrá codificar la actualización de cualquier hash afectado. En ambos casos, puede usar VulnerabilityCheck para verificar y actualizar un hash dado.

CONSEJO: Al escribir el código anterior, tenga en cuenta cuántas contraseñas debe actualizar. Recuerde considerar que la conexión a la base de datos puede fallar, las computadoras pueden bloquearse, la memoria puede agotarse, etc. No es recomendable, por ejemplo, cargar millones de registros a la vez en memoria.

Después de actualizar los hashes de contraseña, ahora puede actualizar a la última versión de Spring Security. Si está utilizando la función de actualización de contraseñas de Spring Security, a medida que los usuarios inicien sesión, su contraseña se volverá a generar automáticamente con el nuevo valor de rondas que haya configurado.

Preguntas frecuentes

P: ¿Cómo sé si mis hashes son vulnerables?

R: Son vulnerables si se generaron con la clase BCrypt de Spring Security con un factor de trabajo de 31. Puede confirmarlo revisando los hashes de contraseña en su sistema que son gestionados por Spring Security. Si comienzan con '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' o '$2$31', entonces esa contraseña es vulnerable y debe actualizarse.

P: ¿Cómo debería cambiar mi aplicación?

R: OWASP recomienda un factor de trabajo de 10 para BCrypt. Algunos sistemas de mayor potencia usarán un valor de hasta 16. Cada sistema es diferente y BCrypt está diseñado para poder aumentar el factor de trabajo con el tiempo según sea necesario.

P: ¿Dónde cambio mi aplicación?

R: Es probable que esté configurando el factor de trabajo construyendo un BCryptPasswordEncoder así:

new BCryptPasswordEncoder(31)

Puede aparecer en una definición de bean como esta:

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(31);
}

Puede buscar esa cadena y actualizarla. Tenga en cuenta que el factor de trabajo podría estar controlado en su aplicación por una propiedad externa, lo que significaría que querrá cambiarlo en su configuración externa en su lugar.

P: Acabo de actualizar Spring Security y ahora algunos o todos los inicios de sesión y registros de usuarios se quedan colgados. ¿Qué sucedió?

R: A partir de Spring Security 5.5.7+, 5.6.4+, 5.7.0+, los hashes de contraseña que indican un factor de trabajo de 31 -- por ejemplo, los que comienzan con '{bcrypt}$2a$31', '{bcrypt}$2b$31', '{bcrypt}$2y$31', '{bcrypt}$2$31', '$2a$31', '$2b$31', '$2y$31' o '$2$31' -- tardarán de 2 a 3 días en completar cada cálculo de hash. Para aliviar esto, deberá cambiar Spring Security para que use un número de rondas menor. Luego, use esta herramienta para actualizar los hashes de contraseña vulnerables.

P: He completado los tres pasos recomendados (cambiar la configuración de BCryptPasswordEncoder, actualizar los hashes de contraseña y actualizar Spring Security). Los hashes de contraseña modificados no se están actualizando a mi nuevo factor de trabajo configurado. ¿Qué debería hacer?

Asegúrese de tener publicado un bean de tipo UserDetailsPasswordService. Ese bean es el que se utiliza para actualizar las contraseñas a un nuevo número de rondas de registro de BCrypt.

P: ¿Por qué Spring Security no puede simplemente actualizar las contraseñas vulnerables en el momento de la actualización sin necesidad de esta herramienta?

Primero, porque con la última versión de Spring Security, los hashes de contraseña con un factor de trabajo de 31 se calculan correctamente y, por lo tanto, tardan de 2 a 3 días en completar cada uno. Es una expectativa poco práctica suponer que este es un costo razonable para que las aplicaciones lo asuman.

Segundo, Spring Security solo admite aumentar el factor de trabajo (por ejemplo, de 10 a 12), no disminuirlo (por ejemplo, de 31 a 10).