Algunas consideraciones con respecto a cómo llamar a una vulnerabilidad:
¿Cuál de los escenarios anteriores podría informar un investigador de seguridad como una vulnerabilidad?
En primer lugar, no debes cifrar las contraseñas . El cifrado es reversible.
En su lugar, debes codificar las contraseñas . Un hash es un poco como encriptación unidireccional.
Cuando el usuario inicia sesión, en lugar de descifrar, encrypt hash la contraseña que proporcionó y ve si coincide con el hash que ya está almacenado en la base de datos. Si es la misma contraseña (y sal), entonces el hash resultante será consistente y puedes dejarlos entrar.
Cuando hash de contraseñas debes considerar algunas cosas:
Es importante usar sal para evitar ataques de canal lateral en relación con la detección de duplicados.
Debes usar una rutina bien revisada.
Debes usar un factor de Trabajo suficientemente alto para que sea costoso a la fuerza bruta.
He explicado todas las consideraciones aquí: ¿Por qué se considera MD5 un algoritmo vulnerable? .
En resumen, debes usar BCrypt. (que ha tenido más tiempo para ser examinado que Argon2)
Ejecute un SHA-256 rápido en la contraseña antes de enviarlo a BCrypt. (para evitar el truncamiento)
El factor de trabajo de BCrypt debería tomar 50-500 ms en su máquina de destino.
Limitar los intentos de inicio de sesión para evitar la Fuerza Bruta en línea y el DoS a través de los cálculos de hash.
BCrypt ya tiene Salt, pero es mejor incluir también Pepper (~ 72 bits de entropía), que es un tipo rápido de contraseña adicional que se agrega a la contraseña del usuario. El Pepper es el mismo para todos los usuarios, pero es único para su aplicación. Se almacena en su código fuente, o mejor aún, en un archivo de texto separado, pero nunca se almacena en una base de datos SQL.
Incluya los requisitos razonables de seguridad de la contraseña en su aplicación, porque ninguna cantidad de hashing protegerá un password débil.
¿Se consideraría una vulnerabilidad una base de datos de contraseñas sin cifrar en un sistema? (piensa que sí)
Si no hash o cifrado, es una vulnerabilidad segura
¿Se consideraría una vulnerabilidad una base de datos de contraseña hash sin sal en un sistema? (inseguro)
Sí, principalmente debido a las tablas del arco iris. Sin embargo, la mayor preocupación sería qué tan fuerte es la función hash que estás usando. La mayoría de los algoritmos buenos ya tienen sal, por lo que si no tiene sal, es muy probable que esté usando un algoritmo débil.
¿Una base de datos de contraseñas con sal y hash se consideraría una vulnerabilidad? (tiende a pensar que no)
Tienes razón, esto está bien. Es común almacenar tanto Salt como Hash en una base de datos SQL, pero también es mejor incluir Pepper que se mantiene fuera de la base de datos SQL.
¿Y se consideraría una vulnerabilidad una base de datos de contraseñas cifradas pero con una misma clave "secreta"?
Sí. El cifrado reversible de las contraseñas es malo. Si la clave es robada, las contraseñas se recuperan fácilmente sin fuerza bruta. Hashing resuelve este problema.
Lea otras preguntas en las etiquetas passwords vulnerability