Estado de autenticación web: ¿sesión vs cookie?

Question

¿Cuál es la mejor manera de autenticar y rastrear el estado de autenticación de usuario de página a página? Algunos dicen que el estado de la sesión, algunos dicen que las cookies?

¿Podría simplemente utilizar una variable de sesión que tiene el ID del usuario y, luego de la autenticación, instaurar una clase de usuario personalizada que tenga la información del usuario. Luego, en cada página, verifique que la variable de sesión aún esté activa y acceda a los datos básicos del usuario desde el objeto Usuario.

¿Alguna idea? ¿Algún buen ejemplo?

Answer 1

No hay perfecto manera de hacerlo. Si lo almacena en una cookie, se tomará antiaéreo el robo de cookies. Si lo almacena en la sesión, se tomará una copia porque las sesiones se pueden secuestrar.

Personalmente, tiendo a pensar que una sesión es un poco más confiable porque lo único almacenado en el cliente es una clave de sesión. Los datos reales permanecen en el servidor. Si quieres, juega las cartas un poco más cerca del cofre. Sin embargo, esa es solo mi preferencia, y un buen hacker sería capaz de superar la seguridad de mala calidad, independientemente.

No importa lo que haga, no intente implementarlo usted mismo. Lo entenderás mal. Use el sistema de autenticación provisto por su plataforma específica. También debe asegurarse de tener las precauciones de seguridad adecuadas para proteger el token de autenticación.

Answer 2

No sé si es LA MEJOR manera de hacerlo, pero nos sentimos cómodos con la forma en que lo hacemos.

tenemos un objeto de usuario personalizado que instanciamos cuando el usuario se autentica, luego usamos Session para mantener este objeto en la aplicación.

En alguna aplicación lo combinamos con el uso de cookies para extender la sesión de forma continua.

Answer 3

El problema con favorecer las sesiones sobre las cookies para 'seguridad' es que las sesiones UTILIZAN las cookies para identificar al usuario, por lo que cualquier problema con las cookies está presente con las sesiones.

Una cosa a tener en cuenta con el uso de Sessions es la ubicación de los datos. Si planea escalar a más de un servidor web en cualquier punto, debe tener mucho cuidado al almacenar grandes cantidades de datos en los objetos de la sesión.

Dado que está utilizando .NET, básicamente tendrá que escribir su propio proveedor de la tienda de sesión para manejar esto, ya que InProc no escalará más allá de 1 servidor, el proveedor de DB es simplemente una mala idea (El punto es para EVITAR las lecturas de DB aquí mientras escala, no agrega más), y el StateServer tiene muchos problemas de capacidad. (En el pasado, he utilizado un proveedor de tienda de sesiones de Memcached con cierto éxito para combatir este problema).

Buscaría las cookies firmadas en google y buscaría utilizarlas en lugar de las cookies o sesiones habituales. Soluciona muchas de las preocupaciones de seguridad y elimina los problemas de localidad con las sesiones. Tenga en cuenta que van y vuelven en cada solicitud, así que guarde los datos con moderación.

Answer 4

Las cookies y las sesiones en sí mismas no son realmente suficientes. Son herramientas que se usan para rastrear al usuario y lo que hacen, pero realmente debe pensar en utilizar una base de datos para conservar información sobre el usuario que también se puede usar para proteger la aplicación.

Answer 5

Las sesiones son cookies ...