Verificación segura del PIN si HTTPS es descifrable por un tercero

-1

Estoy desarrollando un sistema donde las aplicaciones móviles se comunican con el servidor a través de HTTPS. La comunicación consta de dos fases: al principio, la aplicación se "registra" en el servidor: entre otras cosas, el usuario elige su PIN y se envía al servidor y se almacena allí. Supongamos por ahora que esta fase es segura y que toda la información se ha intercambiado de forma segura y que no se filtró ninguna información.

La segunda fase de comunicación comienza después del registro. La aplicación envía las solicitudes al servidor, y con cada solicitud, se solicita al usuario que ingrese el PIN que se agrega a la solicitud para autenticar al usuario (en realidad, es solo uno de los pasos de autenticación, ya que también utilizamos la autenticación del certificado de cliente). Mi pregunta es la siguiente: ¿es posible evitar que este PIN se exponga en caso de que un atacante pueda descifrar nuestra comunicación HTTPS? Parece que la mayoría de las soluciones fallan porque el atacante puede enumerar los PIN, ya que generalmente tienen entre 4 y 6 caracteres (por ejemplo, al pasar por un hash de PIN fallan debido a esto).

Podemos intercambiar algunos datos adicionales en la fase de registro, según sea necesario.

    
pregunta poe123 30.06.2016 - 13:38
fuente

1 respuesta

1

Puede implementar su propia capa de cifrado además de la que proporciona TLS. Ya que dice que "podemos intercambiar algunos datos adicionales en la fase de registro", creo que la solución más sencilla sería compartir una clave de cifrado simétrica (por ejemplo, AES) durante el registro y luego cifrar toda la comunicación posterior con eso. (La IV evitará la fuerza bruta incluso si solo hay un número limitado de posibles textos sin formato).

Tenga en cuenta que esto se basa totalmente en la seguridad de la conexión original cuando se intercambian el PIN y la clave. Si eso falla, este esquema falla. Otra opción sería enviar la aplicación con su clave pública codificada en ella. Haga que la aplicación genere una clave simétrica aleatoria, cifrada de forma asimétrica con su clave pública y envíela al servidor. Esto se puede hacer solo una vez o una vez por sesión. Pero ahora estamos empezando a construir un protocolo criptográfico completo ...

Esto sería un trabajo, y tal vez no valga la pena el esfuerzo. La principal amenaza probablemente no sea la ruptura de TLS de todos modos, pero el teléfono de los usuarios está infectado con malware o su servidor está siendo pirateado.

En vez de eso, te aconsejaría que obtuvieras el TLS correctamente para que un atacante nunca pueda descifrarlo en primer lugar. En el caso de una aplicación móvil, donde tiene control tanto del cliente como del servidor, esto es más fácil de hacer que para una aplicación web. Recomiendo estos pasos:

  • Elija un conjunto pequeño de juegos de cifrado seguro y solo permita que el cliente y el servidor los acepten
  • Permitir solo TLS 1.2 (o superior)
  • Implementar fijación de clave pública
respondido por el Anders 30.06.2016 - 13:57
fuente

Lea otras preguntas en las etiquetas