it-swarm-es.com

¿Qué caracteres no debo permitir en las contraseñas?

Estoy planeando desarrollar un sitio web que requiera que los usuarios registren un nombre de usuario y una contraseña. Cuando dejo que el usuario elija una contraseña, ¿qué caracteres debo permitir que los usuarios tengan en la contraseña? ¿Hay alguno que no deba debido a problemas de seguridad con el protocolo http o el lenguaje de implementación?

Todavía no he decidido un lenguaje de implementación, pero usaré Linux.

20
Jonas

Desde una perspectiva de seguridad/implementación, no debería haber ninguna necesidad de rechazar caracteres aparte de '\ 0' (que de todos modos es difícil de escribir). Cuantos más caracteres barra, menor será el espacio de fase total de las posibles contraseñas y, por lo tanto, más rápido será forzar las contraseñas. Por supuesto, la mayoría de las suposiciones de contraseñas en realidad usan palabras de diccionario en lugar de búsquedas sistemáticas del dominio de entrada ...

Sin embargo, desde una perspectiva sabilidad, algunos caracteres no se escriben de la misma manera en diferentes máquinas. Como ejemplo, tengo dos computadoras diferentes aquí donde shift-3 produce # en una y £ en la otra. Cuando escribo una contraseña, ambas aparecen como '*', así que no sé si lo hice bien o no. Algunas personas piensan que eso podría confundir a las personas lo suficiente como para comenzar a rechazar esos personajes. No creo que valga la pena hacerlo. La mayoría de las personas reales acceden a servicios reales desde una o quizás dos computadoras, y no tienden a poner muchos caracteres extendidos en sus contraseñas.

43
user185

Puede haber problemas con los caracteres no ASCII. Una contraseña es una secuencia de glifos, pero el procesamiento de la contraseña (hashing) necesitará una secuencia de bits, por lo que debe haber una forma determinista de transformar los glifos en bits. Este es todo el pantano turbio de páginas de códigos . Incluso si te apegas a nicode , hay problemas en marcha:

  • Un solo personaje puede tener varias descomposiciones como puntos de código. Por ejemplo, el carácter "é" (que es muy frecuente en francés) puede codificarse como un único punto de código U + 00E9, o como la secuencia U + 0065 U + 0301; ambas secuencias están destinadas a ser equivalentes. Si obtiene uno u otro depende de las convenciones utilizadas por el dispositivo de entrada.

  • Una cadena Unicode es una secuencia de ¡puntos de código (que son enteros en el rango de 0 a 1114110). Hay varias codificaciones estándar para convertir dicha secuencia en bytes; los más comunes serán UTF-8, UTF-16 (big-endian), UTF-16 (little-endian), UTF-32 (big-endian) y UTF-32 (little-endian). Cualquiera de estos puede o no comenzar con un BOM .

Por lo tanto, una sola "é" puede codificarse significativamente en bytes con al menos veinte variantes distintas, y eso es cuando se adhiere a "Unicode convencional". codificación Latin-1 , o su contraparte de Microsoft , también está muy extendido, así que haga que 21. La codificación que utilizará una determinada pieza de software dependerá de muchos factores, incluyendo el locale . Es molesto cuando el usuario ya no puede iniciar sesión en su computadora porque cambió la configuración de "canadiense - inglés" a "canadiense - francés".

Experimentalmente , la mayoría de los problemas de ese tipo se evitan restringiendo las contraseñas al rango de imprimible ASCII caracteres) (aquellos con códigos que van del 32 al 126 - personalmente evitaría el espacio, así que haga que 33 a 126) y aplique la codificación de mono byte (sin BOM, un carácter se convierte en uno byte). Dado que las contraseñas deben escribirse en varios teclados sin retroalimentación visual, la lista de caracteres debería estar aún más restringida para una usabilidad óptima (lucho diariamente con diseños canadienses donde lo que está escrito en el teclado no necesariamente coinciden con lo que la máquina cree que es, especialmente cuando atraviesan uno o dos anidados conexiones RDP ; los caracteres '<', '>' y '\' se mueven con mayor frecuencia). Con solo letras (mayúsculas y minúsculas) y dígitos, estará bien.

Se podría decir que el usuario es responsable; es libre de usar los caracteres que desee siempre y cuando se ocupe del problema de escribirlos. Pero eso no es posible en última instancia: cuando los usuarios tienen problemas, llaman al servicio de asistencia your, y usted debe asumir parte de sus errores.

17
Thomas Pornin

Si está generando contraseñas aleatorias, es una buena idea evitar los caracteres que pueden confundirse con otros. Por ejemplo (ignorando símbolos):

  • Minúsculas: l, o
  • Mayúsculas: I, O
  • Números: 1, 0
11
Justin Morgan

Además de permitir todos los caracteres, considere tener una longitud máxima muy generosa en el campo de contraseña para apoyar a las personas que adoptan el enfoque de frase de contraseña para las contraseñas.

La frase "mi contraseña está en minúsculas" es en realidad una frase de contraseña segura y razonable debido a su longitud.

6
Antony

No debes rechazar ningún personaje. Es posible que desee evitar que las contraseñas tengan menos de 6 caracteres. Y luego deberías sa bcrypt para cambiar la contraseña.

1
Stephen Touset

Hay un par de caracteres que pueden causar problemas:

*,? y%: como estos se usan a menudo como comodines, pueden confundir el lenguaje de programación subyacente.

Tabulador, Retorno, Nueva línea, Tabulador vertical, Escape: Tales caracteres especiales pueden solicitar un comportamiento extraño de su lenguaje de programación OR del navegador utilizado por el cliente. (Si el cliente usa varios navegadores diferentes es es muy posible que uno permita que se ingresen y que otro navegador no. Bloqueando efectivamente al cliente de su cuenta en ese navegador).

\ a menudo se trata como un personaje de escape que le da al personaje un significado especial.
P.ej. "\ n" es nueva línea en muchos casos. "\ t" es la pestaña.
Si su lenguaje de programación (o el navegador del cliente) lo hace, está de regreso a la posibilidad de recibir los caracteres que mencioné anteriormente.
Entonces, probablemente sea mejor deshabilitar\por completo solo para estar seguro.

0
Tonny

Creo que a menos que esté disponible un 'teclado virtual' o una herramienta similar, que produciría caracteres de manera uniforme, solo tenemos caracteres alfanuméricos. La ubicación de todos los demás puede diferir en diferentes teclados. Si un usuario debe acceder al servicio desde otra ubicación, eso podría llevar a bloquearlo de manera eficiente.

Sugeriría usar el teclado virtual como una forma de enviar exactamente las mismas representaciones de caracteres (ya se dijo sobre Unicode arriba) de la misma manera, sin importar qué sistema/teclado/lo que se use. Por lo tanto, no será necesario excluir ningún carácter que pueda escribirse en cualquier palabra clave.

0