¿Es esta técnica una forma segura de confirmar los detalles de la cuenta bancaria de un usuario, sin requerir que proporcionen sus credenciales?

Question

¿Es esta técnica una forma segura de confirmar los detalles de la cuenta bancaria de un usuario, sin requerir que proporcionen sus credenciales?

#1 de Steffen Ullrich (1 votos)
#2 de entrop-x (0 votos)

2

Hay muchos servicios financieros que pueden verificar la cuenta bancaria de un usuario solicitando su nombre de usuario y contraseña e iniciando sesión en su nombre. Algunos ejemplos son Coinbase y TransferWise .

Se me ha ocurrido una forma para que un usuario verifique los detalles de su cuenta bancaria sin proporcionar su nombre de usuario y contraseña a un tercero. Me gustaría saber si hay fallas de seguridad con el siguiente protocolo:

El servicio de terceros inicia un servidor proxy que registra todo el tráfico.
El usuario establece una conexión TLS a través del proxy y verifica el certificado SSL del banco.
El usuario inicia sesión con su nombre de usuario y contraseña, y guarda su cookie de sesión.
El usuario inicia una nueva conexión TLS a través del proxy, que utiliza un secreto maestro diferente.
El usuario utiliza su cookie de sesión actual para obtener los detalles de su cuenta a través del proxy.
El usuario cierra la sesión e invalida la cookie de sesión.
El usuario envía el secreto principal de la conexión TLS final al servicio de terceros.
El servicio de terceros ahora puede descifrar el HTML y verificar los detalles del usuario, como su nombre completo, número de teléfono y saldos de cuenta.

Notas:

Si un banco permite que se use una cookie de sesión desde múltiples direcciones IP, el usuario podría simplemente iniciar y cerrar sesión en su propia máquina.
El usuario estaría viendo las páginas con proxy en su propia máquina, por lo que esto también funcionaría con la autenticación de dos factores.
Es posible que algunos sitios web de banca en línea no invaliden correctamente las cookies de sesión cuando un usuario cierra la sesión. Sin embargo, la mayoría (si no todos) los bancos expiran una sesión después de 10-15 minutos de inactividad, por lo que el usuario puede esperar a que la sesión expire antes de revelar la clave privada.
La página HTML podría filtrar más datos de los necesarios. Habría varias maneras de resolver esto para diferentes bancos. Muchos bancos proporcionan una API para sus aplicaciones móviles, por lo que solo podría presentar algunas solicitudes específicas de API para revelar solo la información necesaria.
En lugar de enviar la clave privada y permitir que un tercero descifre todo el HTML y las cookies, podría ser posible crear un circuito booleano encriptado que proporcione una prueba de conocimiento cero para la sesión TLS grabada. El tercero podría ejecutar un cálculo que verifique el protocolo de enlace y el certificado TLS, descifre la URL y el HTML, y luego verifique la presencia de ciertas cadenas para verificar los detalles de la cuenta del usuario. El resultado del circuito es true o false , y el tercero no podrá descubrir ninguna otra información sobre la sesión cifrada. Alternativamente, las salidas del circuito podrían ser incluso las cadenas de su nombre completo, número de teléfono y saldo de la cuenta de cheques. Voy a intentar investigar este enfoque con la biblioteca libsnark , ¡porque es una idea tan fascinante!

Una forma de implementar esto podría ser crear una aplicación de navegador basada en WebKit que los usuarios puedan descargar e instalar. La aplicación podría configurar un controlador de protocolo en su navegador, de modo que se abra cada vez que el usuario haga clic en una URL como <verification scheme>://domain/path . La aplicación funcionaría con cualquier sitio web, pero también podría usar recetas preconfiguradas para diferentes bancos.

Esto también podría implementarse directamente en Firefox y Chrome, pero eso no es muy probable. También hay maneras mucho mejores de hacer esto. Algunos bancos modernos pueden proporcionar un token OAuth con permisos de solo lectura limitados. Un banco podría incluso usar la criptografía de clave pública para simplemente firmar los detalles de su cuenta usando su clave privada (tal vez la clave privada para su certificado SSL actual).

Creo que la técnica descrita anteriormente podría ser útil, ya que puede funcionar para cualquier sitio web (no solo para la banca). Pero hágame saber si puede detectar algún problema de seguridad aquí. Estoy seguro de que he entendido mal algo acerca de TLS, o tal vez haya una forma aún más fácil de hacer esto.

banks tls

pregunta ndbroadbent 08.12.2017 - 19:48

fuente

2 respuestas

Lea otras preguntas en las etiquetas banks tls

Poner secretos en un enclave Preguntas de seguridad SQL

score 1 · Answer 1

Creo que, en teoría, el mecanismo podría funcionar, siempre que el usuario pueda confiar en su banco de que su sitio está configurado de manera que no se transfiera información confidencial dentro de la sesión de "prueba". Eso significa que al menos solo la información relevante para la prueba se incluye en la sesión de prueba, que el tercero no puede utilizar la ID de sesión HTTP y que no se reutiliza la sesión TLS, es decir, que no se usa la misma clave para proteger las sesiones TLS anteriores o posteriores.

Esto significa que no solo el usuario necesita un software especial para crear la sesión de prueba, sino también que el banco debe configurarse de manera que sea compatible con esta prueba. En mi opinión, esto hace que este concepto sea demasiado complejo y poco fiable en la práctica.

score 0 · Answer 2

Veo una vulnerabilidad potencial, aunque no estoy seguro de si realmente se puede ejecutar. El riesgo no está en el lado del cliente, sino en el lado de terceros. De hecho, primero había añadido un comentario, que eliminé después, porque me di cuenta de que estaba equivocado, y esto me hizo pensar en esta vulnerabilidad. El comentario que eliminé fue que no necesitaba el proxy de terceros, pero que podía, como usuario, registrar el flujo de TCP usted mismo y luego enviar este registro de flujo de TCP como un archivo comprimido, junto con la clave establecimiento de acuerdo, a la tercera parte, como "prueba de la sesión pasada". Pero luego me di cuenta de que esto no es una prueba, porque el contenido real de la sesión está cifrado en TLS con una clave simétrica, por lo que, como usuario, podría modificarlo como quisiera, también, porque usted también tiene La clave simétrica. También puedes calcular todo tipo de MAC con esa tecla. Si su banco le envió que tiene un saldo negativo durante la sesión, puede modificarlo para que se muestre en una cuenta con 5 millones de dólares en su cuenta. El certificado es del banco, la clave simétrica negociada es verdadera, pero el contenido puede ser determinado no solo por el banco, sino también por usted. Así que borré mi sugerencia errónea.

Sin embargo, creo que uno puede hacer lo mismo a través del proxy. Si usted, como usuario, configura un socket web falso en una de sus máquinas y, en lugar de comunicarse con el banco a través del proxy de terceros, se comunica con su máquina, que actúa como un segundo proxy, y se comunicará con el banco. puede realizar un ataque MITM en su propia sesión TLS con ese proxy, porque conoce la clave simétrica y modifica a su voluntad el contenido, como en mi comentario borrado. Si el banco le dice que está vencido, puede modificar esto sobre la marcha en su proxy y mostrar un saldo de cuenta de 5 millones de dólares, que es el flujo de TCP que el tercero descifrará.

Por supuesto, si el tercero está atento, puede ver que la dirección IP a la que fuiste no corresponde a la dirección IP de un banco. Pero tendrá un certificado correcto y una negociación de clave correcta.