Autorización de una computadora para acceder a una aplicación web

Question

Tengo una aplicación web y tengo la tarea de agregar un inicio de sesión seguro para reforzar la seguridad, similar a lo que Google ha agregado a las cuentas de Google.

caso de uso

En esencia, cuando un usuario inicia una sesión, queremos detectar si el usuario ha autorizado previamente este equipo. Si la computadora no se ha autorizado, al usuario se le enviará una contraseña de un solo uso (por correo electrónico, SMS o llamada telefónica) a la que debe ingresar, donde el usuario puede elegir recordar esta computadora. En la aplicación web, realizaremos un seguimiento de los dispositivos autorizados, lo que permite a los usuarios ver cuándo y dónde iniciaron sesión desde ese dispositivo, y desautorizar los dispositivos si así lo desean.

Requerimos una solución que sea muy ligera (es decir, que no requiera instalación de software del lado del cliente), y que funcione con Safari, Chrome, Firefox e IE 7+ (desafortunadamente). Ofreceremos seguridad x509, que brinda la seguridad adecuada, pero aún necesitamos una solución para los clientes que no pueden o no quieren usar x509.

Mi intención es almacenar información de autorización usando cookies (o, potencialmente, usando almacenamiento local, degradando a flash cookies, y luego cookies normales).

A primera vista

pista dos valores separados (datos o galletas locales): un hash que representa una, así como un contador dispositivo contador de sesión segura. Ambos valores son impulsados ​​(y grabados) por la aplicación web y dictados al cliente. La ficha de SSO depende del dispositivo así como de un número de secuencia. Esto efectivamente permite que los dispositivos sean desautorizados (todos los tokens SSO se vuelven inválidos) y mitiga la repetición (no de manera efectiva, por lo que estoy haciendo esta pregunta) a través del uso de un número de secuencia, y usa un nonce.

Problema

Con esta solución, es posible que alguien acaba de copiar los SSO y fichas de dispositivos y su uso en otra solicitud. Si bien el número de secuencia me ayudará a detectar dicho abuso y, por lo tanto, desautorizar el dispositivo, la detección y la respuesta solo pueden ocurrir después de que el dispositivo válido y la solicitud maliciosa intenten acceder, lo cual es tiempo suficiente para que se produzcan daños.

Tengo ganas de usar HMAC sería mejor. Rastree el dispositivo, la secuencia, cree un nonce, timestamp y hash con una clave privada, luego envíe el hash más esos valores como texto sin formato. El servidor hace lo mismo (además de validar el dispositivo y la secuencia) y lo compara. Eso parece mucho más fácil y mucho más confiable ... suponiendo que podamos negociar, intercambiar y almacenar claves privadas de forma segura.

Pregunta

Entonces, ¿cómo puedo negociar de forma segura una clave privada para el dispositivo autorizado, y luego almacenar de forma segura esa clave? ¿Es más posible, al menos, si me conformo con almacenar la clave privada usando almacenamiento local o flash cookies y simplemente digo que es "lo suficientemente bueno"? O bien, ¿hay algo que pueda hacer con mi borrador original para mitigar la vulnerabilidad que describo?

Answer 1

Sospecho que está pidiendo más seguridad de la que el sistema, como se describe, puede proporcionar. En pocas palabras, si no puede controlar al cliente, puede (incorrectamente) usar el SSO y los tokens de dispositivo en innumerables formas (no intencionadas), como usted sabe. No importa qué tan bien diseñe las otras partes de su sistema; este es el talón de Aquiles de tu sistema.

Dicho de otra manera, en el sistema como lo ha descrito, está asignando tareas y confiando en el navegador web del cliente para proporcionar su token de dispositivo y token SSO. ¿Derecha? Si es así, ¿cómo puedes evitar el movimiento de estos tokens a otros dispositivos? (Vea las estrategias de mitigación, a continuación.)

Ahora, para responder a sus preguntas de frente con esto en mente:

"Entonces, ¿cómo puedo firmemente negociar una clave privada para dispositivo autorizado, y luego, ¿almacenas de forma segura esa llave?

No hace daño hacer esto, pero no va a ayudar, como expliqué anteriormente.

"¿Es más posible, al menos, si me acomodo para almacenar la clave privada usando galletas de almacenamiento o memoria flash local y sólo decir que es 'suficientemente bueno'?

que no lo sé qué es "lo suficientemente bueno". Debe comunicar claramente el ataque de "movimiento de tokens" y ayudar al cliente a tomar una decisión informada.

"O, ¿hay algo que pueda hacer en mi borrador original para mitigar la vulnerabilidad? ¿Describo? "

Sin duda existen estrategias de mitigación que dependen de su base de instalación de usuario y de su tolerancia al riesgo.

La pregunta clave, a mi entender, pensar en las habilidades y habilidades del tipo de persona que podría mover fichas de una máquina a otra, puede su estrategia de mitigación hacer una mella significativa en ese comportamiento sin degradar el sistema rendimiento y usabilidad para usuarios "honestos"?

Aquí están algunas ideas:

• Usted podría utilizar autenticación de dos factores, tales como RSA SecurID. Esto no evitará el movimiento de fichas de máquina, pero requeriría que el TFA se mueva con él.

• Puede intentar ofuscar u ocultar las copias locales de estos tokens, pero esto parece ser una cuestión de seguridad solo a través de la oscuridad.

• Puede verificar la dirección MAC de una máquina. Si es más difícil clonar una dirección MAC que mover un token de dispositivo, esta podría ser una capa útil de seguridad.

• Puede intentar requerir el uso de ciertos navegadores personalizados que "bloquean" el acceso a estos tokens. Esto es solo una idea; No sé si es práctico.

• Si sabe que no se supone que las máquinas se muevan físicamente, puede examinar las propiedades de la red para buscar pruebas de que la máquina se encuentra en una ubicación de red diferente y, por lo tanto, su ubicación física.

• Si consulta y almacena (en el servidor, no en el cliente) información de configuración de la computadora, puede detectar si un token se mueve de una máquina con una configuración a una máquina con una diferente. (Este enfoque, por supuesto, se quejaría cuando una máquina se actualizara).)

• En lugar de almacenar tokens de dispositivo local, puede requerir la instalación de una aplicación que proporcione una API de autenticación a la aplicación web. Esta aplicación podría integrarse en algún lugar de la computadora que sea difícil de piratear, eliminar o mover. (De esta manera, esta aplicación proporcionaría un sistema de "autenticación de dos factores" para la máquina.)

• En concierto con, o por separado de la idea anterior, se puede instalar una aplicación separada "llamar a casa" en el dispositivo. Sería "check-in" de vez en cuando con su servidor. Si cambia la ubicación de la red, la configuración del dispositivo o deja de responder, puede denegar el acceso en consecuencia.

Espero que esto ayude. No me considero un experto en seguridad, pero me gusta pensar en los problemas de diseño. Puede obtener algunas respuestas mejores si pregunta más al https://security.stackexchange.com/)

Answer 2

¿Qué hay de la captura de la dirección MAC de la computadora y el almacenamiento de esa información en la base de datos también? Las direcciones MAC como usted sabe son exclusivas de todas las computadoras, versa una dirección IP.

Getting MAC address on a web page using a Java applet

mirar en línea hay varias maneras de capturar las direcciones MAC a través de las páginas web y applets.