Prevención de dispositivos usando el mismo secreto OTP

Entiendo totalmente su necesidad, ya que escanear el Código QR con los Autenticadores de Google KeyURI resultará en "copias" de la posesión de la autenticación.

Lo suficientemente interesante es que hay un RFC para esto: enlace Pero mi sospecha es que esto podría ser una exceso de bits.

Estoy trabajando en nuestro propio servidor de autenticación que, aparte de muchos otros dispositivos de autenticación, también es compatible con aplicaciones de teléfonos inteligentes como Google Authenticator que escanea el secreto OTP en "Texto sin formato". Como dije, realmente no me gusta esto, así que también empezamos a pensar en mejorar el proceso de implementación. Estos son nuestros pensamientos hasta ahora: enlace

Básicamente, queremos poder registrar un teléfono inteligente sin conexión a Internet. A veces, el teléfono inteligente no tiene una conexión o, a veces, el servidor de autenticación no puede acceder al servidor de autenticación, sino al cliente de escritorio. Así que pensamos en seguir confiando en el código QR.

Pero en lugar de solo transportar la clave secreta dentro del código QR y, por lo tanto, hacer que el token se pueda copiar a muchos teléfonos inteligentes, necesitamos un segundo componente generado por el teléfono inteligente. La forma más sencilla es esta:

1. El servidor de autenticación proporciona el primer componente de la clave secreta en un código QR
2. El usuario escanea este código QR con su nueva aplicación brillante
3. La aplicación genera el segundo componente y simplemente muestra esto al usuario.
4. El usuario escribe este segundo componente en la página de inscripción del servidor de autenticación.
5. Tanto la aplicación de servidor como la de teléfono inteligente calculan la clave secreta final según el componente generado por el servidor y el componente generado por la aplicación de teléfono inteligente.

Plus : el flujo de trabajo es bastante sencillo y no está sujeto a errores

Menos : un usuario malvado aún podría escribir el primer componente del servidor y el segundo componente generado por el teléfono inteligente y calcular "manualmente" la clave secreta y usar esta clave secreta en varias aplicaciones de teléfonos inteligentes. . Pero esto sigue siendo un proceso desagradable. El objetivo principal era proteger de los usuarios perezosos y malvados, que podrían simplemente preguntar a su colega: "Oye, escanea mi token también".

Tengo curiosidad, que piensas de esto. Si te gusta esto, síguenos en github o contribuye, quizás esto también sea una solución para ti.

Si estás diseñando tu propia aplicación de autenticación; en lugar de escanear el token OTP, escanee un token de autorización que luego se usará para recuperar el OTP de un servidor. El servidor puede configurarse para liberar el token solo una vez. Acumule el certificado que se enlaza en su aplicación, y usted también es bueno.

El flujo se vería así.

• El usuario solicita el token OTP del sitio web
• El usuario abre la aplicación y escanea el código QR, que contiene una clave de API de uso único
• La aplicación luego se comunica con el servidor, verifica el certificado con el certificado anclado
• La aplicación envía una clave API de uso una sola vez, el servidor devuelve el token OTP y marca la clave API como inactiva.

Es posible que desee utilizar el ID de dispositivo para implementar un secreto determinista único por dispositivo como se describe en RFC 4226 , nada hace cumplir el secreto que se transmitirá (pero se recomienda utilizar la generación aleatoria).

 We distinguish two different cases:

      - A single master key MK is used to derive the shared secrets;
        each HOTP device has a different secret, K_i = SHA-1 (MK,i)
        where i stands for a public piece of information that identifies
        uniquely the HOTP device such as a serial number, a token ID,
        etc.  Obviously, this is in the context of an application or
        service -- different application or service providers will have
        different secrets and settings.

Como alternativa a su escenario de la clave aleatoria generada en la primera ejecución, la aplicación puede usar el dispositivo uuid como clave de encriptación en su 1 y 2, lo que dificulta la reproducción en otro dispositivo.