Agregar la API HTTPS a un sistema de hardware heredado que usa contraseñas numéricas cortas

3

Trabajo con un sistema de hardware que tradicionalmente autentica a los usuarios mediante la introducción de una contraseña numérica corta en un teclado físico. A pesar de la pequeña entropía de contraseñas, este sistema ha demostrado ser bastante robusto porque existen mecanismos para detectar la fuerza bruta (entrada de contraseña incorrecta repetida). Cada usuario tiene una cadena de nombre asociada y una contraseña numérica. La cadena de nombre se utiliza solo para fines administrativos y no para el proceso de autenticación. Entonces, para ser claros: la única manera de que un usuario interactúe con el sistema es estar en el sitio y caminar hasta un teclado físico, en cuyo punto solo tienen X intenta ingresar la contraseña numérica correcta.

Ahora deseamos introducir el acceso remoto de dispositivos móviles al sistema mediante un servidor HTTPS integral y una API REST. Debido a que el sistema es una plataforma integrada muy restringida y sin metal, la implementación de un servidor HTTPS ha sido posible (y ahora se ha logrado), pero creo que acomodar un esquema basado en token como OAuth será demasiado difícil en este momento, y por lo tanto, deseo confiar en la autenticación básica encriptada TLS.

Para cumplir con los estándares, los usuarios remotos deberán proporcionar una contraseña cada vez que utilicen la aplicación del teléfono. La administración del producto inevitablemente estipulará que las cadenas de nombre de usuario y las contraseñas existentes se utilizan para autenticar a un usuario de forma remota a través de REST HTTPS (en otras palabras, cuando usan la aplicación del teléfono), pero claramente las contraseñas numéricas cortas existentes podrían ser forzadas por la fuerza bruta Fácilmente, y sospecho que intentar implementar un mecanismo de bloqueo a través de HTTPS podría ser difícil y problemático. Cambiar el sistema existente para usar contraseñas más largas y complejas no es una opción porque el sistema existente no las admite. Por lo tanto, llego a la conclusión de que cada usuario necesitará una contraseña secundaria de mayor entropía para el acceso remoto, junto con su contraseña numérica heredada. Sospecho que a la administración de productos, sin embargo, no les va a gustar el hecho de que el usuario ahora tenga que memorizar y usar una contraseña de acceso remoto por separado.

El esquema que he pensado para evitar esto es el siguiente:

  • El usuario configura inicialmente su aplicación para que funcione con el dispositivo de hardware. El dispositivo de hardware proporciona al usuario (a través de su LCD) una clave larga de alta entropía. El usuario ingresa esa clave larga en su aplicación móvil.

  • La aplicación almacena internamente esa clave de forma permanente, asociada con la contraseña numérica corta del usuario.

  • Cada vez que el usuario desea usar la aplicación, ingresa su contraseña numérica. Si la aplicación tiene una clave almacenada internamente para esa contraseña, entonces se usa dentro del encabezado de Autorización Básica (posiblemente adjunta a la contraseña heredada) para realizar llamadas de la API HTTPS al hardware.

De esta manera, existe una contraseña de alta entropía para fines de acceso remoto, lo que reduce el riesgo de fuerza de autenticación básica. La contraseña heredada corta ahora se usa solo para que la aplicación recupere la contraseña HTTPS del almacenamiento local. En cierto sentido, supongo que esto es como compartir previamente un 'sal' a través de un canal de comunicación separado (que en este caso sería el usuario que lee la clave en la pantalla LCD del hardware). Logra el objetivo final de dar al usuario la impresión de que está accediendo al sistema (a través de la aplicación) por medio de su contraseña numérica regular.

El único defecto que veo con esto es que se basa en el dispositivo móvil que almacena la clave de acceso remoto. Cuánta de una vulnerabilidad que presenta es una incógnita para mí en este momento. Lo que estoy pensando es que, si el proceso de Autenticación básica requiere una concatenación de la clave remota (almacenada permanentemente) y la contraseña numérica corta (ingresada por el usuario cada vez, nunca almacenada) significa que cualquier cosa que esté almacenada permanentemente en el dispositivo no es suficiente para que un atacante pueda acceder sin más trabajo.

Teniendo en cuenta mis limitaciones, ¿existen fallas u oportunidades de mejora con lo que he propuesto?

    
pregunta Trevor 08.11.2015 - 13:05
fuente

1 respuesta

1

Su solución suena bien, la vulnerabilidad es como mencionó el almacenamiento local. Dado que la contraseña larga está "salada" con el PIN corto, aún es propenso a los ataques si se conoce la contraseña larga.

Una forma de evitar esto es utilizar un certificado TLS cliente que se presentará a petición del servidor. Esto tiene la ventaja de no poder recuperar el certificado almacenado (sin esfuerzo) y todo el zoológico de seguridad del certificado (especialmente la revocación).

    
respondido por el WoJ 08.11.2015 - 18:37
fuente

Lea otras preguntas en las etiquetas