Por qué SHA-256 no es suficiente para almacenar contraseñas

Hashination no es un cifrado. El cifrado se puede descifrar con la clave correcta. La función atajo no ofrece una operación analógica inversa. Sin embargo, esto no significa que la contraseña guardada como un atajo permanece fuera del alcance del atacante.

Después de la filtración, el atacante puede adivinar las contraseñas localmente: calcular el resultado para cada propuesta y compararlo con el registro robado. Al mismo tiempo, no tiene que pasar por el límite de sus intentos de inicio de sesión de aplicación.

La velocidad de SHA se convierte en un defecto

SHA-256 es perfecto para muchas aplicaciones criptográficas, incluyendo la comprobación de integridad. Está diseñado para el procesamiento rápido de datos. Sin embargo, para almacenar contraseñas queremos que cada intento de costar los recursos notables del atacante.

Agregar sal a SHA256(sól + hasło) no resuelve el problema de la velocidad. Sal y costo del cálculo cumplen diferentes roles. No sustituya la función especializada con su propio bucle de acceso directo o diseñe su propio formato de certificaciones.

Utilice la biblioteca para contraseñas de hash

Para la nueva solución OWASP indica Argon2id como opción preferida. Scrypt es una alternativa cuando Argon2id no está disponible. PBKDF2 se aplica entre otras cosas en entornos con requisitos específicos de cumplimiento. BCrypt es necesario en sistemas antiguos, pero tiene limitaciones, incluyendo la longitud de entrada.

Seleccione la biblioteca mantenida con las funciones de creación y escritura de verificación. Debe apoyar la generación de sal y el almacenamiento de parámetros. Seleccione los parámetros de coste según las recomendaciones y mediciones actuales en el servidor objetivo, teniendo en cuenta los logins paralelos y los límites de recursos.

El alto costo de una operación no debe permitir la sobrecarga fácil del servicio. La protección en línea todavía requiere reducción de las pruebas y el control de carga.

Sal, parámetros y pimienta

Salt es un valor aleatorio para cada registro. No tiene que ser secreto. Gracias a ello, las mismas contraseñas no dan entradas idénticas, y el trabajo realizado para un registro no se mueve directamente a todos los demás.

En la base de datos, también mantiene el identificador del algoritmo y los parámetros necesarios para la verificación. Las bibliotecas a menudo las colocan juntas en una cadena codificada.

Pepper Este es un secreto extra opcional almacenado fuera de la base de datos de contraseña. Puede ayudar en escenarios específicos de derrame, pero hace que la gestión clave y la rotación difícil. No es un sustituto de la sal o la función de hash adecuada.

¿Cómo aumentas los costos sin conocer contraseñas?

Al iniciar sesión con éxito, la aplicación tiene una contraseña dada por el usuario. Primero lo verifica de acuerdo con el registro antiguo y luego, si los parámetros están fuera de fecha, crea un nuevo registro con la configuración actual. Este es un momento típico para rehash.

Usted no recuperará la contraseña original del atajo actual para recalcular toda la base de datos. Para cuentas que no regresen al servicio, se necesita una política de migración separada o reajuste.

Antes de implementar, comprobar el rechazo de la contraseña incorrecta, la migración del registro antiguo, los límites de longitud y el comportamiento de carga. No inicie sesión en las contraseñas o enviarlas a herramientas analíticas durante estas pruebas.