¿Los códigos de seguridad 2FA enviados con texto son deliberadamente fáciles de recordar?

También he notado esto, y creo que es el resultado de la tendencia del cerebro humano para aplicar patrones a ruido aleatorio . Esto parece ser más común cuando se trata específicamente de recordar una serie de números.

Aproximadamente el 85% de los números aleatorios de seis dígitos tendrán al menos un dígito que se repite y el 40% tendrá un dígito secuencial de repetición uno al lado del otro. (Estoy feliz de ser corregido en mi matemática).

Estas claves se generan usando el algoritmo TOTP estándar . El artículo resume esta implementación, mostrando que no hay ningún esfuerzo para generar un número memorable:

  

Según RFC 6238, la implementación de referencia es la siguiente:

     

• Genere una clave, K, que es una cadena de bytes arbitraria, y compártala de forma segura con el cliente.
  
• Acuerde un T0, el tiempo de Unix para comenzar a contar los pasos de tiempo, y un intervalo, TI, que se usará para calcular el valor del contador C (los valores predeterminados son la época Unix como T0 y 30 segundos como TI)
  
• Aceptar un método hash criptográfico (el valor predeterminado es SHA-1)
  
• Aceptar una longitud del token, N (el valor predeterminado es 6)
  

Aunque RFC 6238 permite que se utilicen diferentes parámetros, Google   La implementación de la aplicación de autenticación no es compatible con T0, TI   Valores, métodos hash y longitudes de token diferentes de los predeterminados. Eso   también espera que la clave secreta K sea ingresada (o suministrada en un código QR)   en codificación base 32 según RFC 3548.

     

Una vez que se acuerdan los parámetros, la generación de token es la siguiente:

     

1. Calcule C como el número de veces que TI ha transcurrido después de T0.
  
2. Calcule el hash HM con C como mensaje y K como clave (el algoritmo HMAC se define en la sección anterior, pero también la mayoría de las bibliotecas criptográficas lo admiten). K se debe pasar como está, C se debe pasar como un entero sin signo de 64 bits en bruto.
  
3. Tome los menos 4 bits significativos de H y utilícelo como un desplazamiento, O.
  
4. Tome 4 bytes de H a partir de O bytes MSB, descarte el bit más significativo y almacene el resto como un entero (sin signo) de 32 bits, I.
  
5. El token son los N dígitos más bajos de I en la base 10. Si el resultado tiene menos dígitos que N, rellénalo con ceros desde la izquierda.
  

Tanto el servidor como el cliente calculan la   token, entonces el servidor verifica si el token suministrado por el cliente   coincide con el token generado localmente. Algunos servidores permiten códigos que   debería haberse generado antes o después de la hora actual para   para tener en cuenta los sesgos leves del reloj, la latencia de la red y los retrasos del usuario.

En mi teléfono tenía alrededor de 90 códigos de verificación de varias compañías. 62 de estos eran 6 dígitos de largo. Aquí está el recuento de cada dígito:

¿Posiblemente un ligero sesgo hacia 1,8 y 9? Es casi seguro que solo hay ruido en los datos (62 es una pequeña muestra).

¿Qué pasa con los dígitos dobles?

Elprimergráficosolocontienelosdígitosdoblesenloslímitesde2dígitos(esdecir,AABBCC),porloqueesperamosquecadaparaparezcaaproximadamente1.86vecesenlas186ubicacionesdedígitosposibles.Elsegundoescualquierubicación(esdecir,XXX99Xcuentacomoundígitodoble).Esperamosquecadaparalrededorde3.1vecesenlas310ubicaciones.

Parecequenohayningunadesviaciónobviaconmuchosmásdígitosdoblesquelosnodobles:losdígitosdoblessemuestranennaranja.Enlosúltimosdatos,esperaríamosalrededorde31dígitosdobles,yobtendremos27.Esoparecerazonable.

Porsupuesto,estonodescartaotrospatrones"no aleatorios", pero para ser honestos, es probable que los humanos estén buscando patrones. Mire estos números, todos tomados de mi aplicación 2FA: 365 595, 111 216, 566 272, 468 694, 191 574, 833 043.

Espero que esto sea solo una posibilidad aleatoria en tu caso. Si hay un patrón, debilita todo el punto de tener un segundo código.

No, no se supone que sean fáciles de recordar intencionalmente y no hay un caso comercial generalizado para ello a menos que hayan recibido comentarios de que sus usuarios tenían problemas para escribir 6 números. Entonces alguien podría haber hecho algo tonto, pero realmente espero que no.

También tiene que ver con la forma en que los humanos tienden a pensar en la aleatoriedad. En la aleatoriedad real, los dígitos repetidos y los patrones repetidos ocurren con mucha más frecuencia de lo que esperamos. Cuando se les pide a los humanos que creen secuencias de dígitos que "parezcan" al azar, tienden a evitar la repetición de patrones o dígitos (así como otras peculiaridades, como el uso excesivo de "7", y el uso insuficiente de "0" y "2", etc). Si le pide a alguien que elija un número "aleatorio" entre 1 y 100, muy a menudo contendrá un 7, y muy a menudo será 37 (o 17). Puede estudiar los números de lotería que las personas seleccionan manualmente, ya que (a menudo) las personas están tratando de elegir algo de apariencia aleatoria (en la falsa creencia de que los números de apariencia aleatoria son más propensos a ganar en un sorteo al azar).

Si un humano está tratando de emular un sorteo de monedas al azar, se alternarán entre cabezas y colas mucho más de lo que repetirán el último resultado, haciendo posible predecir su próximo valor con bastante buena certeza (> 50% posibilidad de que su próximo valor sea el opuesto a su último).

Una secuencia de dígitos repetidos o de dos dígitos sería bastante común en un número aleatorio verdadero de 6 dígitos (por ejemplo, ~ 41% de un dígito repetido consecutivo, ~ 85% de un dígito repetido en cualquier lugar), y muy poco común en un " número de 6 dígitos al azar que le pides a un humano que proponga.