2011-01-04 9 views
7

Así que esto es básicamente una garantía de que estoy haciendo todo el proceso de registro/inicio de sesión en lo que respecta a hashing/salazón.Hashing & Salting - Validar el inicio de sesión con cookies

Tengo una tabla de usuarios con los campos password, salt, token (obviamente hay otros, pero este es el más importante). Tras el registro se genera una sal al azar, y una muestra aleatoria, y se pone en el campo de la contraseña esto:

hash("sha256", $theirpostpassword.$randomgeneratedsalt); 

que la sal generada al azar y el token se almacenan en sus respectivos ámbitos en los que los usuarios fila de la tabla.

De modo que al iniciar sesión selecciono SOLAMENTE la sal de la fila de usuarios con el nombre de usuario que especificó. Luego hago una consulta de recuento de cuántas filas tienen su contraseña de entrada concatenada con su sal específica, y luego las inicio de sesión. Estoy bastante seguro de que tengo esa parte desactivada.

Ahora estaba pensando en validar su inicio de sesión en cada página que tendría una función ejecutó cada página que comprueba su cookie para ver si el formato de id-username-token coincide con la fila en la base de datos. Lo que significa que cada inicio de sesión establece su cookie con esas credenciales.

Ahora, lo único que se me ocurre para hacerlo mejor es cambiar el token de cada inicio de sesión válido?

Gracias por la perspicacia chicos.

+1

Me gustaría que el token dependa de la IP del usuario remoto, pero al comprobar que la cookie -con esa información- en cada solicitud parece funcionar bien. – ncuesta

+1

Gracias por la respuesta rápida, estaba un poco en contra de la comprobación de IP por completo ya que sé que hay algunas direcciones IP dinámicas que cambian con bastante frecuencia. –

+0

No debe crear el sistema de autenticación usted mismo porque muchas cosas pueden salir mal. ¡Utilice facebook connect/twitter sign in/openid etc. en su lugar! – Alfred

Respuesta

4

Sí, definitivamente debería estar cambiando los tokens con cada inicio de sesión. De lo contrario, una ficha robada una vez es una cuenta robada para siempre. Los usuarios esperan que el cierre de sesión asegure su sesión del ataque al invalidar sus cookies u otros datos.

En lugar de que el token sea aleatorio, puede hacer que sirva como firma, generándolo a partir de un hash de la identificación de usuario, tiempo de caducidad de la sesión y cualquier otra cosa en la cookie, más una sal (como el sistema de inicio de sesión). Esta sal no tiene que venir de la base de datos, pero puede. Podría ser una cadena codificada (a veces llamado "pimienta", creo). Recuerde tratar la cookie como inválida si ya pasó el tiempo de caducidad. Es por eso que el token debe ser una firma, para asegurarse de que no hayan falsificado esa información.

+1

No estoy de acuerdo con que el token sea una firma. Necesitas que el token sea indescifrable y la única manera de garantizarlo es con la aleatoriedad. Por supuesto, también tiene una firma, pero un token aleatorio es muy importante. –

1

comprueba su cookie para ver si el formato de nombre de usuario id-token coincide con la fila en la base de datos

Usted podría pero esto es bastante caro y no está abordando el problema de la gestión de sesiones - establecer un tiempo de caducidad de cookies en el pasado no siempre hace que se eliminen las cookies. Por supuesto, considere esto como un tipo de función de recordarme (pero use una ruta de desplazamiento para evitar presentar la cookie cada vez).

No está obteniendo nada sobre el almacenamiento del nombre de usuario autenticado en la sesión. Pero cambie la identificación de la sesión cuando autentique a un usuario y use SSL para pasar tokens de autenticación.

2

suena bastante bien para mí, pero usted debe ser consciente de un par de cosas:

Para que su base de datos de contraseña resistente a ataques de fuerza bruta que podría repetir el hash:

$hash = $password; 
for ($i = 0; $i < 1000; ++$i) { 
    $hash = hash("sha256", $hash . $salt); 
} 

Segundo , asegúrese de usar SSL todo el tiempo. Sin él, es bastante trivial que un atacante robe la cookie de inicio de sesión. Vea fireheheep para ver un buen ejemplo de lo trivial que es.

Definitivamente Cambiar el identificador de cada inicio de sesión y considerar cambiarlo por cada solicitud para prevenir los ataques de fijación de sesión y de repetición.

También puede seleccionar la sal y el hash de la base de datos y hacer la comparación de hash del lado del servidor (en lugar de en el DB) para reducir el número de viajes de ida y vuelta a la base de datos.

me gustaría sugerir que el símbolo sea totalmente aleatorio. Quieres que no se pueda indagar y la mejor manera de hacerlo es al azar. Usted podría atar el token a una dirección IP particular, pero esto debería ser además de un token aleatorio, no un reemplazo.

Eso es todo lo que viene a la mente. ¡Bien por pedir consejo en lugar de solo MD5-ing la contraseña y pegarla en la base de datos!

Cuestiones relacionadas