security - expiration - non httponly session cookies identified

Recordarme las mejores prácticas de Cookie?

Question

Leí sobre muchas preguntas antiguas sobre este argumento, y creo que pensé que la mejor práctica es configurar una cookie con username , user_id username y un token aleatorio.

Los mismos datos de cookies se almacenan en DB en la creación de cookies, y cuando los usuarios tienen la cookie, se comparan (datos de cookies, datos de DB).

Sinceramente, no puedo entender cuál es la lógica de seguridad si esta es la mejor práctica real.

Un atacante que roba la cookie tiene la misma cookie que el usuario original: |

¿Has olvidado algún paso? :PAG

Answer 1

Siempre supe que la función "recordarme" solo convertía la cookie de la sesión (es decir, la cookie con la ID de sesión) de la que caduca al cerrar el navegador a una fecha futura, no implica guardar datos adicionales, solo extender la sesión.

Y sí, si un atacante obtiene la cookie, puede hacerse pasar por el usuario. Pero esto siempre es válido y no tiene nada que ver con "recordarme".

Answer 2

si se roban sus cookies, cualquiera puede iniciar sesión en sus cuentas. en realidad es lo que hace fireheep. la seguridad reside en el token aleatorio. todo el sistema supone que las cookies no pueden ser robadas. la única otra forma de entrar es adivinar el token aleatorio. si lo haces lo suficiente, debería ser casi imposible.

Answer 3

Mi enfoque es el siguiente:

1. Hash el user_id
2. Genere una clave única para el usuario - md5(current_timestamp)
3. Guarde la clave de la base de datos
4. Codifica todo para que parezca una BS - base64
5. Guárdelo en la cookie

Hasta ahora, ha estado funcionando bien para mí :)

Answer 4

NUNCA DEBES NUNCA almacenar una contraseña de usuario en una cookie, ¡ni siquiera si es hash!

Eche un vistazo a esta publicación de blog:

• Mejores prácticas de cookies de inicio de sesión mejoradas (noviembre de 2006; por bjaspan) ( orignal )

Citar:

1. Cuando el usuario inicia sesión con Remember Me checked, se emite una cookie de inicio de sesión además de la cookie de gestión de sesión estándar. [2]
2. La cookie de inicio de sesión contiene el nombre de usuario del usuario, un identificador de serie y un token. La serie y el token son números aleatorios inimaginables de un espacio adecuadamente grande. Los tres se almacenan juntos en una tabla de base de datos.
3. Cuando un usuario que no ha iniciado sesión visita el sitio y presenta una cookie de inicio de sesión, el nombre de usuario, la serie y el token se buscan en la base de datos.
4. Si el triplete está presente, el usuario se considera autenticado. El token usado se elimina de la base de datos. Se genera un nuevo token, se almacena en la base de datos con el nombre de usuario y el mismo identificador de serie, y se emite al usuario una nueva cookie de inicio de sesión que contiene los tres.
5. Si el nombre de usuario y la serie están presentes pero el token no coincide, se supone un robo. El usuario recibe una advertencia muy redactada y todas las sesiones recordadas del usuario se eliminan.
6. Si el nombre de usuario y la serie no están presentes, la cookie de inicio de sesión se ignora.

Answer 5

Debe almacenar el user_id y emitir un token aleatorio además de la contraseña del usuario. Use el token en la cookie y cambie el token cuando cambie la contraseña. De esta forma, si el usuario cambia su contraseña, la cookie será invalidada.

Esto es importante si la cookie ha sido secuestrada. Se invalidará si el usuario detecta el secuestro, y además porque el token no está relacionado con la contraseña que el secuestrador no podrá derivar y luego cambiará la contraseña de la cuenta del usuario y "poseerá" la cuenta (suponiendo que requiera la contraseña existente) antes de cambiar las contraseñas, el secuestrador no posee la cuenta de correo electrónico, por lo que no pueden usar "Olvidé mi contraseña", etc.).

Tenga cuidado de que los tokens no sean fáciles de adivinar (es decir, deben consistir en datos completamente aleatorios, como los de un CRNG).

Si desea ir un paso más allá, puede encriptar la cookie antes de enviarla y descifrarla al recibirla. Y además de eso, no asuma que un secuestrador no conoce la clave de cifrado utilizada, por lo que valide los contenidos de la cookie al descifrarla.

Pero todo lo dicho, prefiere utilizar la administración de sesión persistente de una biblioteca en lugar de utilizar la suya propia.

Answer 6

Ni siquiera almacenaría el nombre de usuario en una cookie, solo un token generado al azar con una técnica casi imposible de descifrar y mapearlo para el usuario en su base de datos, y nunca almacenar la contraseña del usuario, incluso hash en una cookie, estará abierta a Brute Force Attack . Sí, si alguien roba el token puede acceder a la cuenta del usuario, pero la contraseña no se verá comprometida y el token se invalidará tan pronto como el usuario real cierre la sesión. Además, recuerde que no debe permitir tareas confidenciales como cambiar la contraseña de un usuario que solo tiene un token válido, debe volver a solicitar la contraseña para tales tareas.

Answer 7

El "paso" que pareces estar olvidando es que si el valor de la cookie es correctamente hash, tendría poco valor para un atacante.

EDITAR:

Aquí hay un par de cosas que puede hacer para proteger a sus usuarios contra los ataques relacionados con el robo de cookies:

• Vuelva a generar tokens a lo largo del tiempo para que un atacante no pueda suplantar a un usuario a menos que tenga una cookie lo suficientemente reciente. Si la seguridad es la prioridad principal, regenere los tokens en cada solicitud (carga de página). Si no es así, regenere los tokens al cambiar la contraseña.
• Mantenga y valide los hashes de los agentes de usuario para que un atacante no pueda suplantar a un usuario a menos que tenga tanto la cookie como el agente de usuario del usuario.

ps Las cookies deben contener tokens (aleatorios) y no hash de contraseñas (ver hashes o tokens para las cookies "recordarme" ).