¿Cuáles son las mejores reglas a seguir para qué personajes permitir una contraseña?

Question

Sin pensarlo en absoluto, solo quiero decir que debería permitir cada personaje. En cualquier caso, se convierte en hash, y no quiero limitar a las personas que desean crear contraseñas seguras.

Sin embargo, al pensarlo más, hay muchos personajes que no tengo idea del efecto que tendrían en las cosas. Caracteres extraños, símbolos ascii, etc. para nombrar un par.

Intenté Google pero no puedo encontrar un estándar definitivo para lo que hace la gente. Incluso la mayoría de las organizaciones profesionales no parecen saber. Parece ser una práctica común para muchos sitios el no permitir caracteres especiales, lo cual es una tontería y no es lo que quiero hacer.

De todos modos, ¿hay alguna recomendación estándar de longitud, caracteres permitidos, etc.?

no estoy seguro si importa, pero me va a utilizar ASP.NET w/C#

Answer 1

Cualquier carácter ASCII imprimible, no en espacio en blanco (entre 33 y 126 inclusive) se permite normalmente en las contraseñas. Muchos profesionales de seguridad (y comentaristas de SO) están aconsejando el uso de un passphrase en lugar de una contraseña, por lo que tendría que permitir espacios. El argumento es que debido a su longitud, y dado que las frases no están en el diccionario, las frases clave son más difíciles de descifrar que las contraseñas. (Una frase de contraseña también puede ser más fácil de recordar, por lo que un usuario legítimo no tiene que mantenerla escrita en una nota adhesiva directamente en su monitor.)

Algunos strong password generators usan un hash, así que pondría un límite muy alto en la longitud (512 o 1024) solo para ser inclusivo. Los generadores de contraseñas de hoy a menudo producen cadenas de 32-128 caracteres, pero quién sabe qué hashes se usarán en los próximos años.

Answer 2

No

un experto, pero no me gusta cuando los personajes que elijan y no extraña que se rechazan. Entonces, creo que estoy de acuerdo con tu instinto.

Answer 3

Los caracteres no ASCII ciertamente dificultan las cosas cuando se trata de ingresar la contraseña en dispositivos limitados (móviles, consolas, etc.), pero por lo general no es imposible. Podría decirse que si el usuario quiere hacer eso, debe dejarlos. Es bastante fácil hacer algo razonable y consistente: codificar en UTF-8 antes de hacer hash, por ejemplo. Solo te meterías en dificultades si algún dispositivo de entrada enviara los personajes como una composición (por ejemplo, e + acento agudo en lugar de "e agudo"), pero sospecho que eso no sucedería en la vida real. (Puede descomponerlo todo usted mismo, pero eso sería un montón de problemas al buscar un caso marginal.)

Lo restringiría a caracteres imprimibles, sin embargo. Poner pestañas, formularios de alimentación, etc. en una contraseña realmente es preguntando por problemas.

Answer 4

Si está hablando de prevenir el tipo de ataque de inyección SQL, probablemente sea una mejor idea asegurarse de que su código haga lo que se supone que debe hacer, en lugar de limitar la entrada para que el problema sea más fácil.

Para los caracteres no ASCII, no lo veo como un problema más difícil si su entrada se puede representar correctamente como una cadena binaria (y no como texto ), que se pasa luego a su función hash o generador de claves, etc.

Answer 5

Fundamentalmente, se debe permitir la mayor parte de la clase de caracteres Unicode. Sin embargo, omita los caracteres de control (por ejemplo, 0-31 además del espacio), la marca de orden de bytes (0xfffe y oxfeff). Además, primero debe canonicalizar la representación para deshacerse de los problemas causados ​​por las diferentes representaciones.Sin embargo, puede emitir advertencias para los personajes que parecen ser demasiado difíciles de ingresar, pero los usuarios evitarán eso.

Answer 6

Respuesta corta: permite tanto como sea compatible con el respaldo del sistema. Hoy en día no hay excusa para no utilizar la compatibilidad total con Unicode para la entrada de texto, y eso incluye contraseñas. No creo que deba preocuparse por los problemas con los personajes, siempre y cuando se manejen literalmente (pero no soy un profesional en este campo, tenga cuidado con la inyección de sql).

Tengo una mascota molesta contra los sitios que imponen restricciones a las contraseñas ... cualquier tipo de restricción. Me gustan los sitios que le dirán cuán sólida es su contraseña y le recomiendo que la fortalezca, pero forzar a un usuario a escribir al menos 8 caracteres, o requerir letras y números, etc. es simplemente frustrante.

Si necesita tener un tamaño de campo máximo (por ejemplo, para almacenar en una base de datos) intente que sea lo suficientemente grande para cualquier cosa que la gente escriba a mano. En realidad, no existe un campo de contraseña demasiado grande, ya que siempre existe la posibilidad de utilizar una contraseña segura automatizada y generada, pero de 64 a 128 caracteres sería suficiente.

Answer 7

Recuerde: Cuando almacene contraseñas, todas las contraseñas se deben cifrar con un algoritmo unidireccional como md5 de sha1. Dado que estos algoritmos siempre producen números hexadecimales, no necesita preocuparse por las inyecciones de SQL ni nada de eso.

Por lo tanto, siempre que pueda md5 o sha1 un carácter, se debe aceptar.

Answer 8

Agregue otro voto para "dejar que el usuario incluya todos los caracteres que su interfaz le permite ingresar". Ni siquiera rechazaría tabular o controlar caracteres. Su software tiene la capacidad de aceptar cadenas de bytes arbitrarias y hash, así que acepte cadenas de bytes arbitrarias como contraseñas. De lo contrario, reduce el espacio que un atacante debe buscar en un ataque de fuerza bruta o de diccionario.

(Por supuesto, incluso si lo hace permitir todo, el 99% de los usuarios todavía utilizará el nombre de su mascota como su contraseña ...)

Answer 9

Con el tiempo puede que tenga que imprimir la contraseña claro en un correo electrónico confirmlation enviado a tus usuarios.

PD: Podría considerar también problemas de codificación en el correo electrónico, si no es ascii estándar (por ejemplo, caracteres japoneses), es posible que un usuario no reciba el correo electrónico en el formato adecuado o simplemente no pueda leerlo en otro sistema debido a que las fuentes no están instaladas.

Todo esto pesa en la gama de caracteres ascii "imprimibles".