La necesidad de esconder la sal para hacer un hachís
En el trabajo tenemos dos teorías en competencia sobre las sales. Los productos en los que trabajo utilizan algo como un nombre de usuario o un número de teléfono para salar el hachís. Básicamente, algo que es diferente para cada usuario pero que está disponible para nosotros. El otro producto genera aleatoriamente un salt para cada usuario y cambia cada vez que el usuario cambia la contraseña. Luego, la sal se cifra en la base de datos.
Mi pregunta es si el segundo enfoque es realmente necesario. Puedo entender desde una perspectiva puramente teórica que es más seguro que el primer enfoque, pero ¿qué pasa desde un punto de vista práctico? En este momento, para autenticar a un usuario, el salt debe estar descifrado y aplicado a la información de inicio de sesión.
Después de pensarlo, simplemente no veo una ganancia real en seguridad con este enfoque. Cambiar la sal de una cuenta a otra aún hace que sea extremadamente difícil para alguien intentar aplicar fuerza bruta al algoritmo hash, incluso si el atacante sabía cómo determinar rápidamente cuál era para cada cuenta. Esto se basa en el supuesto de que las contraseñas sean lo suficientemente seguras. (Obviamente, encontrar el hash correcto para un conjunto de contraseñas donde todas tienen dos dígitos es significativamente más fácil que encontrar el hash correcto de contraseñas que tienen 8 dígitos). ¿Estoy equivocado en mi lógica o hay algo que me falta?
EDITAR: Bien, aquí está la razón por la que creo que es realmente discutible cifrar la sal. (Déjame saber si estoy en el camino correcto).
Para la siguiente explicación, asumiremos que las contraseñas siempre tienen 8 caracteres y la sal es 5 y que todas las contraseñas están compuestas por letras minúsculas (simplemente facilita las matemáticas).
Tener una sal diferente para cada entrada significa que no puedo usar la misma tabla de arcoíris (en realidad, técnicamente podría hacerlo si tuviera una del tamaño suficiente, pero ignorémoslo por el momento). Esta es la verdadera clave de la sal, según tengo entendido, porque para descifrar cada cuenta tengo que reinventar la rueda, por así decirlo, para cada una. Ahora bien, si sé cómo aplicar el salt correcto a una contraseña para generar el hash, lo haría porque un salt en realidad simplemente extiende la longitud/complejidad de la frase hash. Entonces, estaría reduciendo la cantidad de combinaciones posibles que necesitaría generar para "saber" que tengo la contraseña + sal de 13^26 a 8^26 porque sé cuál es la sal. Eso lo hace más fácil, pero aún así muy difícil.
Entonces, sobre cifrar la sal. Si sé que el salt está cifrado, no intentaría descifrarlo (suponiendo que sepa que tiene un nivel suficiente de cifrado) primero. Yo lo ignoraría. En lugar de intentar descubrir cómo descifrarlo, volviendo al ejemplo anterior, simplemente generaría una tabla de arcoíris más grande que contiene todas las claves para 13^26. No conocer la sal definitivamente me ralentizaría, pero no creo que agregaría la monumental tarea de intentar descifrar el cifrado de la sal primero. Por eso no creo que valga la pena. ¿Pensamientos?
Aquí hay un enlace que describe cuánto tiempo resistirán las contraseñas bajo un ataque de fuerza bruta: http://www.lockdown.co.uk/?pg=combi
Esconder una sal es innecesario.
Se debe utilizar una sal diferente para cada hachís. En la práctica, esto es fácil de lograr obteniendo 8 o más bytes de un generador de números aleatorios de calidad criptográfica.
De una respuesta mía anterior :
Salt ayuda a frustrar los ataques de diccionarios precalculados.
Supongamos que un atacante tiene una lista de contraseñas probables. Puede codificar cada uno y compararlo con el hash de la contraseña de su víctima y ver si coincide. Si la lista es grande, esto podría llevar mucho tiempo. No quiere dedicar tanto tiempo a su próximo objetivo, por lo que registra el resultado en un "diccionario" donde un hash apunta a su entrada correspondiente. Si la lista de contraseñas es muy, muy larga, puede utilizar técnicas como Rainbow Table para ahorrar algo de espacio.
Sin embargo, supongamos que su próximo objetivo altera su contraseña. Incluso si el atacante sabe qué es la sal, su tabla precalculada no tiene valor: la sal cambia el hash resultante de cada contraseña. Tiene que volver a codificar todas las contraseñas de su lista, colocando la sal del objetivo en la entrada. Cada sal diferente requiere un diccionario diferente y, si se utilizan suficientes sales, el atacante no tendrá espacio para almacenar diccionarios para todas ellas. Negociar espacio para ahorrar tiempo ya no es una opción; el atacante debe recurrir al hash de cada contraseña de su lista para cada objetivo que quiera atacar.
Por lo tanto, no es necesario mantener la sal en secreto. Es suficiente asegurarse de que el atacante no tenga un diccionario precalculado correspondiente a esa sal en particular.
Después de pensar un poco más en esto, me di cuenta de que engañarse pensando que la sal se puede ocultar es peligroso. Es mucho mejor asumir que la sal no se puede ocultar y diseñar el sistema para que sea seguro a pesar de ello. Proporciono una explicación más detallada en otra respuesta.
Sin embargo, recomendaciones recientes del NIST alientan el uso de una "sal" secreta adicional (he visto a otros llamar a esta "pimienta" secreta adicional). Se puede realizar una iteración adicional de la derivación de clave utilizando este secreto como sal. En lugar de aumentar la fuerza contra un ataque de búsqueda precalculada, esta ronda protege contra la adivinación de contraseñas, de manera muy similar a la gran cantidad de iteraciones en una buena función de derivación de claves. Este secreto no sirve para nada si se almacena con la contraseña hash; debe administrarse como un secreto, y eso podría resultar difícil en una base de datos de usuarios grande.
La respuesta aquí es preguntarse ¿de qué está realmente tratando de protegerse? Si alguien tiene acceso a su base de datos, entonces tiene acceso a las sales cifradas y probablemente también tenga acceso a su código. ¿Con todo eso podrían descifrar las sales cifradas? Si es así, entonces el cifrado es prácticamente inútil de todos modos. La sal realmente está ahí para hacerlo, por lo que no es posible formar una tabla de arcoíris para descifrar toda la base de datos de contraseñas de una sola vez si se rompe. Desde ese punto de vista, siempre que cada sal sea única, no hay diferencia, se requeriría un ataque de fuerza bruta con sus sales o las sales cifradas para cada contraseña individualmente.
Una sal escondida ya no es sal. Es pimienta. Tiene su utilidad. Es diferente a la sal.
Pepper es una clave secreta agregada a la contraseña + sal que convierte el hash en un HMAC (Código de autenticación de mensajes basado en hash). En teoría, un hacker con acceso a la salida del hash y a la sal puede adivinar por fuerza bruta una entrada que generará el hash (y, por lo tanto, pasará la validación en el cuadro de texto de la contraseña). Al agregar pimienta, se aumenta el espacio del problema de forma criptográficamente aleatoria, lo que hace que el problema sea intratable sin hardware serio.
Para obtener más información sobre la pimienta, consulte aquí .
Véase también hmac .
