Desde el punto de vista de la arquitectura, ¿cuál es la mejor aproximación a la sesión [] o las cookies cifradas?

Question

Estamos tratando de decidir la mejor decisión para mantener el estado en nuestra aplicación web. Nos inclinamos a utilizar cookies cifradas en el navegador, pero algunos de nuestros desarrolladores piensan que deberíamos ir con las variables de sesión en el servidor.

Las principales razones por las que creo que las cookies son un mejor enfoque es simplemente porque no dependemos del servidor de la aplicación en un escenario de balance de carga.

La razón principal contra el uso de cookies es el manejo de las cookies podría ser complicado.

¿Cuál es su opinión sobre este tema?

EDITAR 1:

Ok. Veo en los primeros mensajes que ninguno de los enfoques es mejor. ¿Cuál será el enfoque de deseo entonces?

Answer 1

Hay dos problemas aquí. Primero es la diferencia entre las cookies y la sesión. A menos que esté utilizando sesiones sin cookies (como identificadores únicos en la URL), la sesión es solo una cookie con una caducidad muy corta. Puede configurar fácilmente una aplicación para compartir la sesión en varios servidores mediante el uso de un servidor de estado (ScaleOut, Velocity, SQL Server)

Eso, por supuesto, supone que está utilizando la cookie del usuario para almacenar sólo un identificador único, y la vinculación que volver a todos los datos verdaderos en el servidor, probablemente en una base de datos. Sin embargo:

Almacenar datos confidenciales en la cookie de un usuario, incluso si está encriptada, no es realmente que es seguro, porque tiene que ser descifrable, lo que significa que es vulnerable. Cada vez que elige usar encriptación bidireccional en su aplicación, está asumiendo una carga de criptografía mucho más pesada para mantener el mismo nivel de seguridad. Si no tiene una considerable experiencia criptográfica a su disposición, probablemente sea mejor tomar la ruta segura y simplemente no hacerlo.

Así que en resumen, el uso integrado en sesión o hágalo usted mismo, de cualquier manera asegúrese de que la única pieza de información que se envía al cliente es una identificación imposible de adivinar que se ata de nuevo a los datos almacenados en su extremo.

Remembering a user with a cookie:

Asignar ... una identificación temporal asociado a ese usuario, como un GUID.Dado que los GUID son astronómicamente únicos y prácticamente a prueba de colisiones, también son prácticamente imposibles de adivinar o predecir desde fuera del sistema.

La ventaja de rodar su propia sesión basada en cookies/"recuérdame" funcionalidad es lo que da más control sobre cuánto tiempo se conserva la información, distribuida, etc. Por otra parte, representa más trabajo , algunos de los cuales están re-implementando funcionalidades que vienen de fábrica con la sesión de ASP.NET. Por lo general, recomiendo usar lo que ya existe, a menos que pueda articular claramente algún requisito empresarial que lo elimine como una opción.

Answer 2

El enfoque tradicional es Sesión respaldada por SqlSessionStateProvider.

El enfoque moderno parece ser utilizar la base de datos para el almacenamiento y utilizar un caché (memcached) en la parte frontal de la base de datos para acelerar las búsquedas. Pero la sesión ya no está disponible, al igual que las cookies cifradas (a excepción de la cookie de autenticación).

Answer 3

Sí, sospecho que el manejo de las cookies puede ser complicado.

Recomendaría usar como ASP.NET StateService, que se puede ejecutar en cualquier máquina, para manejar las sesiones.

Si va por la ruta de las cookies, debe tener mucho cuidado con la forma de hacerlo, y a menos que sea un experto, seguramente hará algo mal.

Answer 4

No entiendo por qué la Cookie está teniendo un mal golpe aquí. He visto el enfoque de Cookie utilizado en algunos sistemas muy grandes y nunca lo vi pirateado.

Answer 5

Desde un punto de la arquitectura, lo que debería estar pensando es la escala esperada de esta aplicación. Y muy probablemente, lo más inteligente es comenzar con la funcionalidad de sesión incorporada de ASP.NET. Más tarde, Si usted encuentra que usted está realmente necesitarlo, a continuación, añadir ya sea:

1. Menor a medio escalabilidad: El equilibrio de carga con sesiones pegajosas, o equilibrio de carga basándose en la dirección IP de la solicitud (& sigue utilizando ASP. Sesión NET).
2. media a alta escalabilidad: Un almacenamiento de sesión compartida en RAM, es decir, compartida ASP.NET StateService, proyecto "velocidad", ScaleOut SessionServer, etc.
3. alta escalabilidad: Un sistema de sesión basada en cookies de fabricación casera que es completamente 'sin estado' entre servidores web, en el sentido de que está basado en secretos precompartidos y hash que se validan sin consultar un almacén de sesión central. Si realiza esta ruta, debería considerar almacenar configuraciones de usuario no confidenciales en la cookie, para escalar esto también.

El beneficio de la sesión completamente basada en cookies es que es infinitamente escalable. Cada vez que tenemos un nuevo usuario, también obtenemos una nueva PC remota que puede almacenar su estado de sesión para nosotros, para 'gratis'. Por supuesto, el hash en nuestros servidores frontend web requiere algo de CPU, pero el nivel frontend es sin estado y fácil de escalar. La desventaja es que es más trabajo de desarrollo.

Ask Bjørn Hansen tiene una visión general de las sesiones en las cookies in these presentation slides, from around slide 16 and forward. Theo Schlossnagle escribió sobre ellos en his book Scalable Internet Architectures. Here is a good scientific paper para hacer cookies realmente seguras, con mejor seguridad que las propuestas de Ask y Theo, si me sirve la memoria.

Tenga en cuenta que puede que no necesite tanta escalabilidad como podría pensar. Como ejemplo, Stack Overflow es atendido solo por 2 servidores frontend, con un equilibrador de carga que divide el tráfico por la dirección IP del usuario. Esto hace que la sesión local de ASP.NET en cada servidor web de frontend funcione de forma normal, siempre y cuando todos los servidores web estén operativos, una solución aceptable y muy simple para la mayoría de los sitios con 2-5 servidores web.

Hay una consideración que puede invalidar lo anterior. Si encuentra que necesita un caché compartido para otros datos (resultados de consultas SQL, resultados de cálculos reutilizables pero muy costosos para la CPU), y ya va a implementar dicho caché, entonces solo lo hace sentido para pegar sesiones en este caché también.Ejemplos del tipo de caché compartida de la que estoy hablando son Memcached, Microsoft project "Velocity", Shared Cache, ScaleOut StateServer y otros. Muchos sitios no necesitarán esto, pero es una muy buena solución. Esta solución puede ser más accesible en términos de precio & tiempo de desarrollo una vez que se lanza el proyecto "Velocity", dependiendo de las intenciones de Microsoft con "Velocity".

Conclusión

1. ¿Sólo necesita sesiones compartidas entre servidores frontend web, o necesita esto para otros datos, así (resultados SQL almacenamiento en caché, etc.)? ¿Necesitas una memoria caché compartida en RAM en general? Si es así, tendrá que buscar en el middleware compartido de caché/clúster en general.
2. Si no, ¿sabe en qué escala estará operando? Si lo hace, entonces debería poder decidir cuál de las 4 opciones de datos de la sesión (desde la sesión incorporada de ASP.NET a las cookies) le queda mejor.
3. Si recién está comenzando y no sabe a cuántos usuarios atraerá, entonces comenzaría con la funcionalidad de sesión integrada de ASP.NET y solo agregaría soluciones más complejas cuando sea necesario.

Answer 6

si el usuario borra las cookies de la información del navegador se perderá con seguridad. Este no es el caso para la sesión