Me encontré con una discusión en la que aprendí que lo que había estado haciendo no era, de hecho, sazonar contraseñas, sino salpicarlas, y desde entonces comencé a hacer ambas cosas con una función como:

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

Ignorando el algoritmo hash elegido (quiero que esto sea una discusión de sales y pimientos y no algoritmos específicos, pero estoy usando uno seguro), ¿es esta una opción segura o debería hacer algo diferente? Para aquellos que no están familiarizados con los términos:

• Una sal es un valor generado aleatoriamente que generalmente se almacena con la cadena en la base de datos diseñada para hacer imposible el uso de tablas hash para descifrar contraseñas. Como cada contraseña tiene su propia sal, todas deben ser forzadas individualmente para poder descifrarlas; sin embargo, como la sal se almacena en la base de datos con el hash de la contraseña, un compromiso de la base de datos significa perder ambos.

• Un pimiento es un valor estático de todo el sitio almacenado por separado de la base de datos (generalmente codificado en el código fuente de la aplicación) que está destinado a ser secreto. Se utiliza para que un compromiso de la base de datos no provoque la fuerza bruta de toda la tabla de contraseñas de la aplicación.

¿Hay algo que me esté perdiendo y es la mejor opción para proteger la seguridad de mi usuario de poner sal y salpicar mis contraseñas? ¿Existe alguna falla de seguridad potencial al hacerlo de esta manera?

Nota: Para el propósito de la discusión, suponga que la aplicación y la base de datos se almacenan en máquinas separadas, no comparten contraseñas, etc., por lo que una violación del servidor de la base de datos no significa automáticamente una violación del servidor de la aplicación.

Está bien. Dado que necesito escribir sobre esto una y otra vez , haré una última respuesta canónica solo sobre la pimienta.

La aparente ventaja de los pimientos

Parece bastante obvio que los pimientos deberían hacer que las funciones de hash sean más seguras. Quiero decir, si el atacante solo obtiene su base de datos, entonces las contraseñas de sus usuarios deberían ser seguras, ¿verdad? Parece lógico, ¿verdad?

Por eso mucha gente cree que los pimientos son una buena idea. Que tiene sentido".

La realidad de los pimientos

En los ámbitos de la seguridad y la criptografía, "tener sentido" no es suficiente. Algo tiene que ser demostrable y tener sentido para que se considere seguro. Además, tiene que ser implementable de forma sostenible. El sistema más seguro que no se puede mantener se considera inseguro (porque si alguna parte de esa seguridad falla, todo el sistema se derrumba).

Y los pimientos no encajan ni en los modelos demostrables ni sostenibles ...

Problemas teóricos con los pimientos

Ahora que hemos preparado el escenario, veamos qué está mal con los pimientos.

• Introducir un hachís en otro puede ser peligroso.

  En tu ejemplo, lo haces .hash_function($salt . hash_function($pepper . $password))

  Sabemos por experiencias pasadas que "simplemente introducir" un resultado de hash en otra función de hash puede disminuir la seguridad general. La razón es que ambas funciones hash pueden convertirse en un objetivo de ataque.

  Es por eso que algoritmos como PBKDF2 usan operaciones especiales para combinarlos (hmac en ese caso).

  El punto es que si bien no es gran cosa, tampoco es algo trivial para tirarlo. Los sistemas criptográficos están diseñados para evitar casos "deberían funcionar" y, en cambio, se centran en casos "diseñados para funcionar".

  Si bien esto puede parecer puramente teórico, de hecho no lo es. Por ejemplo, Bcrypt no puede aceptar contraseñas arbitrarias . Entonces, pasar bcrypt(hash(pw), salt)puede resultar en un hash mucho más débil que bcrypt(pw, salt)si hash()devuelve una cadena binaria.

• Trabajando contra el diseño

  La forma en que se diseñó bcrypt (y otros algoritmos de hash de contraseñas) es para trabajar con una sal. El concepto de pimiento nunca se introdujo. Esto puede parecer una trivialidad, pero no lo es. La razón es que una sal no es un secreto. Es solo un valor que puede ser conocido por un atacante. Por otro lado, un pimiento, por definición, es un secreto criptográfico.

  Los algoritmos de hash de contraseñas actuales (bcrypt, pbkdf2, etc.) están diseñados para aceptar solo un valor secreto (la contraseña). Agregar otro secreto al algoritmo no se ha estudiado en absoluto.

  Eso no significa que no sea seguro. Significa que no sabemos si es seguro. Y la recomendación general sobre seguridad y criptografía es que si no lo sabemos, no lo es.

  Entonces, hasta que los criptógrafos diseñen y examinen los algoritmos para usarlos con valores secretos (pimientos), los algoritmos actuales no deben usarse con ellos.

• La complejidad es el enemigo de la seguridad

  Lo crea o no, la complejidad es el enemigo de la seguridad . Hacer un algoritmo que parezca complejo puede ser seguro o puede que no lo sea. Pero hay muchas posibilidades de que no sea seguro.

Problemas importantes con los pimientos

• No es mantenible

  Su implementación de pimientos excluye la capacidad de rotar la tecla de pimiento. Dado que el pimiento se usa en la entrada de la función unidireccional, nunca puede cambiar el pimiento durante la vida útil del valor. Esto significa que necesitaría idear algunos trucos inútiles para que admita la rotación de claves.

  Esto es extremadamente importante ya que es necesario cada vez que almacena secretos criptográficos. No tener un mecanismo para rotar claves (periódicamente y después de una infracción) es una gran vulnerabilidad de seguridad.

  Y su enfoque de pimienta actual requeriría que cada usuario tenga su contraseña completamente invalidada por una rotación, o espere hasta su próximo inicio de sesión para rotar (que puede ser nunca) ...

  Lo que básicamente hace que su enfoque sea un no-go inmediato.

• Requiere que lances tu propia criptografía

  Dado que ningún algoritmo actual respalda el concepto de un pimiento, requiere que usted componga algoritmos o invente otros nuevos para respaldar un pimiento. Y si no puede ver de inmediato por qué eso es algo realmente malo:

  Cualquiera, desde el aficionado más despistado hasta el mejor criptógrafo, puede crear un algoritmo que él mismo no pueda romper.

  • Bruce Schneier

  NUNCA lanza tu propia criptografía ...

La mejor manera

Entonces, de todos los problemas detallados anteriormente, hay dos formas de manejar la situación.

• Simplemente use los algoritmos tal como existen

  Si usa bcrypt o scrypt correctamente (con un alto costo), todas las contraseñas de diccionario, excepto las más débiles, deberían ser estadísticamente seguras. El récord actual de hash bcrypt al costo 5 es 71k hash por segundo. A ese ritmo, incluso una contraseña aleatoria de 6 caracteres tardaría años en descifrarse. Y considerando que mi costo mínimo recomendado es 10, eso reduce los hashes por segundo en un factor de 32. Así que estaríamos hablando solo de 2200 hashes por segundo. A ese ritmo, incluso algunas frases del diccionario o modificaciones pueden ser seguras.

  Además, deberíamos buscar esas clases débiles de contraseñas en la puerta y no permitirles entrar. A medida que el descifrado de contraseñas se vuelve más avanzado, también deberían hacerlo los requisitos de calidad de las contraseñas. Sigue siendo un juego estadístico, pero con una técnica de almacenamiento adecuada y contraseñas seguras, todos deberían estar prácticamente muy seguros ...

• Cifre el hash de salida antes del almacenamiento

  Existe en el ámbito de la seguridad un algoritmo diseñado para manejar todo lo que hemos dicho anteriormente. Es un cifrado en bloque. Es bueno, porque es reversible, por lo que podemos rotar las teclas (¡yay! ¡Mantenibilidad!). Es bueno porque se está utilizando según lo diseñado. Es bueno porque no le da información al usuario.

  Miremos esa línea de nuevo. Digamos que un atacante conoce su algoritmo (que es necesario para la seguridad, de lo contrario, es seguridad a través de la oscuridad). Con un enfoque tradicional de pimienta, el atacante puede crear una contraseña centinela y, dado que conoce la sal y la salida, puede usar la fuerza bruta de la pimienta. Ok, eso es una posibilidad remota, pero es posible. Con un cifrado, el atacante no obtiene nada. Y dado que la sal es aleatoria, una contraseña centinela ni siquiera le ayudará. Así que lo mejor que les queda es atacar la forma cifrada. Lo que significa que primero tienen que atacar su hash cifrado para recuperar la clave de cifrado y luego atacar los hash. Pero hay mucha investigación sobre el ataque de cifrados, por lo que queremos confiar en eso.

TL / DR

No uses pimientos. Hay una serie de problemas con ellos, y hay dos formas mejores: no usar ningún secreto del lado del servidor (sí, está bien) y encriptar el hash de salida usando un cifrado de bloque antes del almacenamiento.

Primero deberíamos hablar de la ventaja exacta de un pimiento :

• El pimiento puede proteger contraseñas débiles de un ataque de diccionario, en el caso especial, donde el atacante tiene acceso de lectura a la base de datos (que contiene los hash) pero no tiene acceso al código fuente con el pimiento.

Un escenario típico sería la inyección de SQL, las copias de seguridad desechadas, los servidores desechados ... Estas situaciones no son tan infrecuentes como parece y, a menudo, no están bajo su control (servidor de alojamiento). Si utiliza...

• Una sal única por contraseña
• Un algoritmo de hash lento como BCrypt

... las contraseñas seguras están bien protegidas. Es casi imposible forzar una contraseña segura en esas condiciones, incluso cuando se conoce la sal. El problema son las contraseñas débiles, que forman parte de un diccionario de fuerza bruta o son derivaciones de ellas. Un ataque de diccionario los revelará muy rápido, porque solo prueba las contraseñas más comunes.

La segunda pregunta es ¿cómo aplicar el pimiento ?

Una forma a menudo recomendada de aplicar un pimiento es combinar la contraseña y el pimiento antes de pasarlo a la función hash:

$pepperedPassword = hash_hmac('sha512', $password, $pepper); $passwordHash = bcrypt($pepperedPassword);

Sin embargo, hay otra forma aún mejor:

$passwordHash = bcrypt($password); $encryptedHash = encrypt($passwordHash, $serverSideKey);

Esto no solo permite agregar un secreto del lado del servidor, sino que también permite intercambiar $ serverSideKey, en caso de que sea necesario. Este método implica un poco más de trabajo, pero si el código existe una vez (biblioteca), no hay razón para no usarlo.

El punto de la sal y la pimienta es aumentar el costo de una búsqueda de contraseña precalculada, llamada tabla de arco iris.

En general, tratar de encontrar una colisión para un solo hash es difícil (asumiendo que el hash es seguro). Sin embargo, con hashes cortos, es posible usar la computadora para generar todos los hash posibles en una búsqueda en un disco duro. A esto se le llama Mesa Arcoiris. Si crea una tabla de arco iris, puede salir al mundo y encontrar rápidamente contraseñas plausibles para cualquier hash (sin sal y sin pimienta).

El objetivo de un pimiento es hacer que la tabla de arcoíris necesaria para piratear su lista de contraseñas sea única. Perdiendo así más tiempo al atacante para construir la mesa del arco iris.

Sin embargo, el objetivo de la sal es hacer que la tabla de arcoíris para cada usuario sea única para el usuario, lo que aumenta aún más la complejidad del ataque.

Realmente, el objetivo de la seguridad informática es casi nunca hacerla (matemáticamente) imposible, solo matemática y físicamente impráctica (por ejemplo, en sistemas seguros se necesitaría toda la entropía del universo (y más) para calcular la contraseña de un solo usuario).

Quiero que esto sea una discusión sobre sales y pimientos y no algoritmos específicos, pero estoy usando uno seguro

Cada función de hash de contraseña segura que conozco toma la contraseña y la sal (y el secreto / pimienta si es compatible) como argumentos separados y hace todo el trabajo por sí misma.

Simplemente por el hecho de que está concatenando cadenas y que hash_functionsolo toma un argumento, sé que no está utilizando uno de esos algoritmos estándar bien probados y analizados, sino que está tratando de desarrollar el suyo. No hagas eso.

Argon2 ganó el Concurso de hash de contraseñas en 2015 y, hasta donde yo sé, sigue siendo la mejor opción para nuevos diseños. Admite pimienta a través del parámetro K (llamado "valor secreto" o "clave"). No conozco ninguna razón para no usar pimienta. En el peor de los casos, la pimienta se verá comprometida junto con la base de datos y no estará peor que si no la hubiera usado.

Si no puede usar el soporte de pimienta incorporado, puede usar una de las dos fórmulas sugeridas de esta discusión :

Argon2(salt, HMAC(pepper, password))   or   HMAC(pepper, Argon2(salt, password))

Nota importante: si pasa la salida de HMAC (o cualquier otra función de hash) a Argon2 (o cualquier otra función de hash de contraseña), asegúrese de que la función de hash de contraseña admita cero bytes incrustados o codifique el valor hash (por ejemplo, en base64 ) para asegurarse de que no haya bytes cero. Si está utilizando un idioma cuyas cadenas admiten cero bytes incrustados, probablemente esté seguro, a menos que ese idioma sea PHP , pero lo comprobaría de todos modos.

No veo que almacenar un valor codificado en su código fuente tenga relevancia para la seguridad. Es seguridad a través de la oscuridad.

Si un pirata informático adquiere su base de datos, podrá comenzar a forzar brutalmente sus contraseñas de usuario. Ese hacker no tardará en identificar su pimienta si logra descifrar algunas contraseñas.