La mejor manera de manejar la autenticación de cuenta de usuario y las contraseñas

Question

Cuál es la mejor forma de manejar la administración de cuentas de usuario en un sistema, sin tener acceso a las cuentas a sus empleados que tienen acceso a una base de datos.

Ejemplos:

1. Almacenamiento de nombre de usuario/contraseña en la base de datos. Esta es una mala idea porque cualquiera que tenga acceso a una base de datos puede ver el nombre de usuario y la contraseña. Y por lo tanto, usarlo.

2. Almacenamiento de hash de nombre de usuario/contraseña. Este es un método mejor, pero se puede acceder a la cuenta reemplazando el hash de contraseña en la base de datos con el hash de otra cuenta para la que conoce la información de autenticación. Luego, después de que se concede el acceso, lo revierte a la base de datos.

¿Cómo maneja Windows/* nix esto?

Answer 1

Este fue un tema común en UNIX hace muchos años, y se resolvió separando los componentes de identidad del usuario (nombre de usuario, UID, shell, nombre completo, etc.) de los componentes de autenticación (hash de contraseña, sal de hash de contraseña). Los componentes de identidad pueden leerse globalmente (y de hecho deben serlo, si los UID se deben asignar a nombres de usuario), pero los componentes de autenticación deben mantenerse inaccesibles para los usuarios. Para autenticar a un usuario, tenga un sistema confiable que acepte un nombre de usuario y contraseña, y devolverá un resultado simple de "autenticado" o "no autenticado". Este sistema debe ser la única aplicación con acceso a la base de datos de autenticación, y debe esperar durante un tiempo aleatorio (quizás entre 0.1 y 3 segundos) antes de responder para ayudar a evitar ataques de sincronización.

Answer 2

Puede almacenar el sal para la contraseña hash en otra tabla, por supuesto, cada usuario tendrá su propia sal. A continuación, puede limitar el acceso a esa tabla.

Answer 3

1. Una muy mala idea de hecho. Si la base de datos está en peligro, todas las cuentas están en peligro.
2. Buen camino a seguir. Si su algoritmo hash incluye el nombre de usuario, reemplazar el hash de contraseña con otro no funcionará.

Unix almacena hashes en un archivo de texto/etc/shadow, que solo es accesible para usuarios con privilegios. Las contraseñas están encriptadas con una sal.

Answer 4

Este es un método mejor, pero se puede acceder a la cuenta reemplazando el hash de la contraseña en la base de datos con el hash de otra cuenta para la que conoce la información de autenticación.

En realidad no hay forma de evitar esto. Cualquiera que tenga acceso de escritura al archivo de contraseña tiene control total de la computadora.

Answer 5

Puede usar openID y no guardar contraseñas de usuario confidenciales en absoluto. ¿Quién dijo que es solo para sitios web?

Answer 6

Iría con 2 pero usaré un poco de sal. Algunos pseudocódigo:

SetPassword(user, password) 
    salt = RandomString() 
    hash = Hashfunction(salt+password) 
    StoreInDatabase(user, salt, hash) 

CheckPassword(user, password) 
    (salt, hash) = GetFromDatabase(user) 
    if Hashfunction(salt+password) == hash 
     return "Success" 
    else 
     return "Login Failed" 

Es importante utilizar una función hash bien conocida (tal como MD5 o SHA-1), implementado en una biblioteca. No haga rodar el suyo o intente implementarlo desde un libro, simplemente no justifica el riesgo de equivocarse. @Brian R. Bondy: La razón por la que usas sal es para dificultar los ataques de diccionario, el atacante no puede usar un diccionario y trata de no usar todas las contraseñas, sino que tiene que tomar el diccionario y hash it , lo que hace que los requisitos de almacenamiento expode. Si tienes un diccionario de las 1000 contraseñas más comunes y hash, necesitas algo así como 16 kB, pero si agregas dos letras al azar, obtienes 62 * 62 * 16 kB ≈ 62 Mb.

Si no puede usar algún tipo de One-time passwords He oído cosas buenas sobre OTPW pero no las he usado.

Answer 7

El enfoque habitual es utilizar la segunda opción con el correo electrónico:

tienda nombre de usuario, contraseña y hash de correo electrónico en la base de datos.

Los usuarios pueden ingresar su contraseña o restablecerla, en este último caso se genera una contraseña aleatoria, se crea un nuevo hash para el usuario y se le envía la contraseña por correo electrónico.

Editar: Si la base de datos está en peligro, entonces usted puede garantizar que no se puede acceder a información sensible, ya no puede garantizar la seguridad de su aplicación.

Answer 8

Ingrese el nombre de usuario y la contraseña junto con. De esta forma, si dos usuarios tienen la misma contraseña, los hashes seguirán siendo diferentes.

Answer 9

Jeff Atwood tiene algunos buenos mensajes relativos a hash, si decide ir por ese camino:

• Rainbow Hash Cracking
• You're Probably Storing Passwords Incorrectly

Answer 10

Esto no es un problema para muchas aplicaciones, ya que acceder a la base de datos es probablemente el objetivo más común de cualquier atacante. Entonces, si ya tienen acceso a la base de datos, ¿por qué todavía desean iniciar sesión en la aplicación? :)

Answer 11

Si el 'sistema' es un sitio web público RPX puede proporcionarle a los servicios de cuenta de usuario/usuario de los proveedores más comunes, como OpenID, Facebook, Google, etc.

Ahora, dada la forma usted formula su pregunta Supongo que el 'sistema' del que está hablando es más bien una aplicación empresarial interna basada en Windows/Linux. Sin embargo; para aquellos buscando en Google los proveedores de cuentas de usuario/login (como lo hice antes de encontrar RPX), esto podría ser una buena opción :)