¿Qué caracteres haría inválidos para una contraseña?

Question

Una situación hipotética: ha implementado un sistema de manejo de contraseñas, y no impone ninguna limitación sobre qué caracteres se pueden usar. Desea configurar algunas reglas que sean un compromiso razonable entre dos cosas:

1. Permita al usuario la mayor libertad posible.
2. Tenga en cuenta la posibilidad de que pueda cambiar la forma en que maneja las contraseñas en el futuro; no desea descartar implementaciones razonables porque las contraseñas existentes de los usuarios se volverían inválidas.

¿Qué reglas impondrías? ¿Hay otros factores que puedan afectar tu elección?

Answer 1

Lo mejor es que no haya restricciones, a menos que realmente pueda justificarlas.

Si usted es un banco, proveedor de correo electrónico o si el usuario puede pedir algo sin proporcionar una tarjeta de crédito, entonces tiene sentido forzar a los usuarios a usar una contraseña segura. De lo contrario, lo estás haciendo difícil sin ningún motivo.

En cuanto a lo que debe almacenar, yo diría que 1024 caracteres de Unicode con caracteres de control prohibidos es todo lo que está justificado. Si el usuario no puede escribirlo, debería haber elegido una contraseña diferente. Todo lo que está almacenando es un hash, por lo que siempre puede cortarlo al tamaño que desee.

Answer 2

Mantendré todo lo que pueda hacer con una tecla (y opcionalmente cambiar) en su teclado, excepto la pestaña. ¿Qué tipo de esquemas necesitarían una opción más restrictiva?

Answer 3

No imponer ninguna restricción alguna vez. Y me parece que está planeando almacenar la contraseña, no el hash. No hagas eso tampoco. Más bien, almacene salt y combinación hash de contraseña y dicha sal.

Sin embargo, puede exigir a sus usuarios una contraseña razonablemente fuerte imponiendo restricciones de longitud (por ejemplo, no menos de 6 caracteres) y caracteres que contengan la contraseña (por ejemplo, debe contener caracteres alfabéticos en letras mayúsculas y minúsculas) , uno o dos dígitos y varios caracteres no alfabéticos como^o #).

Answer 4

Haga que los usuarios escriban contraseñas que contengan al menos un número y un carácter no alfanumérico, y que tengan más de seis caracteres. De todos modos, creo que sean cuales sean las limitaciones, en el caso de que cambie la forma en que valida las contraseñas, debe notificar a los usuarios en un plazo razonable para actualizar la suya.

Answer 5

Cualquier carácter sin control debería estar bien. Creo que los desarrolladores de sistemas de contraseñas súper-duper en el futuro permitirían caracteres ASCII "inusuales" como signos de puntuación y otras marcas, pero los personajes de control tienen el hábito de ser poco manejables para ingresar en shells de modo de texto e incluso en los cuadros de diálogo GUI que esperan Tab y Enter/Return para ser libre para sus propios fines.

Answer 6

Un espacio en blanco (basado en la lógica que puede ser recortado por accidente antes de ser hash)

Answer 7

Las reglas que sugeriría hacer cumplir:

1. Longitud - no menos de 8 caracteres - pero no más de 20
2. Facilidad de ruptura: el pase no debe contener el nombre, apellido o nombre de usuario del usuario, ni (si es posible verificar) ninguna palabra que aparezca en el diccionario inglés.
3. Contenido - Hay 4 tipos de caracteres en el teclado: mayúsculas, minúsculas, números y signos de puntuación. Una buena contraseña debe incluir representantes de al menos 3 grupos y no más de 2 o 3 caracteres del mismo grupo en una fila.

Answer 8

Sin límite de contraseña. Si pueden escribirlo desde su teclado, independientemente del teclado regional que usen. Es posible que desee imponer una longitud mínima, opciones como al menos un número y un carácter especial, pero sin límite máximo.

En relación con su segunda pregunta. La forma en que lo implementaría es creando campos separados a medida que mejora la fortaleza de las contraseñas. Por ejemplo, ahora tendría dos campos relacionados con la contraseña: salt, password_md5. Digamos luego que quieres usar sha256. Crea un nuevo campo llamado password_sha256. Cuando el usuario inicia sesión, primero verifique password_sha256. Si ese campo está vacío, verifique password_md5. Si eso coincide, ahora tiene la contraseña de texto sin formato que ingresó el usuario. A continuación, puede generar la contraseña sha256 (también restablecería la sal para una buena medida) y almacenar el nuevo valor. Luego, borraba el valor en password_md5 para que nadie pudiera revertirlo para obtener la contraseña.

Personalmente, me gustaría ir con el mejor hash que tu lenguaje puede hacer y usar eso. Lo importante es aplicar una buena política de contraseña mínima, no importa cuán seguro es el hash cuando la contraseña es "1234", y sembrar el hash con un carácter aleatorio para evitar ataques de diccionario.

Answer 9

En nuestra organización, si el usuario está proporcionando la contraseña, les permitimos usar lo que quieran.

Cuando los usuarios se inscriben por primera vez en el sistema, se genera una contraseña para ellos. Dado que esta contraseña generalmente se envía por correo a ellos, evitamos el uso de ciertos caracteres que podrían confundirse, especialmente cuando se usan ciertas fuentes. Por ejemplo, la letra O y el número 0 (cero) no se utilizan. Lo mismo para L, I y 1 (uno), S y 5, Z y 2 y otros.

Antes de hacer este cambio, tuvimos un montón de llamadas a nuestra mesa de ayuda porque los personajes que confusos y no podían entrar.

Answer 10

Personalmente, yo uso el teclado de huellas digitales de DigitalPersona (sí, Microsoft [o hizo] hacer un dispositivo similar, ambos integrados o separados del teclado).

Esto permite la generación de contraseñas extremadamente largas y complicadas que no tienen que anotarse (ya que al presionar con el dedo en el lector se ingresa la contraseña al diálogo de inicio de sesión [sistema/aplicación/sitio web]).

Esto, en mi opinión, ofrece lo mejor de ambos mundos: contraseñas extremadamente difíciles de "adivinar", sin tener que recordarlas. También simplifica la recomendación de seguridad adicional de usar diferentes contraseñas en diferentes sistemas.

Bueno, ese es mi valor de dos centavos.

Answer 11

Personalmente siempre he estado interesado en no aplicar demasiadas reglas.

Esto ha cambiado. Acabo de descubrir que mi sitio web es vulnerable a los ataques XSS. La solución es desinfectar cada pieza de entrada que proviene del usuario, incluida la contraseña.

Durante 10 años no hemos tenido límites en la contraseña. Ahora estamos implementando un límite para los caracteres que se pueden usar, y esto es simplemente para evitar que los hackers puedan acceder a Javascript o SQL.Así que construimos la siguiente lista:

Los caracteres válidos para una contraseña son: a-z A-Z 0-9. ps %/(blank)

Esto permite mucha flexibilidad, pero evita los caracteres que pueden usarse para codificar un hack XSS, como; <> \ {} [] + =? &,: ' "`

HTH

Answer 12

algunas reglas a seguir:

1. Caracteres evitar el control no es tan frecuente hoy en día, pero los caracteres de control todos tienen significados especiales y algunos caracteres de control intercepta hardware a. realizar funciones especiales. Algunos causarán problemas con los datos Ejemplo de Control 0 (cero) generaría un nulo
2. ¿Va a imponer restricciones de seguridad? Esta es una pregunta de interfaz de usuario además de un problema de seguridad. necesidad de seguridad. Ma Algunos de los ejemplos dados anteriormente están desactualizados. Las tablas hash para combinaciones de contraseñas se publican con hasta 15 contraseñas de caracteres y las contraseñas de 16 caracteres pueden ser forzadas en minutos si la contraseña es débil o sigue un comportamiento humano típico. Comienza con un capital, termina con un número o carácter especial.
3. Evitaría los caracteres comodín comunes, comillas, dos puntos, punto y coma, etc ... que se usan comúnmente en los lenguajes OS o DB.
4. La autenticación de múltiples factores es un buen camino a seguir. No dependa solamente de la contraseña o no acepte contraseñas.