security - redes - informacion mediatica
Cookies de sesión firmadas ¿Una buena idea? (5)
¿Qué le hace pensar que esto mejorará el rendimiento en comparación con las ID de sesión segura y la recuperación de la información de usuario y hora del componente del servidor de la sesión?
Si algo debe ser a prueba de manipulaciones, no lo ponga en las manos de los niños pequeños. Como en, no se lo dé al cliente en absoluto, incluso con el bloqueo a prueba de manipulaciones.
Ignorando los problemas ideológicos, esto se ve bastante decente. Usted no tiene un nonce. Deberías agregar eso. Solo una basura al azar que almacene junto con el ID de usuario y la hora, para evitar la repetición o la predicción.
En un esfuerzo por aumentar el rendimiento, estaba pensando en tratar de eliminar una simple "cookie de sesión", pero encriptar toda la información en la misma cookie.
Un ejemplo muy simple:
userid= 12345
time=now()
signature = hmac(''SHA1'',userid + ":" + time, secret);
cookie = userid + '':'' + time + '':'' + signature;
El tiempo se usaría para un tiempo máximo de caducidad, de modo que las cookies no se mantendrán para siempre.
Ahora, la gran pregunta: ¿es esta una mala idea?
¿Sería mejor utilizar AES256 en su lugar? En mi caso, los datos no son confidenciales, pero no deben modificarse bajo ninguna circunstancia.
EDITAR
Después de algunas buenas críticas y comentarios, me gustaría añadir esto:
- El ''secreto'' sería único por usuario e impredecible (cadena aleatoria + ID de usuario?)
- La cookie caducará automáticamente (esto se hace en función del valor del tiempo + una cierta cantidad de segundos).
- Si un usuario cambia su contraseña, (o tal vez incluso se desconecta?), El secreto debería cambiar.
Una última nota: estoy tratando de encontrar soluciones para disminuir la carga de la base de datos. Esta es solo una de las soluciones que estoy investigando, pero es una de mis favoritas. La razón principal es que no tengo que buscar otro mecanismo de almacenamiento más adecuado para este tipo de datos (memcache, nosql) y hace que la aplicación web sea un poco más "sin estado".
No deberías reinventar la rueda. El manejador de sesión que viene con su plataforma de desarrollo ahora es más seguro y ciertamente más fácil de implementar. Las cookies siempre deben ser números aleatorios muy grandes que enlazan con datos del lado del servidor. Una cookie que contiene una identificación de usuario y una marca de tiempo no ayuda a endurecer la sesión del ataque.
Este manejador de sesión propuesto es más vulnerable al ataque que el uso de una función Cryptographic para cada sesión. Un escenario de ataque es el siguiente.
Es probable que esté usando el mismo secreto para su cálculo de HMAC para todas las sesiones. Por lo tanto, este secreto podría ser forzado por un atacante que inicia sesión con su propia cuenta. Al mirar su identificación de sesión puede obtener todo excepto el secreto. Entonces el atacante podría forzar en bruto el secreto hasta que el valor de hmac pueda reproducirse. Usando este secreto, puede reconstruir una cookie administrativa y cambiar su user_id=1 , lo que probablemente le otorgue acceso administrativo.
Sé que esta pregunta es muy antigua ahora, pero pensé que sería una buena idea actualizar las respuestas con una respuesta más actual. Para alguien como yo que pueda tropezar con eso.
En un esfuerzo por aumentar el rendimiento, estaba pensando en tratar de eliminar una simple "cookie de sesión", pero encriptar toda la información en la misma cookie.
Ahora, la gran pregunta: ¿es esta una mala idea?
La respuesta corta es: No, no es una mala idea, de hecho, esta es una muy buena idea y se ha convertido en un estándar de la industria.
La respuesta larga es: depende de su implementación. Las sesiones son geniales, son rápidas, simples y fáciles de obtener. Sin embargo, como un sistema sin estado funciona bien, es un poco más complicado de implementar y puede estar fuera del alcance de proyectos más pequeños.
Implementar un sistema de autenticación basado en Tokens (cookies) es muy común ahora y funciona muy bien para sistemas / apis sin estado . Esto hace posible autenticarse para muchas aplicaciones diferentes con una sola cuenta. es decir. inicie sesión en {sitio no asociado} con Facebook / Google.
Implementar un sistema oAuth como este es un GRAN tema en sí mismo. Así que te dejo con un poco de documentación oAuth2 Docs . También recomiendo buscar en Json Web Tokens (JWT) .
extra
Una última nota: estoy tratando de encontrar soluciones para disminuir la carga de la base de datos. Esta es solo una de las soluciones que estoy investigando
Redis funcionaría bien para descargar consultas de bases de datos. Redis es un sistema de almacenamiento simple en memoria. Almacenamiento muy rápido, ~ temporal que puede ayudar a reducir los hits de DB.
Sí, esta es una mala idea.
Para empezar, no es seguro. Con este esquema, un atacante puede generar su propia cookie e imitar a cualquier usuario.
Los identificadores de sesión se deben elegir de un espacio grande (128 bits) por un generador de números aleatorios criptográficos.
Deben mantenerse en privado, para que los atacantes no puedan robarlos ni suplantar a un usuario autenticado. Cualquier solicitud que realice una acción que requiera autorización debe ser a prueba de manipulaciones. Es decir, toda la solicitud debe tener algún tipo de protección de integridad, como un HMAC, para que su contenido no se pueda modificar. Para aplicaciones web, estos requisitos conducen inexorablemente a HTTPS.
¿Qué preocupaciones de rendimiento tienes? Nunca he visto una aplicación web donde la seguridad adecuada creara algún tipo de punto de acceso.
Si el canal no tiene privacidad e integridad, usted se abre a los ataques man-in-the-middle. Por ejemplo, sin privacidad, Alice envía su contraseña a Bob. Eve husmea y puede iniciar sesión más tarde como Alice. O bien, con integridad parcial, Alice adjunta su cookie firmada a una solicitud de compra y se los envía a Bob. Eve intercepta la solicitud y modifica la dirección de envío. Bob valida el MAC en la cookie, pero no puede detectar que la dirección ha sido alterada.
No tengo ningún número, pero me parece que las oportunidades para los ataques de hombre en el medio están en constante crecimiento. Noto que los restaurantes usan la red wi-fi que ponen a disposición de los clientes para el procesamiento de su tarjeta de crédito. Las personas que se encuentran en bibliotecas y en lugares de trabajo a menudo son susceptibles de husmear si su tráfico no supera HTTPS.
Un token firmado es un buen método para cualquier cosa en la que desee emitir un token y luego, cuando se lo devuelve, pueda verificar que haya emitido el token, sin tener que almacenar ningún dato en el servidor. Esto es bueno para características como:
- time-limited-account-login;
- restablecimiento de contraseña;
- formas anti-XSRF;
- time-limited-form-submission (anti-spam).
No es en sí mismo un reemplazo de una cookie de sesión, pero si puede eliminar la necesidad de almacenamiento de sesión en todo lo que probablemente sea bueno, incluso si la diferencia de rendimiento no va a ser enorme.
HMAC es una forma razonable de generar un token firmado. No va a ser el más rápido; Es posible que pueda salirse con la suya con un simple hash si conoce y puede evitar los ataques de extensión. Te dejaré para decidir si eso vale la pena el riesgo para ti.
Supongo que hmac() en el idioma que está usando está configurado para usar una clave secreta adecuada del lado del servidor, sin la cual no puede tener un token seguro firmado. Este secreto debe ser fuerte y estar bien protegido si va a basar todo su sistema de autenticación en él. Si tiene que cambiarlo, todos se desconectarán.
Para fines de inicio de sesión y restablecimiento de contraseña, es posible que desee agregar un factor adicional al token, un número de generación de contraseña. Puede volver a utilizar la sal de la contraseña hash en la base de datos para esto si lo desea. La idea es que cuando el usuario cambie las contraseñas debe invalidar los tokens emitidos (a excepción de la cookie en el navegador que hace el cambio de contraseña, que se reemplaza por uno reeditado). De lo contrario, un usuario que descubre que su cuenta se ha visto comprometida no puede bloquear a otras partes.