Mobile OTP - ¿Seguro?

Es la primera vez que oigo esto, pero no significa que no sea muy conocido.

Suena un poco similar a OATH HOTP / TOTP . OATH se basa en RFC 4226 y parece, al menos a primera vista, más sólido. Por ejemplo, utiliza HMAC en lugar de hash simple (motp usa MD5). OATH también fue adoptado por productos como Yubikey y recientemente Google Authenticator .

Basándome en estos hechos tan poco profundos, diría que personalmente preferiría OATH en lugar de esta solución aparentemente hecha a medida. Requeriría un análisis más profundo para realmente resaltar las ventajas / desventajas de esos esquemas.

Espero que esto responda a tus dos primeras preguntas.

En cuanto a los motivos para elegirlo: la contraseña de un solo uso (OTP) no solo protege contra la interceptación a través de la línea de comunicación. Por lo tanto, si bien SSL garantizará que la contraseña (o la contraseña de un solo uso) se transporta de manera segura, OTP garantiza que, incluso si la contraseña se pierde o se la roban, no se puede reutilizar . Es único para cada sesión. Entonces, incluso si alguien miró por encima de tu hombro cuando escribiste tu contraseña, ya que es una contraseña de un solo uso, no pueden usarla nuevamente.

Hay otros beneficios para los esquemas OTP, en este caso, actúa como autenticación de segundo factor . No solo lo que sabes, sino también lo que tienes. En esos esquemas OTP basados en dispositivos móviles, generalmente se trata de una clave secreta que se almacena en su teléfono y se usa para generar la contraseña. Por lo tanto, un atacante no solo necesitará su contraseña, sino también su teléfono (o la tecla de su teléfono) para autenticarse como usted.

La mayoría de los esquemas de autenticación son complementarios a SSL y no lo reemplazarán. Incluso si el proceso de autenticación es seguro, generalmente se intercambian otros datos o se establece algún tipo de sesión. Por ejemplo, considere iniciar sesión en su cuenta bancaria y luego ver las transacciones o transferir fondos. Proteger la autenticación solo (por ejemplo, a través de OTP) no es suficiente. Lo mismo ocurre con solo proteger la conexión (utilizando SSL sin autenticación). Para protegerlo mejor, por lo general, combinaría SSL con algún tipo de autenticación de usuario.

Con respecto a su preocupación sobre el almacenamiento de PIN / clave en forma reversible en lugar de usar un hash seguro. Yo diría que esta es probablemente una compensación aceptable considerando lo que usted gana. La OTP le brinda una gran protección contra los casos en los que la contraseña estática podría filtrarse (incluido el phishing, el hombro, las personas que escriben sus contraseñas, la ingeniería social, etc.). Incluso si se filtra una contraseña OTP, limita su utilidad, ya que solo se puede usar una vez y dentro de un período de tiempo limitado. El inconveniente es que debe asegurarse de que su servidor de autenticación (y, en cierta medida, los dispositivos de usuario) estén bien protegidos. Si su servidor es su punto débil, entonces, no estoy seguro de que los hash seguros sean suficientes para protegerlo de todos modos. Además, su combinación con SSL y una contraseña estándar (con hash) realmente podría mejorar aún más su protección.

El esquema tiene algunas limitaciones de seguridad. Una contraseña de un solo uso no es segura contra los ataques de intermediarios, a menos que exista algún otro mecanismo fuera de banda para evitar los ataques de intermediarios. También es un poco incómodo de usar.

Dependiendo del contexto, puede haber mejores formas de autenticación. Por ejemplo, si va a crear una aplicación, en muchas configuraciones sería mejor usar SSL con un certificado de cliente (puede requerir un PIN o una contraseña también una vez que el canal esté configurado, si lo prefiere).

Es muy probable que el uso de la contraseña de un solo uso sea mejor que nada. Puede detener algunas amenazas.

Conclusión: todo depende de para qué planea usar esto. Dependiendo del dominio de la aplicación, puede ser una herramienta útil o puede ser subóptima. Si desea obtener consejos más específicos, le sugiero que describa el contexto de la aplicación específica en el que necesita autenticación, y tal vez explique el nivel de riesgo / modelo de amenaza que tiene en mente.

MOTP es un protocolo de autenticación. El escenario de uso previsto es un usuario con algún tipo de dispositivo móvil que desee autenticarse con un servidor; el dispositivo genera un código de autenticación que solo es válido por un tiempo limitado (unos pocos minutos). La autenticación se basa en un secreto compartido entre el lado del cliente y el lado del servidor.

En el lado del cliente, el secreto se divide en dos partes: un secreto de 64 bits que se guarda dentro del dispositivo (lo que tiene) y un PIN de 4 dígitos que el usuario debe ingresar cada vez (lo que sabe ). De esta manera, MOTP proporciona autenticación de dos factores. El dispositivo no conoce el PIN; cada vez calcula el valor de autenticación del PIN suministrado.

Un dispositivo MOTP típico tiene un teclado y una pantalla capaces de mostrar 6 dígitos, un procesador con requisitos de rendimiento muy bajos (debe poder computar un MD5 de 20 bytes en un abrir y cerrar de ojos), un reloj y, posiblemente, Alguna resistencia a la manipulación para proteger el secreto. Hay dispositivos MOTP de un solo propósito, así como implementaciones en teléfonos móviles. En un dispositivo de un solo propósito, el dispositivo muestra un código de autenticación de 6 dígitos que es válido por un par de minutos (3 minutos menos el tiempo que toma desde calcular el código de autenticación en el cliente hasta la verificación en el servidor, más o menos Las consecuencias de la deriva del reloj). En un teléfono móvil, el código de autenticación puede ser mostrado o utilizado directamente por la aplicación cliente.

MOTP tiene la ventaja de ser muy simple. Hay muchas implementaciones existentes en varios idiomas y en varias plataformas, tanto en el lado del servidor como en el lado del cliente. Por lo que yo sé, MOTP vino de la industria y ha visto poca o ninguna revisión independiente.

El PIN es parte del secreto compartido entre el cliente y el servidor. El servidor debe realizar el mismo cálculo que el cliente, necesita el PIN para eso. Podría hacer una variante de MOTP que use alguna imagen del PIN bajo alguna función de fortalecimiento en lugar del PIN en sí, pero no sería beneficioso, ya que un hash en un espacio de búsqueda de apenas 10 bits es trivial a fuerza bruta incluso si tuvieras que hacerlo por separado con cada cuenta con salado diferente. Los servidores no almacenan contraseñas porque se supone que tienen suficiente entropía para dificultar la inversión de hash por fuerza bruta, esto no se aplica a un PIN de 4 dígitos.

MOTP no es comparable con SSL; Usted usaría los dos en combinación. Los dos pueden ser utilizados de manera complementaria. SSL tiene tres partes: establece un canal seguro entre dos partes, autentica el servidor al cliente y, opcionalmente, autentica el cliente al servidor. La tercera parte a menudo se queda fuera porque la mayoría de los clientes no tienen datos de autenticación, lo que lleva a una gran cantidad de software que utiliza SSL que no admite la autenticación del cliente. MOTP puede ser una forma de autenticar un cliente en una conexión SSL. A diferencia de los certificados de cliente SSL, que típicamente autentican un dispositivo o una combinación de un dispositivo más los datos almacenados en él, MOTP está destinado a autenticar a un usuario; el paso de autenticación requiere ingresar un PIN (que normalmente no se almacena en caché).

Mobile-OTP es mucho más antiguo que HOTP / TOTP (2003 - 8 años antes de la fecha de publicación de HOTP RFC), pero no fue "promocionado" lo suficientemente bien como para convertirse en un estándar. En general, es más o menos lo mismo que TOTP con 2 diferencias principales: - El algoritmo utilizado para producir hashes es MD5, no SHA-1, pero para un desplazamiento de 10 segundos es todavía lo suficientemente seguro como (cita: "MD5 no es una limitación. Mobile-OTP no sería más seguro con un algoritmo hash diferente":
- La OTP que produce no es solo de dígitos, lo que es un poco menos fácil de usar - Los usuarios se ven obligados a usar el PIN para generar la OTP, que también es otro factor negativo desde la perspectiva de la experiencia del usuario, pero una ventaja desde el punto de vista de la seguridad.

La inscripción (generar y transferir secretos compartidos en el cliente y el servidor) también fue menos conveniente en la implementación original, pero hay iniciativas para que sea más fácil de usar