Estoy trabajando en un sistema de registro y autenticación de PHP siguiendo el estándar salt + password = 'auth hash' y usando el nombre de usuario de texto simple / sin cifrar como el campo de búsqueda en la consulta inicial. Para el propósito de esta pregunta, supongamos que también estoy usando un chile global (es probable que agregue uno antes de terminar, así que supongamos que ya lo he hecho).
Algo me pareció un concepto quizás interesante. Me doy cuenta de que dicen " no reinventar la rueda cuando se trata de seguridad ", pero estaba considerando permitir un número de iteraciones 'especificadas por el usuario' para PBKDF2.
Ahora, no quiero decir que el usuario tenga control sobre el número de iteraciones, sino que se genera un número aleatorio entre X e Y en tiempo de ejecución y luego ese valor se almacena, en texto plano, como un campo separado en La base de datos de la misma manera que almacenaría la sal. Entiendo que el algoritmo ya se considera extremadamente seguro y sencillo de implementar, pero creo que una "capa" adicional dificultaría aún más la tarea de un atacante.
En aras de la simplicidad (y la continuidad con el uso de alimentos), llamemos "salsa" al recuento de iteraciones aleatorias. Como ejemplo;
- Pepper ya está en DB y se recupera a una variable
- El usuario se registra con nombre de usuario y contraseña
- Se genera sal
- La salsa se genera y debe estar entre 16000 y 32000 iteraciones ( números teóricos )
- El hash se genera a partir de sal + contraseña + salsa + pimienta
- El nombre de usuario, el hash, la sal y la salsa se almacenan en el DB
Dado que 'salsa' se almacena como texto simple, su propio algoritmo sería adaptable basado en lo que está almacenado en la base de datos (al igual que con sal), e incluso más al punto, elegir un número entre X e Y generalmente es bastante rápido.
Nuevamente, no me preocupa que un atacante pueda romper una clave de salida de 512 bits de hash SHA512 que haya pasado por 32000 iteraciones (número de ejemplo) y tenga sal y pimienta dentro de un período de tiempo razonable, y ciertamente no podrían No generes una mesa de arcoiris contra ella. Estoy más interesado en la posibilidad de que podamos ampliar el diseño aún más, con relativa facilidad, con muy pocos gastos generales adicionales en el lado de los "defensores", pero agregando más gastos generales al lado de los atacantes, lo que puede disuadirlos por completo y sin necesidad de adaptarse el propio algoritmo de hash.
Usted establece sus propios conteos de iteraciones mínimas y máximas dentro del rango de lo que su entorno puede manejar y, por lo tanto, aún mantiene un control significativo sobre la seguridad relativa del sistema, y nunca permite que sus usuarios finales especifiquen su propio valor (para el rendimiento razones, y por la razón es probable que seleccionen algo memorable anulando completamente su paso adicional, y por hacer un buen UX). En entornos donde la seguridad es de suma importancia, seguramente tener estos pequeños pasos adicionales en el camino funcionaría en beneficio de los defensores.
¿Tener este nivel adicional no proporcionaría otro aro para que un atacante lo atraviese? ¿Pensamientos?