Contraseña de un solo uso basada en HMAC

La contraseña de un solo uso basada en HMAC ( HOTP ) es un algoritmo de contraseña de un solo uso (OTP) basado en un código de autenticación de mensajes basado en hash (HMAC). Cuando un cliente intenta acceder a un servidor, el servidor de destino envía un desafío al cliente. El cliente calcula entonces una respuesta que representa una contraseña de un solo uso. Esto suele formar parte de protocolos de autenticación multifactor , como el algoritmo de desafío-respuesta de la Iniciativa de Autenticación Abierta (OATH). ^{[ 1 ]}

HOTP se publicó como RFC 4226 de la IETF en diciembre de 2005, documentando el algoritmo junto con una implementación en Java. Desde entonces, el algoritmo ha sido adoptado por numerosas empresas en todo el mundo (véase más abajo). El algoritmo HOTP es un estándar abierto de libre acceso. 

El algoritmo HOTP proporciona un método de autenticación mediante la generación simétrica de contraseñas legibles por humanos, o valores , cada uno utilizado para un único intento de autenticación. La propiedad de un solo uso se deriva directamente del único uso de cada valor del contador.

Las partes que tengan la intención de utilizar HOTP deben establecer algunosparámetros ; normalmente, estos son especificados por el autenticador y aceptados o no por la entidad autenticada:

• Un método hash criptográfico H (el predeterminado es SHA-1 )
• Una clave secreta K , que es una cadena de bytes arbitraria y debe permanecer privada.
• Un contador C , que tiene 8 bytes de longitud y cuenta el número de iteraciones.
• Longitud del valor HOTP d (6–10, el valor predeterminado es 6, y se recomienda 6–8)

Ambas partes calculan el valor HOTP derivado de la clave secreta K y el contador C. A continuación, el autenticador compara su valor generado localmente con el valor proporcionado por el autenticado.

El autenticador y la entidad autenticada incrementan el contador C de forma independiente. Dado que la entidad autenticada puede incrementar el contador más que el autenticador, la RFC 4226 recomienda un protocolo de resincronización. Este protocolo propone que el autenticador intente repetidamente la verificación antes de que su contador alcance un valor determinado, dentro de un intervalo de tamaño s . El contador del autenticador continúa avanzando más allá del valor en el que la verificación tiene éxito, sin requerir ninguna acción por parte de la entidad autenticada. 

Para protegerse contra ataques de fuerza bruta dirigidos al pequeño tamaño de los valores HOTP, el RFC también recomienda implementar una limitación persistente de la verificación HOTP. Esto se puede lograr bloqueando la verificación después de un pequeño número de intentos fallidos o aumentando linealmente el retraso después de cada intento fallido.

Los códigos de 6 dígitos suelen ser proporcionados por tokens de hardware propietarios de varios proveedores que informan el valor predeterminado de d . El truncamiento extrae 31 bits o${\textstyle \log _{10}(2^{31})\approx 9.3}$dígitos decimales, lo que significa que d puede ser como máximo 10, y el décimo dígito añade menos variación, tomando valores de 0, 1 y 2 (es decir, 0,3  dígitos).

Tras la verificación, el autenticador puede autenticarse simplemente generando el siguiente valor HOTP, devolviéndolo, y luego el autenticado puede generar su propio valor HOTP para verificarlo. Cabe destacar que en este punto del proceso se garantiza la sincronización de los contadores.

El valor HOTP es la salida de diseño legible para humanos, un número decimal de d dígitos (sin omitir los ceros iniciales):

Valor HOTP = HOTP ( K , C ) mod 10 ^d .

Es decir, el valor son los d dígitos menos significativos en base 10 de HOTP.

HOTP es una truncación del HMAC del contador C (bajo la clave K y la función hash H ):

HOTP ( K , C ) = truncar(HMAC _H ( K , C )),

donde el contador C debe usarse en formato big-endian .

La truncación primero toma los 4 bits menos significativos del MAC y los usa como un desplazamiento de byte i :

truncar( MAC ) = extraer31( MAC , MAC [(19 × 8 + 4):(19 × 8 + 7)]),

donde ":" se utiliza para extraer bits desde un número de bit inicial hasta un número de bit final inclusive, donde estos números de bit tienen origen 0. El uso de "19" en la fórmula anterior se relaciona con el tamaño de la salida de la función hash. Con el valor predeterminado de SHA-1, la salida es20 bytes  , por lo que el último byte es el byte 19 (origen 0).

Ese índice i se utiliza para seleccionar 31  bits de MAC , comenzando en el bit i × 8 + 1:

extract31( MAC , i ) = MAC [( i × 8 + 1):( i × 8 + 4 × 8 − 1)].

31 bits son un bit menos que una palabra de 4 bytes. Por lo tanto, el valor se puede colocar dentro de dicha palabra sin usar el bit de signo (el bit más significativo). Esto se hace para evitar definitivamente realizar aritmética modular con números negativos, ya que tiene muchas definiciones e implementaciones diferentes. ^{[ 2 ]}

importar hashlibdef hmac_sha1 ( * , key : bytes , msg : bytes ) -> bytes :Si len ( clave ) > 64 :clave = hashlib.sha1 ( clave ) .digest ( )​​demás :clave = clave . sólo ( 64 , b ' \0 ' )o_key_pad = bytes ( i ^ 0x5c para i en key )i_key_pad = bytes ( i ^ 0x36 para i en key )devolver hashlib . sha1 (teclado numérico +hashlib . sha1 ( i_key_pad + msg ) . digest ()) .digest ( )def hotp ( * , key : bytes , ctr : int , length : int ) -> str :mac = hmac_sha1 ( key = key , msg = ctr . to_bytes ( 8 , 'big' ))desplazamiento = mac [ - 1 ] & 0xftruncado = bytearray ( mac [ offset : offset + 4 ])truncado [ 0 ] &= 0x7fvalor = int.from_bytes ( truncado , ' grande ' ) % ( 10 ** longitud )return str ( valor ) . rjust ( longitud , '0' )

otpauth://esquema URI

Algunas implementaciones de HOTP y TOTP para teléfonos inteligentes permiten a los usuarios escanear códigos QR para agregar tokens HOTP y TOTP a sus aplicaciones de autenticación. Estos códigos QR contienen identificadores uniformes de recursos (URI) con el esquema otpauth://. ^{[ 3 ]}

Las URI HOTP otpauth://comienzan con otpauth://hotp/y deben contener una etiqueta, un secreto y un contador. La etiqueta se codifica como parte de la ruta, mientras que el secreto y el contador se codifican como parámetros de consulta. La URI puede contener opcionalmente otros campos, como el número de dígitos (que por defecto es 6), el algoritmo utilizado (que por defecto es SHA1) y el nombre del emisor.

El secreto está codificado como RFC 4648 Base32 , con relleno omitido. Por ejemplo, la URI otpauth://hotp/Wikipedian?secret=JBSWY3DPFQQHO33SNRSCC&counter=42representa un token HOTP etiquetado como "Wikipedian", con el secreto Hello, world!codificado como ASCII y el contador inicial 42. Cuando se agrega a un autenticador, debería producir el código 439256.

Existen diversos proveedores que ofrecen tokens tanto de hardware como de software; para consultar algunas de estas referencias, véanse a continuación.

Los tokens de software están disponibles para (casi) todas las principales plataformas móviles/ de teléfonos inteligentes ( J2ME , ^{[ 4 ]} Android , ^{[ 5 ]} iPhone , ^{[ 6 ]} BlackBerry , ^{[ 7 ]} Maemo , ^{[ 8 ]} macOS , ^{[ 9 ]} y Windows Mobile ^{[ 7 ]} ).

Aunque la recepción inicial de parte de la prensa informática fue negativa durante 2004 y 2005, ^{[ 10 ] [ 11 ] [ 12 ]} después de que la IETF adoptara HOTP como RFC 4226 en diciembre de 2005, varios proveedores comenzaron a producir tokens compatibles con HOTP y/o soluciones de autenticación completas. 

Según el artículo "Hoja de ruta: Reemplazar contraseñas con autenticación OTP" ^{[ 13 ]} sobre autenticación fuerte, publicado por Burton Group (una división de Gartner, Inc. ) en 2010, " la expectativa de Gartner es que el formato de hardware OTP seguirá disfrutando de un crecimiento moderado, mientras que los OTP para teléfonos inteligentes crecerán y se convertirán en la plataforma de hardware predeterminada con el tiempo".

• Iniciativa para la autenticación abierta
• S/KEY
• Algoritmo de contraseña de un solo uso basado en el tiempo (TOTP)

• RFC 4226: HOTP: Un algoritmo de contraseña de un solo uso basado en HMAC
• RFC 6238: TOTP: Algoritmo de contraseña de un solo uso basado en el tiempo
• RFC 6287: OCRA: Algoritmo de desafío-respuesta de OATH
• Iniciativa para la autenticación abierta
• Implementación del algoritmo HOPT de la RFC 4226 ( archivado el 16/12/2021 en Wayback Machine) . Implementación paso a paso en Python en un cuaderno Jupyter.