Almacenar la contraseña por separado desde el nombre de usuario

Question

Recientemente he hecho una descripción general de la seguridad de mi sitio a raíz de las noticias recientes sobre sitios web de alto perfil que han sido pirateados, por ejemplo. LinkedIn

Así que mi pregunta es:

¿Cómo es posible almacenar la contraseña de un usuario completamente separada de su nombre de usuario y otra información? De esta forma, un pirata informático solo podría obtener una contraseña y no el nombre de usuario correspondiente.

Editar: Olvidé decir que ya estoy almacenando las contraseñas como un hash (y salado).

Answer 1

Independientemente de cómo lo haga, todavía debe haber una forma de que el mecanismo de autenticación vincule el nombre de usuario/contraseña, por lo que lo que intenta hacer es inútil.

En lugar de seguir esa ruta, debe almacenar sus contraseñas como valor Hash que no se puede descifrar, que es accepted best practice.

http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database

Answer 2

No guarde la contraseña, sino más bien almacenar una de hash de la contraseña.

Afortunadamente, MySQL proporciona un (unidireccional) función hash seguro para esto: PASSWORD()

Sus consultas simplemente guardar el hash en lugar de la contraseña en texto plano, así:

update user_table set 
password = PASSWORD(?) 
where user_id = ? 

Puede comprobar de esta manera:

select * from user 
where user_id = ? 
and password = PASSWORD(?); // returns the row if password correct 

el artículo Password Hashing in MySQL en la documentación oficial de MySQL explica a fondo todo.

Answer 3

Creo que la mejor manera de agregar una seguridad es la misma que con el uso de la cuenta de Google. Cuando inicie sesión con la contraseña correcta (codificada en la base de datos usando cualquier algoritmo que desee, sin embargo, sugiero Bcrpyt) recibirá un código secreto en su teléfono. Puedes hacerlo usando el correo electrónico. Se está volviendo complicado, también puedes agregar sal y otras cosas para que sea más difícil de hackear.

Recuerde, si puede crearlo, puede revertirlo. Siempre. Es solo una cuestión de cómo, tiempo, dinero y voluntad alguna vez.

Para su pregunta, no. Siempre debe vincular el nombre de usuario (es decir, la cuenta) a la contraseña. Supongo que podría almacenar esto en dos bases de datos en dos servidores y usar múltiples servidores con sal y hash, pero la forma correcta y aceptada es simplemente codificar usando un algoritmo como dije y comparé.

Answer 4

La manera más limpia de mantener los nombres de usuario y las contraseñas separadas en su sitio es simplemente no guardar las contraseñas en .

Delegue las contraseñas y la autenticación a un servicio externo como Google e implemente OpenID.
http://openid.net/
A continuación, sólo va a almacenar nombres de usuario y usted no tendrá ningún conocimiento de datos de contraseñas, por lo que será imposible que pueda originar una violación, contraseñas y nombres de usuario nunca tendrá que conectar en su sistema en absoluto .
Aquí es Jeff Atwood sobre el tema:
http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html

EDIT: En respuesta a un comentario más abajo, si su cuenta de Google se ve comprometida, entonces es probable que todas las cuentas subsidiarias están comprometidas. Es por eso que un esquema de autenticación segura como Google es esencial. No hay necesidad de reinventar la rueda aquí. Puede proteger aún más su cuenta de Google mediante la autenticación en dos pasos
http://www.codinghorror.com/blog/2012/04/make-your-email-hacker-proof.html
No veo ninguna razón por la cual cada sitio debe esperar actuar como un autenticador distinto ... promueve la fragmentación web a expensas de la seguridad.

Answer 5

Según lo que he leído, LinkedIn usa contraseñas cifradas sin sal que usan encriptación SHA1. Parece que sería más inteligente "saltear" tus contraseñas. Si está salando con sales aleatorias para cada usuario, entonces está en muy buena forma. si no:

Esto significa generar cadenas de bits aleatorias y concatenarlas en su contraseña antes de hash it. Además, también almacena la cadena de bits aleatorios para cada usuario y la extrae de la base de datos cuando el usuario proporciona una contraseña para el hash

La contraseña está 'salada' (concatenada con la sal almacenada para el usuario), luego esa cadena salada es codificada y verificada con la contraseña de hash de los usuarios en la base de datos Esto casi seguro garantiza hashes únicos y hace que la tabla hash de contraseñas sea mucho más difícil de reinvertir en contraseñas lógicas porque la salida de la función hash también se basa en Sal personalizada asignada para cada usuario.

si alguien sabe por qué linkedIn doesnt salt their hashes Me encantaría saber de usted. De todo lo que he leído, SHA1 se puede descifrar fácilmente con el tiempo.