¿Cuál es la forma más segura de identificar un dispositivo sin acción humana, por favor?

Question

¿Cuál es la forma más segura de identificar un dispositivo sin acción humana, por favor?

#1 de Conor Mancone (1 votos)
#2 de lakano (0 votos)

1

Quiero permitir que los usuarios de nuestro sitio web restrinjan el acceso a su cuenta desde dispositivos que hayan autorizado explícitamente. Esto se comprobará en la conexión y cada vez que cambie la dirección IP.

Para hacer esto, debo identificar el dispositivo y debo evitar que otro dispositivo pueda pasar por un dispositivo autorizado.

Podría, por ejemplo, guardar un UUID en una cookie segura (marcas: httpOnly + secure) que el servidor (en HTTPS + HSTS) podría verificar. Sin embargo, a través de un proxy MITM, el atacante podría descubrir el token y usarlo tantas veces como quiera en varias máquinas e incluso cuando el usuario ya no esté conectado al proxy infectado.

Creo que es posible reducir los riesgos mediante la combinación de esta técnica con una llamada de API de inserción web. Esto requiere, por supuesto, un navegador que lo admita (~ 80%) y el usuario acepta recibir nuestras notificaciones. La idea sería que el servidor que recibe el UUID de la cookie, envíe una notificación de inserción que contenga un token aleatorio al dispositivo, luego el dispositivo reenvíe el token al servidor para demostrar que es realmente el dispositivo autorizado.

Este método no resuelve los ataques de proxy MITM, pero una vez que la persona ya no está detrás de esta red infectada, el atacante ya no puede falsificar la identificación del dispositivo.

Las notificaciones push están cifradas, pero también puedo cifrar [EDIT: ofuscar] el token aleatorio enviado mediante una simple operación XOR con el valor UUID de la cookie como clave.

¿Tiene la forma más segura de identificar un dispositivo sin necesidad de acción humana, por favor?

[EDITAR: Precisamente, la suscripción a la notificación de inserción se realiza solo una vez, y se puede solicitar que se realice desde una red segura, como en casa, para evitar el proxy MITM mientras se realiza la suscripción.]

attacks identity-theft man-in-the-middle identity

pregunta lakano 06.10.2017 - 18:03

fuente

2 respuestas

1

No estoy seguro de si su sugerencia de notificación push realmente va a ayudar. Para que funcione, el cliente todavía tiene que "suscribirse" a las notificaciones push. ¿Qué evitaría que un MITM intercepte la solicitud del cliente final para suscribirse a notificaciones automáticas y suscribirse en su lugar?

Internet está intrínsecamente construido alrededor del concepto de clientes "anónimos" que inician conversaciones con servidores. Es posible que un cliente identifique de forma única un servidor a través de la validación de certificados SSL, pero nada de Internet está realmente diseñado para hacer lo contrario.

Lo que realmente se reduce a esto es que si hacer lo que querías hacer fuera fácil y a toda prueba, entonces todos los servidores de todo el mundo lo harían y las credenciales robadas serían cosa del pasado. Eso obviamente no es el caso, sin embargo.

respondido por el Conor Mancone 06.10.2017 - 18:27

fuente

Lea otras preguntas en las etiquetas attacks identity-theft man-in-the-middle identity

¿Se puede explotar remotamente un malicous.dll descargado ubicado en el directorio "drive by download"? La sesión del shell del comando Metasploit murió a causa de EOFError

score 0 · Accepted Answer

Me respondo a mí mismo después de una investigación.

El certificado TLS del cliente no se puede usar mientras que los navegadores no permitirán importar fácilmente el certificado. Actualmente, la mayoría de los navegadores requieren acciones humanas complejas: descargue el archivo de certificado, ingrese en configuración, avanzado, administración de certificados, importe, seleccione el archivo que desea importar. Es una muy mala experiencia para el usuario, no podemos pedirle al usuario que haga esto después de registrarse en nuestro sitio web.

Pero, podemos tener algo similar, con Web Crypto API (todas las funciones no son totalmente compatibles con todos los navegadores, que requieren polyfill). Generamos claves asimétricas públicas / privadas cuando el usuario solicita la autorización del dispositivo.

Luego, en el lado del servidor, podemos guardar la clave pública del dispositivo y el hash asociado (SHA256) de la clave pública como un «ID de dispositivo». Cada vez que el usuario realiza una solicitud a la API, agregamos en el encabezado el ID de dispositivo y una prueba con una firma, el hash de solicitud firmado por la clave privada del dispositivo (agregaremos un nonce para evitar el ataque de repetición).

En el lado del cliente, las claves se guardan cifradas por la contraseña de usuario dentro de IndexedDB. Por supuesto, si el usuario borra los datos de indexedDB del sitio, la autorización para este dispositivo se pierde.