Sal aleatoria: ¿necesaria para un solo usuario?

Tanto el uso aleatorio de sal como varios cálculos de hash u otra estrategia de retardo (bcrypt, scrypt, lo que sea) tiene sentido no solo para muchos usuarios, sino también para un usuario.

Salt evita que un atacante ingrese trivialmente su hash en Google para obtener una contraseña instantánea sin siquiera usar una herramienta. Una buena sal aleatoria hace que sea menos probable que haya elegido una que alguien más haya creado una tabla de arco iris para el valor de todos modos (por ejemplo, para algunas sales obvias que podría ver, como los ID de usuario).

Tener una sal aleatoria diferente para cada usuario evita que un atacante reutilice los hash en una tabla de arco iris (o que use una tabla de arco iris para una sal específica que ya existe). Fuerza a la fuerza bruta de cada usuario individual. No puedes evitar que alguien continúe con un ataque de fuerza bruta, y eventualmente tendrá éxito (ya que incluso las contraseñas "fuertes" son relativamente débiles). Pero cuanto más tiempo le toma a un usuario de fuerza bruta, más seguros están los restantes (si se requieren 2 segundos para un usuario de fuerza bruta, puede hacer 1000 usuarios en unas pocas horas, si se tarda una semana por usuario, Las cosas se ven mucho mejor). Ese es el punto central de usar algo como bcrypt.

Ahora, si hay solo un usuario , forzar brutalmente al primer usuario significa un compromiso del 100%.

Por lo tanto, usar una estrategia que retrase la fuerza bruta es al menos tan importante como con una base de datos de muchos usuarios (pero, conceptualmente, más importante).

Algo como un GUID funcionará bien, no importa si almacena la "cadena" en algún lugar o si la reutiliza cuando el mismo usuario cambia la contraseña. Una sal debe ser accesible de alguna forma para que pueda validar la contraseña. Claro, sería bueno que lo mantuvieras en secreto, pero eso no es posible ni necesario para su propósito. Además, si alguien puede robar la sal, también tendrá la contraseña de hash, ya que generalmente se almacena en el mismo lugar. En la medida en que no exista un "riesgo adicional" de que alguien pueda preparar una mesa de arco iris con anticipación para esa sal conocida (antes de robar la contraseña real). Dicho esto, si te sientes incómodo, realmente no cuesta nada cambiar también la sal cada vez que el usuario cambia la contraseña.

El propósito de la sal no es el cifrado de algún tipo, sino el de frustrar las tablas del arco iris, lo que hace que la inversión del hash sea una operación trivial.

En principio, hardcoding una sal "elegida al azar" directamente como usted propone sería igual de buena para su escenario de un solo usuario. Sin embargo, este es un mal enfoque ya que existe la posibilidad de que eventualmente reutilices el código para otra cosa (un proyecto diferente tuyo) o que eventualmente tengas más de un usuario.

Es posible que no veas esto en este momento, pero generalmente es una posibilidad.

Ahora, lo que sucede con las cosas que pueden suceder es que eventualmente sucederán . Por lo tanto, si codifica directamente una única sal, ya que de todos modos solo hay un usuario, eventualmente tendrá un agujero de seguridad, tal vez dentro de 10 años, cuando ya no lo piense más.
Tan pronto como use la misma sal para varios usuarios o para un solo usuario en varios proyectos, es bastante inútil. Simplemente no debe permitir que eso suceda.

Lo mismo se aplica, por supuesto, al enfoque de tener una sal "permanente" que se usa en todas partes, por ejemplo, por el resto de su vida. Esta es una invitación abierta para construir una tabla de arco iris, ya que al hacerlo se ahorrará trabajo computacional. Atacar una de sus contraseñas será más o menos la misma carga de trabajo que atacar todas las contraseñas en su vida.

Cuando no se agrega (o salpica) la contraseña, la contraseña no es muy fuerte y un atacante obtiene el hash, se puede descifrar simplemente buscando el hash en una tabla de arco iris (una lista precalculada de los hashes). de las contraseñas más comunes que puede encontrar en línea ). Pero cuando agrega algunos datos adicionales a la contraseña, una tabla de arco iris precalculada es inútil y un atacante tiene que calcular el hash de cada contraseña común, lo que requiere un tiempo de procesamiento considerable, especialmente cuando se utiliza una función de hash lenta (que se recomienda) .

Cuando su sal es siempre la misma (lo que significa que es una "pimienta") y un atacante obtiene esa pimienta, puede precomputar una tabla de arco iris para esa pimienta que se puede usar para descifrar cualquier contraseña que haya en el futuro con la misma pimienta . Cuando su aplicación se implementa ampliamente y cada implementación usa el mismo pimiento, sería factible que un atacante precalcule dicha tabla para aumentar la eficiencia cuando se dirige a múltiples implementaciones. Cuando su aplicación es solo una instancia, tal tabla arco iris podría ser útil. Un posible escenario de ataque sería cuando hubiera alguna vulnerabilidad que filtre el hash y usted no conozca esa vulnerabilidad. Sin una tabla arco iris, un atacante podría tardar mucho tiempo en descifrar la nueva contraseña después de cada cambio de contraseña, lo que le daría un poco de tiempo para encontrar y solucionar el problema. Con una tabla arco iris, solo tomaría unos segundos descifrar cualquier nueva contraseña que establezca.

Siempre es una buena idea saltear, ya que no quieres que una tabla preestablecida contra ese algoritmo sea beneficiosa para atacar la contraseña. Si su contraseña se ve comprometida debido a que se construyó una tabla de arco iris contra el salt anterior, el cambio de la contraseña no sería efectivo.

Debes elegir una nueva sal para que cualquier esfuerzo existente contra el hash sea nulo y sin efecto.

  

Si estoy implementando una aplicación que solo será utilizada por un usuario por base de datos, ¿tiene algún sentido tener un salt generado aleatoriamente?

Sí, las contraseñas de salazón son siempre una buena idea . No importa cuántos usuarios haya. Si un atacante se apodera de su base de datos y sus hash no están salados, tiene una ventaja enorme, ya que podría haber tablas de arco iris y otras técnicas para obtener una coincidencia para los valores hash que se acaban de obtener. Las contraseñas con sal, por otro lado, brindan seguridad, ya que el atacante no conoce la sal de antemano.

Piense en términos de buenas prácticas, ya que su sistema podría terminar siendo adoptado y utilizado por más personas.

  

Sin duda, si el salt se generara de forma aleatoria, debería almacenarse junto con la contraseña de usuario cifrada y el ID de usuario, lo que significaría que el atacante tiene acceso al salt desde la base de datos

Eso no es un problema en absoluto y generalmente es la forma en que se hace . Un atacante no tiene ninguna ventaja en saber la sal, al menos mientras la función hash no esté fundamentalmente dañada.