En criptografía , un pepper es un secreto añadido a una entrada como una contraseña durante el hash con una función hash criptográfica . Este valor se diferencia de una sal en que no se almacena junto con un hash de contraseña, sino que el pepper se mantiene separado en algún otro medio, como un módulo de seguridad de hardware. [1] Tenga en cuenta que el Instituto Nacional de Estándares y Tecnología se refiere a este valor como una clave secreta en lugar de un pepper . Un pepper es similar en concepto a una sal o una clave de cifrado . Es como una sal en que es un valor aleatorio que se agrega a un hash de contraseña, y es similar a una clave de cifrado en que debe mantenerse en secreto.
Un pepper cumple una función comparable a una sal o una clave de cifrado , pero mientras que una sal no es secreta (simplemente única) y se puede almacenar junto con la salida en hash, un pepper es secreto y no debe almacenarse con la salida. El hash y la sal suelen almacenarse en una base de datos, pero un pepper debe almacenarse por separado para evitar que el atacante lo obtenga en caso de una violación de la base de datos. [2] Donde la sal solo tiene que ser lo suficientemente larga para ser única por usuario [ dudoso - discutir ] , un pepper debe ser lo suficientemente largo para permanecer secreto de los intentos de fuerza bruta para descubrirlo (NIST recomienda al menos 112 bits).
La idea de una sal específica de un sitio o servicio (además de una sal por usuario) tiene una larga historia, con Steven M. Bellovin proponiendo un parámetro local en una publicación de Bugtraq en 1995. [3] En 1996, Udi Manber también describió las ventajas de un esquema de este tipo, denominándolo sal secreta . [4] El término pepper se ha utilizado, por analogía con salt, pero con una variedad de significados. Por ejemplo, cuando se habla de un esquema de desafío-respuesta , pepper se ha utilizado para una cantidad similar a salt, aunque no se ha utilizado para el almacenamiento de contraseñas; [5] se ha utilizado para una técnica de transmisión de datos donde se debe adivinar un pepper; [6] e incluso como parte de bromas. [7]
El término pepper fue propuesto para un secreto o parámetro local almacenado por separado de la contraseña en una discusión sobre la protección de contraseñas de ataques de tabla arco iris . [8] Este uso no tuvo éxito de inmediato: por ejemplo, Fred Wenzel agregó soporte al hash de contraseñas de Django para almacenamiento basado en una combinación de bcrypt y HMAC con nonces almacenados por separado , sin usar el término. [9] Desde entonces, su uso se ha vuelto más común. [10] [11] [12]
Existen varios tipos diferentes de pimienta:
En el caso de un pepper de secreto compartido, una única contraseña comprometida (mediante la reutilización de contraseñas u otro ataque) junto con el salt de un usuario pueden dar lugar a un ataque para descubrir el pepper, volviéndolo ineficaz. Si un atacante conoce una contraseña en texto plano y el salt de un usuario, así como el algoritmo utilizado para codificar la contraseña, descubrir el pepper puede ser una cuestión de fuerza bruta para los valores del pepper. Por eso, el NIST recomienda que el valor secreto sea de al menos 112 bits, de modo que descubrirlo mediante una búsqueda exhaustiva sea imposible. El pepper debe generarse de nuevo para cada aplicación en la que se implementa, de lo contrario, una violación de una aplicación daría como resultado una menor seguridad de otra aplicación. Sin el conocimiento del pepper, será mucho más difícil extraer otras contraseñas de la base de datos a partir de sus valores codificados, ya que el atacante tendría que adivinar la contraseña además del pepper.
Un pepper añade seguridad a una base de datos de sales y hashes porque, a menos que el atacante pueda obtener el pepper, descifrar incluso un único hash es imposible, sin importar lo débil que sea la contraseña original. Incluso con una lista de pares (salt, hash), un atacante también debe adivinar el pepper secreto para encontrar la contraseña que produce el hash. La especificación NIST para un salt secreto sugiere usar una Función de Derivación de Clave Basada en Contraseña (PBKDF) con una Función Pseudoaleatoria aprobada como HMAC con SHA-3 como la función hash del HMAC. La recomendación NIST también es realizar al menos 1000 iteraciones del PBKDF, y un mínimo adicional de 1000 iteraciones usando el salt secreto en lugar del salt no secreto.
En el caso de un pepper que es único para cada usuario, la contrapartida es ganar seguridad adicional a costa de almacenar más información de forma segura. Poner en peligro un hash de contraseña y revelar su pepper secreto no tendrá ningún efecto sobre otros hashes de contraseña y su pepper secreto, por lo que cada pepper debe descubrirse individualmente, lo que aumenta enormemente el tiempo necesario para atacar los hashes de contraseña.
... los verificadores DEBERÍAN realizar una iteración adicional de una operación de cifrado o hash con clave utilizando una clave secreta conocida solo por el verificador.
La mayoría de la gente le echa sal al hachís. Bruce le echa sal y pimienta al suyo.