¿Debo codificar una contraseña si se genera aleatoriamente?

El punto de las contraseñas de hash es que si el atacante puede obtener acceso a su archivo de contraseña (ingresando a su servidor, robando medios de copia de seguridad, pirateando a su proveedor de alojamiento, etc.), aún no puede recuperar la contraseña. hash e inicia sesión como el usuario.

Hay dos niveles:

1. Necesitas un hashing como segunda línea de defensa, para que lo que almacenes en el servidor (yo llamo "servidor" al sistema que realiza la autenticación verificando una contraseña dada) no es suficiente para suplantar a los usuarios. Esto evita la escalada de una violación parcial de solo lectura (por ejemplo, una cinta de copia de seguridad robada) a un acceso de lectura y escritura más completo. Consulte esta publicación del blog para una discusión más larga.

2. Si hash la contraseña, entonces puede necesitar usar un función de hash de contraseña si la contraseña de origen tiene poca entropía. Las contraseñas elegidas por los usuarios humanos tienen baja entropía. Si genera las contraseñas "al azar", entonces puede obtener contraseñas de alta entropía. O no. El punto positivo de generar contraseñas a través de un proceso sistemático conocido que se alimenta de un PRNG criptográficamente seguro es que puede calcular la entropía, en lugar de simplemente estimarla. Sin embargo, aún debe asegurarse de obtener suficiente.

Por ejemplo, si genera una contraseña como una secuencia de 10 caracteres aleatorios (letras en minúsculas y mayúsculas, y dígitos), y todos los caracteres se eligen de manera uniforme e independiente entre sí, entonces hay 62 ¹⁰ contraseñas posibles y cada una de ellas tiene la misma probabilidad de ser elegida que cualquier otra. La entropía es entonces igual a log (62 ¹⁰ ) (logaritmo en base 2), es decir, 59.54 bits. Eso no es malo, pero posiblemente aún sea demasiado bajo para la comodidad si se utiliza una función hash simple, ya que una buena GPU puede ejecutar miles de millones de MD5 o SHA-1 por segundo. Luego debe agregar sales e iteración, es decir, usar bcrypt (pero un pequeño recuento de iteraciones ya estaría bien).

Si sus contraseñas tienen al menos 80 bits de entropía, puede considerar que son lo suficientemente fuertes como para derrotar incluso a los atacantes ricos y determinados, y puede usar un hashing simple (es decir, puede salirse con una simple llamada de hash < em> y también con no usar sales). Con letras y dígitos aleatorios, esto se traduce en 14 caracteres . Insisto en que esto es cierto solo si los 14 caracteres se eligen de forma aleatoria, uniforme e independiente entre sí. Estos son requisitos que puede cumplir con su generador de contraseñas, pero no puede esperarlos de una contraseña elegida por el usuario.

Debería tratarlo igual que con cualquier otra contraseña.

No puede garantizar que el usuario no reutilice su contraseña en otros sistemas a menos que los controle; por ejemplo, cuando tuve que elegir una contraseña para mi nuevo servidor de correo de ISP, utilicé la generada automáticamente de la anterior. Sistema para que lo recordara (por un período temporal bastante más largo que el planeado).

Si obliga al usuario a usar una contraseña generada aleatoriamente, es probable que aún la utilicen para otras cosas: un número significativo la anotará o la almacenará en texto sin formato en alguna parte, y es más fácil mantener esa lista corta. No puede asumir que sus usuarios tienen ni siquiera 1/2 pista sobre la seguridad de la contraseña, e incluso aquellos que sí lo hacen pueden no valorar su servicio lo suficiente como para preocuparse por una seguridad decente.

En el escenario dado, tener contraseñas con hash lo protegería en el caso en que el atacante obtenga acceso de lectura al almacén de contraseñas, pero no acceso de escritura o acceso a otros datos. En ese caso, podrían usar la contraseña para iniciar sesión y obtener acceso a más datos.

Cuando el atacante obtenga acceso de escritura al almacén de contraseñas, podrá simplemente reemplazar el hash con el de su propia contraseña, por lo que el hashing no lo protegería en ese caso.

Además, cuando la base de datos de contraseñas está comprometida, puede asumir que cualquier otro dato en el servidor también está comprometido, por lo que el atacante ni siquiera podría tener una razón para iniciar sesión.

La respuesta simple es sí.

algo que parece ser recurrente es la noción de que si el usuario tiene acceso a la sección de contraseña de la base de datos, tendrá acceso a toda la base de datos. Esta es una buena suposición que se debe hacer al proteger sus datos, pero no es una buena suposición cuando se trata de justificar el no hashing de las contraseñas. Esa misma lógica en teoría podría aplicarse en un caso de uso normal en el que el usuario puede cambiar la contraseña.

Las contraseñas en general (no solo la informática) son una forma de verificación contra una variable conocida en su extremo. El almacenamiento de contraseñas en texto sin formato lleva a fugas de seguridad internas y reducirá su confianza sin ningún motivo.

Piense en esto, ¿confiaría su información personal en un sitio que no contenía contraseñas, incluso si la contraseña tuviera los mismos requisitos?

No creo que tengas que hacerlo. Lo único que tienes que buscar es esto: Si su base de datos está comprimida, un pirata informático puede iniciar sesión en cualquier cuenta realmente rápido y realizar cualquier acción para la que sus usuarios tengan permiso. Si este sistema está vinculado a algún otro servicio que podría crear un desastre realmente rápido. Es su decisión, personalmente no lo haría, pero lo consideraría dependiendo de otros servicios a los que mis usuarios puedan acceder a través de mi programa.