Riesgos de seguridad en una infraestructura de sesión dada

Question

Riesgos de seguridad en una infraestructura de sesión dada

#1 de tim (1 votos)
#2 de theabhinavdas (0 votos)

1

Quiero saber si este es un esquema adecuado para la administración de sesiones. Una vez que el usuario se ha autenticado con user / pass, el servidor devuelve session = MD5(SECRET + user_id) (junto con otros campos) donde SECRET es una cadena aleatoria (por ejemplo, 256 bits).

Luego, el cliente simplemente envía el hash session recibido con cada solicitud, y el servidor lo valida al verificar que MD5(SECRET + user_id) es igual al hash recibido.

¿Cuáles son los riesgos potenciales aquí? Supongo que si el usuario puede enviar un user_id vacío, entonces ella está un paso más cerca de SECRET , pero esto es fácilmente evitable. Además, SECRET podría cambiar cada semana aproximadamente.

(Nota: estoy usando Node como el backend para una aplicación móvil, por lo que no hay navegador ni cookies).

session-management

pregunta Carlos Navarro Astiasarán 14.08.2016 - 10:16

fuente

2 respuestas

Lea otras preguntas en las etiquetas session-management

Número mínimo de puertos necesarios para HTTP ¿Es este malware de Android?

score 1 · Answer 1

Ataque de extensión de longitud

Lo que tienes es básicamente un MAC para verificar tu valor user_id . El problema es que un MAC primitivo como MAC = md5(KEY | MESSAGE) es vulnerable a ataques de extensión de longitud .

Esto significa que un atacante con el id de usuario 1 podría, por ejemplo, suplantar a un usuario con el id 10 simplemente agregando un 0 .

Como mínimo, necesitaría usar un HMAC adecuado o usar una función hash no vulnerable como como sha3.

Expiración de token

Si no almacena ningún estado en el servidor, tiene el problema de no poder revocar un token.

Entonces, si un usuario, por ejemplo, cambia su contraseña porque sospecha que existe un compromiso, un atacante que obtuvo un token de antemano aún puede usarlo. No tiene forma de invalidarla y necesita esperar hasta que caduque de forma natural.

Solutions

Lo que parece estar buscando es sesiones del lado del cliente . Es posible que desee considerar el uso de soluciones existentes como JWT o alguna otra biblioteca existente .

Otros problemas

Como dijo @ 0x23212f, tu esquema obviamente no reemplaza a TLS y no te protegerá del hombre en los ataques medios.

Aparte de eso, debe considerar si realmente necesita sesiones del lado del cliente. Si, como sugirió en los comentarios, la única razón es evitar una consulta de base de datos, probablemente no valga la pena implementarla, o la sobrecarga de la red adicional.

score 0 · Answer 2

¿Quieres decir, aparte de los ataques MiTM (Man in The Middle)?

Porque eso sería lo más obvio para ver aquí. Si está enviando el mismo hash con cada solicitud, eso significa que existe la posibilidad de que un atacante pueda interceptar la solicitud y usarla para falsificar al usuario.

Si también desea evitar eso, puede echar un vistazo a DUKPT (Clave única derivada por transacción). Los bancos utilizan una versión patentada de DUKPT, que yo sepa.

Pero, de nuevo, realmente no iría tan lejos. Un canal de comunicación seguro ayudaría a prevenir el problema mencionado anteriormente.