Decidí implementar un sistema de autenticación simple, personalizado para mi aplicación web: cuando un usuario inicie sesión, almacenaré su "id_usuario" en una sesión o cookie. .
Si elijo una cookie, necesitaría cifrar "id_usuario".
No obstante, ¿cuál es la diferencia entre el almacenamiento en uno y el otro para el propósito de autenticación? ¿Cuál es más seguro? ¿Por qué? ¿Qué se recomienda? ¿A qué debo prestar atención cuando lo hago?
Estás comparando naranjas y manzanas aquí, o más exactamente, ladrillos y casas. Lo que identifica una conversación es, por definición, una sesión. Parada completa Pero la sesión se puede implementar de varias maneras:
No todos los marcos permiten todas las implementaciones de sesión.
De vuelta a su pregunta, desde un punto de vista de seguridad, se espera que los datos que no abandonan el servidor sean más difíciles de manipular, porque es trivial crear una cookie personalizada a través de cualquier biblioteca de cliente HTTP. Por lo tanto, al menos debe firmar la cookie y controlar la firma en cada paso, y si no desea filtrar datos internos de la aplicación, también debe cifrar el contenido de la cookie. Esto, y la limitación añadida de 4k para un tamaño de cookie, es suficiente para explicar por qué los datos de la sesión generalmente se guardan en el lado del servidor y solo se pasa una identificación en una cookie.
TL / DR: a menos que tenga una buena razón para no hacerlo, mi consejo sería seguir el uso común y almacenar el ID de usuario en una sesión del lado del servidor: esa es probablemente la forma predeterminada para su marco ... .
Respuesta detallada:
¿Cuál es la diferencia entre almacenar en uno frente a otro para el propósito de autenticación?
No hay diferencia en un punto de vista funcional porque ambas son implementaciones diferentes de una sesión
¿Cuál es más seguro? ¿Por qué?
El uso de una sesión es más seguro porque se basará en un marco o biblioteca muy probado. La sesión del lado del servidor es más sólida porque las sesiones de cookies se basan en claves adicionales para la firma y / o el cifrado, y la administración de claves es un punto adicional a considerar en un punto de vista de seguridad
¿Qué se recomienda?
Definitivamente sesión, porque es proporcionada por su marco o biblioteca, y la mayoría de los problemas de seguridad provienen de la implementación. Esa es la razón por la que las mejores prácticas de seguridad recomiendan no enrollar las suyas
¿A qué debo prestar atención cuando lo hago?
No puede confiar en lo que no controla, por lo que no puede esperar que una cookie no haya sido manipulada por el lado del cliente. Por lo tanto, debe firmar la cookie en el nivel de la aplicación con una clave segura y segura. La identificación de usuario interna normalmente no es relevante para el cliente, por lo que debe cifrarla aún en el nivel de la aplicación, y aún con una clave segura y administrada de forma segura. Debe agregar controles adicionales, aún en el nivel de la aplicación para asegurarse de que la cookie (incluso firmada y encriptada) no haya sido espiada desde una sesión anterior legítima, por lo que debe al menos almacenar el ID de sesión dentro de su cookie firmada específica. Y puede haber otros posibles problemas que no haya pensado ...
Es mejor almacenar ese tipo de datos en la sesión.
La cookie es susceptible de ser robada por la perspectiva del lado del cliente, es posible atacarla bruscamente o ser detectada en la red.
Como recomendación sobre qué prestar atención, debe preocuparse siempre por lo que los clientes pueden aportar. Estoy de acuerdo contigo en hacer rodar el tuyo, te hace entender lo que realmente está sucediendo.
Tenga cuidado con el uso del lenguaje. En ambos casos, está almacenando datos de la sesión; la diferencia es que en un caso lo está almacenando en el servidor y en el otro en el cliente.
Si la identificación del usuario se almacena en una cookie, incluso si está cifrada, es posible que otra persona copie los datos y se haga pasar por el usuario autenticado. Si la cookie solo contiene una referencia a los datos almacenados en el servidor, esto aún es posible, sin embargo, hay una ventana de oportunidad limitada definida por la sesión autenticada. Una vez que caduque, no podrá (o más comúnmente debería no ) ser resucitado.
Hay algunos argumentos para almacenar datos de sesión en un cliente que se relacionan con el rendimiento y la escalabilidad. Desde un punto de vista de seguridad, se podría argumentar que hay algún beneficio en no dejar una huella de los datos de los usuarios en un servidor (pero este no es un argumento muy bueno ya que puede lograrlo al encriptar en el servidor usando una clave almacenada en el cliente). ).
Si está almacenando el lado del cliente de datos de autenticación, debe hacer más para protegerlos: las comunicaciones deben ser exclusivamente a través de HTTPS, una fecha de caducidad y el token de autenticación deben estar cifrados en el conjunto de datos (y ambos deben validarse para la autenticación).
A menos que tenga una razón convincente para mantener los datos de la sesión en el cliente, simplemente siga a la multitud y guárdela en el servidor con solo una referencia no enumerable y con caducidad automática de la sesión en el cliente.
Creo que puede haber cierta confusión con respecto a qué hace una cookie y qué hace una sesión. Como @elsadek señala, la cookie generalmente almacena un ID de sesión, que a su vez se usa en el lado del servidor para recuperar los datos asociados, en su caso, un ID de usuario.
El servidor (con el manejo de sesión habilitado) verifica si una Cookie está adjunta a una solicitud, y si no, devuelve un encabezado Set-Cookie , que generalmente contiene una ID de sesión. El navegador lo recoge y ahora pasará el ID de sesión como un Cookie de nuevo al servidor.
Esto permite al servidor asociar datos con una sesión del navegador, de ahí el nombre "sesión".
Entonces: Almacene su ID de usuario en los datos de la sesión. Y: No ruedes el tuyo. Hay toneladas de bibliotecas, sin tener en cuenta su marco, que hacen esto por usted.
Lea otras preguntas en las etiquetas authentication web cookies