Cuando utiliza la autenticación de 2 pasos para iniciar sesión en su cuenta de Google, puede recibir un SMS en su teléfono móvil con un código de estilo G- 123456 .
Creo que nunca obtuve un código con un cero inicial. ¿Hay alguna razón para esto o es simplemente una ocurrencia improbable en el ámbito de la aleatoriedad?
Esta es una opción de implementación clásica para ayudar a reducir los errores de entrada de datos.
Las personas que están en ciencias de la computación o seguridad de la información entienden la diferencia entre una cadena de texto y una serie de dígitos que representa un valor. Pero a las personas que han recibido capacitación en finanzas, contabilidad y otros campos se les ha enseñado a truncar los ceros iniciales cuando se trata de números. Es más probable que vean una fila de dígitos como un "número que tiene un valor". Por ejemplo, si ven "000001", su cerebro interpreta esto como el valor "uno". Cuando llega el momento de ingresar el código, recuerdan el valor "uno" y escriben reflexivamente "1". Numéricamente es un valor equivalente, pero como una cadena de texto no es una coincidencia exacta.
El diseñador del sistema tiene varias opciones para lidiar con esto.
Pueden generar códigos con ceros iniciales y permitir que los pocos usuarios cometan errores ocasionales, obligándolos a volver a ingresarlos. Eso puede dar a la aplicación una reputación que es difícil de usar.
Pueden cambiar el sistema de entrada para que coincida con coincidencias de texto o con valores numéricos. Esto aumenta la complejidad de la lógica de entrada del usuario en un área de seguridad crítica del código. El historial de fallas de seguridad es una lista de evidencia que muestra que los incrementos en la complejidad en el procesamiento de las opiniones de los usuarios aumentan el riesgo de errores de codificación que conducen a vulnerabilidades.
Pueden generar el código a partir de un conjunto restringido de números que nunca se arriesgan a causar confusión en el usuario. Esto reduce el número posible de combinaciones válidas en aproximadamente un 10%, que el diseñador del sistema debe tener en cuenta al calcular la viabilidad de un ataque de fuerza bruta o de adivinación aleatoria. Y al cambiar la complejidad a la sección de generación del código y alejarse de la sección de entrada del usuario, es menos probable que los errores de programación creen vulnerabilidades.
En última instancia, es un problema de factores humanos para una pequeña fracción de la población. Pero los sistemas de seguridad ya son complejos, consumen mucho tiempo y son frustrantes, por lo que cualquier problema de uso que aumente la frustración del usuario es realmente malo para mantenerlo intencionalmente en un sistema de seguridad (especialmente uno que intenta comercializar comercialmente).
Los lectores de SMS de teléfono tienen la tendencia de interpretar elementos de texto para facilitar la navegación del usuario. Esto incluye los números de teléfono para un marcado rápido, o agregar / guardar para contactar.
Por lo tanto, es muy probable que el uso de un patrón G-[1-9][0-9]{5} sea una manera de evitar ese comportamiento común para que no evite otras acciones como copiar o desencadenar acciones inapropiadas como llamar o guardar para contactar.
Sospecho que el algoritmo se basa estrechamente en el que usan para Google Authenticator, TOTP (si no es el mismo dado el contexto de uso similar) y el algoritmo utilizado por este fue diseñado para garantizar que el resultado siempre fue de 6 dígitos, basado en varios cálculos mucho más grandes. No sé lo suficiente sobre el proceso HMAC real para decir con seguridad que un 0 no podría terminar en la salida pero aparentemente es poco probable. Aquí hay un desglose bastante detallado: enlace
Lea otras preguntas en las etiquetas entropy multi-factor sms