Estaba pensando en nombres de usuario y contraseñas y me preguntaba qué tan seguro sería en lugar de que el servidor tenga una lista de nombres de usuario y un hash adjunto de las contraseñas, solo tenga una lista de la contraseña y el nombre de usuario concatenados y luego hash, o algo por el estilo.
Si alguien pudiera explicar por qué esto no funcionaría, sería genial.
El problema de transmitir de forma segura un nombre de usuario y una contraseña es un problema resuelto, HTTPS es elegante y funciona bien.
En términos de esta propuesta, es significativamente menos segura que HTTPS, porque este sistema propuesto es vulnerable a un ataque de repetición. ¿A quién le importa lo que realmente son el nombre de usuario y la contraseña? Si solo inicia sesión con hash(user+password) , este es el único valor que el atacante necesita saber.
Las respuestas de desafío seguras basadas en hash usualmente innovan una causa donde el servidor proporciona un nonce al cliente, y luego se usa el hash(nonce+hash(password)) . El nonce nunca puede ser reutilizado, el NTML de Microsoft ha solucionado este problema más de una vez.
Después de iniciar sesión con el nombre de usuario y la contraseña, aún necesita proteger el ID de sesión, que es el token de autenticación que el navegador utiliza para mantener el estado autenticado, por lo que HTTPS también es una buena solución para esto.
Su idea parece provenir del hecho de que la misma contraseña ejecutada a través de una función de hash imprime el mismo valor de hash.
En lugar de concatenar la contraseña con el nombre de usuario, la práctica preferida aquí es concatenar la contraseña con un salt aleatorio único (solo un blob de texto aleatorio) que se genera en el servidor cuando un usuario se registra. Esta sal, como el nombre de usuario, realmente no necesita mantenerse en secreto. La ventaja sobre el uso de un blob generado aleatoriamente frente al nombre de usuario es la entropía adicional.
Aunque estás pensando en esto de la manera correcta. Agregar algo a la contraseña antes de hash la hace más segura. Sin embargo, idealmente debería ser algo un poco más largo y más aleatorio que el nombre de usuario.
En la base de datos, solo la contraseña es para fines de autenticación y, como tal, debe estar protegida, el inicio de sesión es para fines de identificación. Como administrador, es posible que deba acceder a la lista de usuarios, bloquear o eliminar una cuenta de usuario o restablecer una contraseña: es imposible hacerlo si todos los inicios de sesión están marcados con hash. También pierde flexibilidad para muchos usos (por ejemplo, imagine algunos mensajes privados entre usuarios, muy difíciles de implementar cuando nadie tiene visibilidad sobre los nombres de usuario).
Por eso, en la base de datos de cualquier usuario, los inicios de sesión (o cualquier otro tipo de datos de identificación) generalmente aparecen de forma clara y solo los datos de autenticación están protegidos mediante un método no reversible (como algoritmos hash).
Algunos problemas que debe superar con esto, la mayoría de los cuales veo son cambios de contraseña, restablecimiento de contraseña, administración de usuarios, directorios de inicio (si corresponde).
Si hash el nombre de usuario y la contraseña juntos, lo más probable es que debas referirte a los usuarios con un número de identificación o algo así para el administrador (referirse a él con el hash sería bastante inseguro, y cómo sabrías quién era ¿quien?). El sistema tampoco podría verificar que un nombre de usuario fuera correcto sin la contraseña.
En mi opinión, sería más efectivo implementar otra medida de seguridad adicional, como 2FA.