¿Qué métodos se pueden usar para evitar nombres de usuario mal escritos?

Los bancos que emiten nombres de usuario numéricos son bastante molestos. Y aunque soy más paranoico que la mayoría, es probable que tengas razón porque alguien simplemente identificó su identificación y no se dio cuenta hasta que te cerraron.

Para responder a la pregunta, algunos bancos lo ayudan a asegurarse de que está intentando iniciar sesión con la cuenta de usuario correcta. Esas "Imágenes de seguridad" que ve en algunas páginas de inicio de sesión de bancos, sí, los bancos le dicen que esas imágenes le ayudan a asegurarse de que está ingresando a su sitio web. Pero el beneficio real es ayudar a los usuarios a darse cuenta de que están intentando iniciar sesión en la cuenta de otra persona. Los sitios que utilizan este proceso le pedirán su nombre de usuario en la página de inicio de sesión principal, y luego lo llevarán a una nueva página con su 'imagen de seguridad' y el campo de contraseña. También pueden solicitar otra forma de autenticación (pregunta de seguridad, etc.) antes de solicitar la contraseña si está iniciando sesión desde una computadora en la que no lo ha visto antes.

Si cada vez que inicia sesión, ve la imagen que seleccionó al registrarse, es más probable (suponiendo que use el sitio con suficiente frecuencia) para darse cuenta de cuándo esa imagen es diferente. Esto podría significar que estás iniciando sesión en un sitio de phishing, pero lo más probable es que hayas perdido la cuenta de usuario.

EDITAR: - Para responder a su edición -

Cuando se trata de ID de usuarios numéricos, solo hay 10 dígitos y están agrupados en un área muy pequeña en 10 teclas y dispositivos móviles. Dadas muchas decenas (o cientos) de miles de usuarios, la escasez de dígitos y lo cerca que están en dos de los tres diseños comunes, realmente no hay manera de garantizar adecuadamente que cualquier ID sea lo suficientemente diferente de otra para evitar errores comunes de escritura errónea .

Además, si lo piensa desde un punto de vista de rendimiento, detectar si una nueva ID es uniq es un proceso muy eficiente y rápido en la mayoría de los sistemas bien diseñados. Sin embargo, detectar si un nuevo ID es diferente de otros requeriría iterar sobre todos los demás ID de usuario y comparar los dos con el algoritmo que sea. Esto sería un proceso (relativamente) lento y doloroso. Con el tiempo y el esfuerzo suficientes, podría almacenar en memoria caché ngrams y cualquier otro punto de comparación para acelerarlo, pero aún así, será lento.

En resumen, no conozco a ninguna empresa que haga esto en las identificaciones de usuario, ciertamente no en las numéricas. (Pero felizmente leí un artículo técnico o un blog de ingeniería sobre alguien que lo está haciendo)

Un par de otros usuarios (incluido Philipp) han mencionado los dígitos de la suma de comprobación, que no comenté ya que inicialmente me centré en el lado del sistema y en el enfoque de los nombres de usuario diferentes de la pregunta. Pero en el pensamiento adicional tiene un lugar en esta conversación. Las sumas de verificación se utilizan a menudo para aumentar los números de cuenta, es decir, los números de tarjeta de crédito, para los cuales cualquier estudiante de programación del primer semestre puede escribir una herramienta de validación. Todo esto elimina la escritura errónea y puede verificarse del lado del cliente sin publicar en el formulario de inscripción. Es imposible decir (sin conocimiento interno) si alguien está usando esto en cuentas de usuario numéricas ... Me atrevería a decir que alguien es, pero no lo he visto y, como no lo haría, Discusión interesante (o documentación) dentro de la comunidad, no he oído hablar de nadie que lo haga. Creo que todos podemos estar de acuerdo, su banco no lo está. :)

Puede generar el código de acceso si toma un número consecutivo y le agrega uno o más dígitos adicionales, que son una suma de comprobación del número real. Puede verificar la validez de un código de acceso en el lado del cliente verificando si los dígitos de suma de verificación ingresados por el usuario coinciden con la parte real del código de acceso.

Un dígito de control reduce la posibilidad de ingresar accidentalmente un código de acceso válido de otro usuario a uno de cada diez, de dos a uno en ciento y de tres a uno en miles.

La desventaja, sin embargo, es que cuanto más larga es la contraseña, más difícil es memorizarla, lo que a su vez hará que las personas olviden sus códigos de acceso y nuevamente consuman recursos humanos para recuperarlos. Eso significa que el diseñador del sistema debe encontrar el equilibrio adecuado entre los inconvenientes generados por las personas que ingresan los códigos de acceso de otras personas y las personas que olvidan sus códigos de acceso.

Evitaron un ataque en tu cuenta. Este es un resultado deseado: si hubieran podido probar contraseñas ilimitadas, habrían adivinado las suyas. El ataque se detuvo a tiempo, lo que le costó un inconveniente menor. Si este patrón se repitió para incomodarlo seriamente, el banco puede simplemente emitirle un nuevo código de acceso aleatorio.

No están tan interesados en evitar inconvenientes económicos como en prevenir costosos fraudes.

EDITAR:

El problema con un número de 8 dígitos asignado aleatoriamente es que probablemente no lo recordará si no tiene que usarlo regularmente. ¿Cómo recuerdas si tu número es 82640927 o 82604927?

Algo que se ha usado durante mucho tiempo para reducir los errores tipográficos es el algoritmo de verificación de dígitos de Luhn. Validará el número y le pedirá al sistema que solicite a un usuario que vuelva a ingresar el número si algún dígito es incorrecto o si un par de dígitos se transpone accidentalmente. Las tarjetas de crédito han utilizado esto durante décadas. Pero el algoritmo de Luhn no evitará todos los problemas accidentales, ni detendrá los intentos deliberados.

La mejor manera de reducir las colisiones accidentales es aumentar el espacio numérico potencial y asignar usuarios al azar a través del espacio numérico. El simple hecho de tener números de 10 dígitos no detiene las colisiones si los usuarios están numerados 0000000001, 0000000002, 0000000003, ... Una forma de lograr esto es usar una semilla secuencial, y luego ingresarla en un algoritmo hash para producir el número de 10 dígitos ( Tomar un int sin firmar de los cuatro bytes inferiores es una forma de lograrlo. Es lo suficientemente aleatorio como para que dos números no tengan una relación entre sí, lo que hace que los errores tipográficos accidentales sean realmente pocos y distantes entre sí. Un dígito Luhn también puede servir como un cheque de cortesía para ayudar al usuario a no perder el tiempo ingresando una contraseña en un número de cuenta obviamente defectuoso.

Los servicios web pueden tener en cuenta la ubicación de donde se originan las solicitudes de inicio de sesión y se correlacionan con sus intentos de inicio de sesión anteriores. Similar a cómo las compañías de tarjetas de crédito se comunicarán con usted cuando noten "actividad inusual" en su tarjeta de crédito. Esta es una pieza de lógica que una organización que proporciona un servicio en la web puede usar para tratar incidentes como este. Si pueden decir con una alta confianza que el nombre de usuario asociado con la conexión no es usted, pueden tomar medidas para aislar esos eventos y afectar la cuenta real.

En su caso, el banco podría tener la lógica programada o el analista deducir si el individuo que intenta iniciar sesión con su ID de cuenta era de la misma área que usted, o si está seguro de que era un área geográfica completamente diferente.

Otra ruta que les ayudaría a darles una imagen serían los registros disponibles del evento. Parece que el representante de servicio al cliente que habló no tuvo acceso a dichos registros, y probablemente no habría tenido la experiencia para verlos. Incluso si lo hicieran, ¿de quién diría que la aplicación registra verbalmente esa información? ¿Incluso lo querrían? ¿Cuántas personas tendrían acceso a esa información?

La lógica avanzada en estas situaciones puede complicarse rápidamente. La forma en que se manejó su banco en este caso parece ser la respuesta más directa y menos costosa para todos los involucrados. Si la única interrupción para usted en el servicio fue una llamada telefónica de 5 minutos con su banco, es una forma de impacto muy bajo para hacer frente a una situación de daño potencial.

Hay una ventaja clave para un nombre de usuario o contraseña asignados: por lo general, es más aleatorio de lo que un usuario generaría. Para un nombre de usuario de solo 8 caracteres numéricos, hay 100 millones (10 ^ 8) de permutaciones posibles. Esto es menos de 1/3 de la población de los Estados Unidos y alrededor de la mitad de la población de Indonesia. Por lo tanto, este método ciertamente no se escalaría más allá de esa cantidad de usuarios de banca en línea.

Sí, esto significa que los nombres de usuario son fáciles de adivinar: un atacante solo tiene que iterar a través de números de 8 dígitos. Por supuesto, uno tendría que ser muy afortunado de forzar de este modo a una cuenta de alto patrimonio neto de esta manera.

Sin embargo, según su experiencia, la misma actividad se puede usar fácilmente para realizar un ataque de denegación de servicio. Simplemente adivine aleatoriamente la contraseña N veces por nombre de usuario en una sucesión rápida (donde N es el número de intentos necesarios para activar un bloqueo de cuenta). En unas pocas horas, el banco tendrá que verificar por teléfono a cada cliente de banca en línea, y su centro de llamadas se verá abrumado.

La solución es expandir el conjunto de caracteres del nombre de usuario. Al permitir letras sensibles a mayúsculas y minúsculas, el número de permutaciones se expande a 218 billones ((26 + 26 + 10) ^ 8), lo que reduce en gran medida la efectividad del ataque anterior de denegación de servicio, así como las colisiones accidentales como la que usted hace. experimentado.

El inconveniente es que los nombres de usuario se vuelven más complejos para que los usuarios los recuerden y los ingresen. Esto se puede mitigar parcialmente permitiendo a los usuarios elegir nombres de usuarios. Y la desventaja de que es una pérdida de aleatoriedad.

Una cosa que algunos sitios web, como Google, parecen estar haciendo para prevenir este tipo de ataque es, después de una cierta cantidad de intentos de inicio de sesión, no bloquearlo, sino darle algo llamado CAPTCHA. Esto se usa más para evitar inicios de sesión de bots, pero también ralentiza a un usuario humano malintencionado, ya que todavía tiene que averiguar la contraseña, y algunos CAPTCHA son difíciles. También podría incomodar a un usuario legítimo, pero cuando obtenga un CAPTCHA en estos sitios, es probable que no recuerde su contraseña.

Otra cosa que algunos sitios parecen estar haciendo es bloquear un nombre de usuario temporalmente, no permanentemente. Por ejemplo, el sitio de mi universidad de 2 años lo bloqueó durante 15 minutos cuando ingresó la contraseña incorrecta 3 veces, luego 5 minutos adicionales y acumulativos por cada nuevo intento de contraseña antes de que finalice el bloqueo. Los bloqueos de pantalla de muchos teléfonos Android también hacen esto. Este método podría permitir ataques de DOS, ya que el usuario malintencionado podría intentar tantos intentos que el verdadero usuario nunca podría iniciar sesión nuevamente, aunque vincular el límite de tiempo a direcciones IP específicas, cookies, etc. podría mitigar esto, teniendo en cuenta que Las IPs pueden ser falsificadas.

Ambos métodos funcionan más para disuadir a los robots que los usuarios humanos maliciosos, pero ralentizan a los usuarios humanos, mientras que no bloquean permanentemente la cuenta del usuario legítimo en caso de accidentes. No estoy seguro de qué tan bien funcionaría cada método para los bancos, ya que son mucho más paranoicos que, por ejemplo, Google. Además, la mayoría de los sitios los he visto en nombres de usuario usados especificados por el usuario, pero asumo que también funcionarán para nombres de usuario numéricos especificados por el banco.