¿Cómo evitar coincidencias de nombre de usuario y contraseña al cambiar un nombre de usuario?

La única forma sensata de obtener lo que desea es solicitar la contraseña cuando un usuario cambia su nombre de usuario. De esta manera, el servidor siempre tiene la información necesaria para realizar una comparación precisa entre el nombre de usuario y la contraseña durante un cambio y evitar coincidencias.

Como las operaciones confidenciales, como cambiar las contraseñas o los nombres de usuario de su caso, deben requerir una contraseña de todos modos (para limitar el daño de XSS), esto no debería ser un problema.

Tu única otra alternativa es probar todas las combinaciones de casos posibles, hacer hash y compararlas con el hash almacenado cuando un usuario cambia su nombre de usuario.

Ir un poco en contra del grano: a no le importa si el nombre de usuario se cambia a una cadena "sustancialmente similar" como la contraseña. Advierta a los usuarios sobre el peligro de seleccionar la misma contraseña y compruebe la coincidencia idéntica .

No importa cuántas reglas establezca, si el usuario está determinado, encontrará una manera de evitarlo. Si tiene que hacerlo, solicite la contraseña al cambiar el nombre de usuario para poder forzarlos a la misma caja, o simplemente déjelo pasar y verifique la próxima vez que inicien sesión y luego hagan un cambio de usuario / aprobación.

El tiempo solo en cualquiera de estos asuntos es si sus usuarios están sujetos a un ataque dirigido. Si un script aleatorio para niños (o algún otro oportunista) se hace con la lista de usuarios, tiene herramientas más sofisticadas para romper esas contraseñas que tratar de hacer coincidir el nombre de usuario. Lo mismo ocurre con el atacante objetivo, pero pueden comenzar con cosas simples que pueden escribir ellos mismos en el teclado. Y si se trata de una persona inteligente que intenta romper la contraseña "PwdRsch1", ¿realmente va a estar seguro solo al revisar las diferencias de casos? ¿Qué hay de "pwdr5ch1"? "PwdRsch2"? "1hcsRdwP"? Puede escribir reglas para cualquiera de estos escenarios que se le ocurran, pero o habrá uno que olvidó o hará que sea tan difícil seleccionar un combo de nombre de usuario / contraseña que simplemente terminarán usando "P4ssw0rd!" y acabar de una vez.

La educación es la forma única de hacer que sus usuarios usen contraseñas realmente seguras, y siempre habrá aquellas que no cumplan.

Digamos que el nombre de usuario tiene 10 letras. Eso es 1024 combinaciones diferentes de mayúsculas y minúsculas. Revísalos todos.

No almacene el hash de contraseña en minúscula. Ese 1024 puede parecerle inconveniente, pero es la diferencia entre un día y tres años para un atacante.

Debes hacer que los ID de usuario y las contraseñas provengan de diferentes conjuntos. En los comentarios, parece que el ID de usuario debe seguir el nombre legal del usuario de forma formulada "John Smith" - > "jsmith" y "Jane Doe" - > "jdoe". Luego, si Jane se casa con John y toma su nombre, entonces su identificación de usuario debe cambiar a algo como "jsmith2"

Por lo tanto, podría estipular que el primer carácter de una contraseña debe ser un símbolo o que la contraseña debe contener un símbolo.

Si los ID de usuario se truncan en 8 caracteres, es posible que necesite que las contraseñas contengan al menos 9 caracteres.

Usted podría tomar el producto cartesiano de los apellidos de una lista y una lista de nombres de pila y utilizarlo como una lista negra para las contraseñas. Si un empleado tiene un nombre que no estaba en su lista, agréguelo y, a medida que las personas cambien las contraseñas, el problema se solucionará solo.

Esto no es una respuesta, solo lo menciono para que las personas no hagan esto .

Puede decidir que tendría sentido almacenar, además del hash regular de su contraseña que distingue entre mayúsculas y minúsculas, un hash de su contraseña convertida en minúsculas.

Esto sin duda resolvería su problema: simplemente escribe en minúsculas el nombre de usuario al que estás cambiando y lo comparas con este hash almacenado de la contraseña en minúsculas.

El inconveniente obvio es que esto en parte anula el propósito de una contraseña hash en primer lugar: hacer que los ataques a su lista de contraseñas sean mucho más difíciles. Un atacante que obtenga acceso a sus listas de contraseñas con hash podría atacar al hash minúsculo mucho más débil (2 ^ n veces más débil) en lugar del hash que distingue entre mayúsculas y minúsculas.

Entonces, las otras opciones mencionadas (pedir la contraseña en el momento del cambio; probar todas las permutaciones del caso si un administrador la cambia, idealmente en el orden más probable primero) parecen apuestas mucho mejores.

Ya hay algunas respuestas geniales, pero aquí hay una forma alternativa de abordar este problema. En lugar de intentar comparar el nuevo nombre de usuario con la contraseña existente, simplemente podría forzar un cambio de contraseña cada vez que un usuario cambie su nombre de usuario.

Naturalmente, querrá advertir a los usuarios que cambiar el nombre de usuario requerirá cambiar la contraseña, pero luego puede usar fácilmente cualquier proceso que ya exista para verificar las nuevas contraseñas con los nombres de usuario.

Si bien la solución más sensata ya se ha mencionado y aceptado, es decir, solicitar la contraseña para cambiar el nombre de usuario, ya que debería hacerlo de todos modos. Una alternativa es también almacenar el hash de la contraseña en minúscula (¿con un salt diferente?) Y comparar el nombre de usuario en minúsculas con eso.

La única forma de evitar que los usuarios elijan contraseñas tontas es forzando las políticas de generación de contraseñas (a diferencia de las políticas de formato contraseña ).

Ahora, si no tiene tanta autoridad sobre sus usuarios (la mayoría de los sitios web no la tienen), al menos debe decirles que generen sus contraseñas con un administrador de contraseñas (y que generen su contraseña maestra con dice ), y podría dificultar la desobediencia a esta política:

Una forma en que podría hacer esto es haciendo que el campo de su contraseña no acepte la entrada del teclado, sino que solo pegue los datos o los datos escritos a máquina (recomiendo verificar la velocidad a la que se ingresan los caracteres). Luego, puede hacer que el recuadro que explica la política de contraseña se resuma en rojo o algo para llamar su atención.