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 tengan los usuarios en la contraseña? ¿hay alguna 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.
Desde una perspectiva de seguridad / implementación, no debería ser necesario rechazar caracteres aparte de '\ 0' (lo cual es difícil de escribir de todos modos). Cuantos más caracteres barre, menor será el espacio de fase total de las contraseñas posibles y, por lo tanto, más rápido será el de las contraseñas de fuerza bruta. Por supuesto, la mayoría de las averiguaciones de contraseñas en realidad usan palabras del diccionario en lugar de búsquedas sistemáticas del dominio de entrada ...
Desde una perspectiva de usabilidad , sin embargo, 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 '*', por lo que no sé si lo hice bien o no. Algunas personas piensan que eso podría confundir a la gente lo suficiente como para comenzar a rechazar a 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.
Puede haber problemas con los caracteres que no son 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 mantienes en Unicode , hay problemas en curso:
Un solo carácter 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 tal 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 una BOM .
Por lo tanto, una sola "é" se puede codificar de manera significativa en bytes con al menos veinte variantes distintas, y eso es cuando se adhiere a "Unicode convencional". codificación Latin-1 , o su homólogo de Microsoft , también está muy extendido, así que haga que 21. La codificación que utilice una determinada pieza de software pueda depender de muchos factores, entre ellos el locale . Es molesto cuando el usuario ya no puede iniciar sesión en su computadora porque cambió la configuración de "Canadian - English" a "Canadian - French".
Experimentalmente , la mayoría de los problemas de ese tipo se evitan restringiendo las contraseñas al rango de ASCII imprimible 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 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 ser aún más restringida para una usabilidad óptima (lucho diariamente con diseños canadienses donde lo que está escrito en el teclado no coincide necesariamente con lo que la máquina cree que es, especialmente cuando se pasa por 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ás bien.
Se podría decir que el usuario es responsable; es libre de usar los caracteres que desee siempre que se ocupe del problema de escribirlos. Pero eso no es en última instancia sostenible: cuando los usuarios tienen problemas, llaman a su servicio de asistencia, y usted tiene que asumir parte de sus errores.
Si está generando contraseñas aleatorias, es una buena idea evitar los caracteres que pueden confundirse con otros. Por ejemplo (ignorando los símbolos):
l, o
I, O
1, 0
Además de permitir que todos los caracteres, considere tener una longitud máxima muy generosa en el campo de la contraseña para ayudar a las personas que toman el enfoque de contraseña a las contraseñas.
La frase "mi contraseña está toda en minúscula" es en realidad una frase de contraseña sólida y razonable debido a su longitud.
No debes rechazar ningún carácter. Usted puede desear evitar que las contraseñas tengan menos de 6 caracteres. Y luego debes usar bcrypt para copiar la contraseña.
Creo que a menos que esté disponible un 'teclado virtual' o una herramienta similar, que produzca 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 llevarlo a bloquearlo de manera eficiente fuera de servicio.
Yo sugeriría usar el teclado virtual como una forma de enviar exactamente las mismas representaciones de caracteres (como se dijo anteriormente sobre Unicode) 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 ninguna palabra clave.
Hay un par de caracteres que pueden causar problemas:
*,? y%: como a menudo se utilizan como comodines, pueden confundir el lenguaje de programación subyacente.
Tab, Return, NewLine, Vertical Tab, Escape: Tales caracteres especiales pueden solicitar un comportamiento extraño desde su lenguaje de programación O desde el navegador utilizado por el cliente. (Si el cliente usa varios navegadores diferentes, es muy posible que uno permita que se ingresen y otro que no. El bloqueo efectivo del cliente de su cuenta en ese navegador).
\ a menudo se trata como un personaje de escape que le da al personaje que sigue un significado especial.
P.ej. "\ n" es nueva línea en muchos casos. "\ t" es una pestaña.
Si su lenguaje de programación (o el navegador de los clientes) hace esto, está de nuevo en la posibilidad de recibir los caracteres que mencioné anteriormente.
Por lo tanto, es probable que sea mejor deshabilitar todo para estar seguro.
Lea otras preguntas en las etiquetas web-application passwords password-policy