¿Debo imponer una longitud máxima a las contraseñas?

Una longitud máxima especificada en un campo de contraseña debe leerse como una ADVERTENCIA DE SEGURIDAD : Cualquier usuario sensible, consciente de la seguridad debe asumir lo peor y esperar que este sitio está almacenando su contraseña literalmente (es decir, no hash, como se explica por epochwolf).

En ese caso: (a) evitar el uso de este sitio como la plaga si es posible [obviamente saben tuercas sobre la seguridad] (b) si debe usar el sitio, asegúrese de que su contraseña sea única, a diferencia de cualquier contraseña que use en otro lugar.

Si está desarrollando un sitio que acepta contraseñas, NO ponga un límite de contraseñas tonto, a menos que quiera ser alquitranado con el mismo pincel.

[Internamente, por supuesto, su código puede tratar solo los primeros 256/1028/2k/4k(lo que sea) bytes como "significativos" para evitar crujir en contraseñas gigantescas.]

Permitir una longitud de contraseña completamente ilimitada tiene un inconveniente importante si acepta la contraseña de fuentes no confiables.

El remitente podría intentar darle una contraseña tan larga que resulte en una denegación de servicio para otras personas. Por ejemplo, si la contraseña es de 1 GB de datos y pasas todo el tiempo aceptarla hasta que se quede sin memoria. Ahora supongamos que esta persona le envía esta contraseña tantas veces como usted está dispuesto a aceptar. Si no tienes cuidado con el otro parámetros involucrados esto podría conducir a un ataque DoS.

Establecer el límite superior en algo así como 256 caracteres parece demasiado generoso para los estándares actuales.

En primer lugar, no asuma que los bancos tienen buenos profesionales de seguridad informática que trabajan para ellos. Muchos no .

Dicho esto, la longitud máxima de la contraseña no tiene valor. A menudo requiere que los usuarios creen una nueva contraseña (argumentos sobre el valor de usar contraseñas diferentes en cada sitio aparte por el momento), lo que aumenta la probabilidad de que simplemente las escriban. También aumenta en gran medida la susceptibilidad al ataque, por cualquier vector de fuerza bruta a social ingeniería.

El límite máximo de longitud de contraseña ahora está desaconsejado por la Hoja de trucos de autenticación de OWASP

Https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Citando todo el párrafo:

Las contraseñas más largas proporcionan una mayor combinación de caracteres y, en consecuencia, hacen que sea más difícil para un atacante adivinar.

La longitud mínima de las contraseñas debe ser impuesta por la aplicación. Se consideran contraseñas de menos de 10 caracteres ser débil ([1]). Si bien la aplicación de la longitud mínima puede causar problemas con la memorización de contraseñas entre algunos usuarios, las aplicaciones deben alentarlos a establecer frases de contraseña (oraciones o combinaciones de palabras) que pueden ser mucho más largas que las contraseñas típicas y, sin embargo, mucho más fáciles de recordar.

La longitud máxima de la contraseña no debe ser demasiado baja, ya que evitará que los usuarios creen frases de contraseña. La longitud máxima típica es de 128 caracteres. Las frases de contraseña más cortas que 20 caracteres son generalmente se consideran débiles si solo consisten en caracteres latinos en minúsculas. Cada personaje cuenta!!

Asegúrese de que cada carácter que escriba el usuario esté incluido en la contraseña. Hemos visto sistemas que truncan la contraseña en una longitud más corta que la que el usuario proporcionó(por ejemplo, truncados en 15 caracteres cuando ingresaron 20). Esto generalmente se maneja estableciendo la longitud de TODOS los campos de entrada de contraseña para que sea exactamente la misma longitud que la contraseña de longitud máxima. Esto es particularmente importante si la longitud máxima de la contraseña es corta, como 20-30 caracteres.

Una razón que puedo imaginar para imponer una longitud máxima de contraseña es si el frontend debe interactuar con muchos backends del sistema heredados, uno de los cuales impone una longitud máxima de contraseña.

Otro proceso de pensamiento podría ser que si un usuario se ve obligado a ir con una contraseña corta, es más probable que invente galimatías aleatorias que una frase o apodo fácil de adivinar (por sus amigos/familiares). Por supuesto, este enfoque solo es efectivo si el frontend obliga a mezclar números / letras y rechaza contraseñas que tienen cualquier palabra del diccionario, incluyendo palabras escritas en l33t-speak.

Una razón potencialmente válida para imponer una longitud máxima de contraseña es que el proceso de hash (debido al uso de una función de hash lenta como bcrypt) toma demasiado tiempo; algo que podría ser abusado para ejecutar un ataque DOS contra el servidor.

Por otra parte, los servidores deben configurarse para eliminar automáticamente los controladores de solicitudes que tardan demasiado tiempo. Así que dudo que esto sea un gran problema.

Creo que tienes razón en ambos puntos. Si están almacenando las contraseñas hash, como deberían, entonces la longitud de la contraseña no afecta su esquema de base de datos en absoluto. Tener una longitud de contraseña abierta arroja una variable más que un atacante de fuerza bruta tiene que tener en cuenta.

Es difícil ver cualquier excusa para limitar la longitud de la contraseña, además de un mal diseño.

El único beneficio que puedo ver a una longitud máxima de contraseña sería eliminar el riesgo de un ataque de desbordamiento de búfer causado por una contraseña demasiado larga, pero hay maneras mucho mejores de manejar esa situación.

El almacenamiento es barato, por qué limitar la longitud de la contraseña. Incluso si está cifrando la contraseña en lugar de simplemente hash una cadena de caracteres 64 no va a tomar mucho más que una cadena de caracteres 6 para cifrar.

Lo más probable es que el sistema bancario esté superponiendo un sistema antiguo, por lo que solo pudieron permitir cierta cantidad de espacio para la contraseña.

Mi banco hace esto también. Solía permitir cualquier contraseña, y tenía una de 20 caracteres. Un día lo cambié, y he aquí que me dio un máximo de 8, y había cortado caracteres no alfanuméricos que estaban en mi antigua contraseña. No tenía ningún sentido para mí.

Todos los sistemas de back-end en el banco funcionaban antes cuando estaba usando mi contraseña de 20 caracteres con no alfanuméricos, por lo que el soporte heredado no puede haber sido la razón. E incluso si lo fuera, aún deberían permitirte tener arbitrarios contraseñas, y luego hacer un hash que se ajuste a los requisitos de los sistemas heredados. Mejor aún, deberían arreglar los sistemas heredados.

Una solución de tarjeta inteligente no me iría bien. Ya tengo demasiadas cartas... No necesito otro truco.

Si acepta una contraseña de tamaño arbitrario, entonces se asume que se está truncando a una longitud de cortina por razones de rendimiento antes de que se hash. El problema con el truncamiento es que a medida que el rendimiento de su servidor aumenta con el tiempo, no puede aumentar fácilmente la longitud antes del truncamiento, ya que su hash sería claramente diferente. Por supuesto, podría tener un período de transición donde ambas longitudes se hash y se comprueban, pero esto utiliza más recursos.

Ignora a las personas que dicen no validar contraseñas largas. Owasp literalmente dice que 128 caracteres deberían ser suficientes. Solo para dar suficiente espacio para respirar, puedes dar un poco más, digamos 300, 250, 500 si te apetece.

Https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

Longitud de la contraseña Las contraseñas más largas proporcionan una mayor combinación de personajes y, en consecuencia, hacen que sea más difícil para un atacante adivinar.

...

La longitud máxima de la contraseña no debe establecerse demasiado baja, ya que evitará los usuarios de crear frases de contraseña. La longitud máxima típica es 128 caracteres. Las frases de contraseña más cortas que 20 caracteres son generalmente se consideran débiles si solo consisten en caracteres latinos en minúsculas.

¿Debería haber una longitud máxima? Este es un tema curioso en él, ya que las contraseñas más largas suelen ser más difíciles de recordar y, por lo tanto, es más probable que se escriban (un GRAN no-no por razones obvias). Las contraseñas más largas también tienden a olvidarse más, lo que si bien no es necesariamente un riesgo de seguridad, puede conducir a problemas administrativos, pérdida de productividad, etc. Es probable que los administradores que creen que estos problemas son apremiantes impongan longitudes máximas a las contraseñas.

Yo personalmente creer en este tema específico, a cada usuario su propio. Si usted piensa que puede recordar una contraseña de 40 caracteres,entonces todo el poder para usted!

Dicho esto, sin embargo, las contraseñas se están convirtiendo rápidamente en un modo de seguridad obsoleto, las tarjetas inteligentes y la autenticación de certificados resultan muy difíciles o imposibles de usar por fuerza bruta, ya que es un problema, y solo es necesario almacenar una clave pública en el extremo del servidor con la clave privada en su tarjeta/computadora en todo momento.

Las contraseñas más largas, o frases de paso, son más difíciles de descifrar simplemente en función de la longitud, y más fáciles de recordar que requerir una contraseña compleja.

Probablemente es mejor ir por una longitud mínima bastante larga (10+), restringiendo la longitud inútil.

Los sistemas heredados (ya mencionados) o la interfaz de sistemas externos del proveedor pueden necesitar el límite de 8 caracteres. También podría ser un intento equivocado de salvar a los usuarios de sí mismos. Limitarlo de esa manera resultará en demasiados pssw0rd1, pssw0rd2, etc. contraseñas en el sistema.

Una razón por la que las contraseñas no pueden ser hash es el algoritmo de autenticación utilizado. Por ejemplo, algunos digest algorithms requieren una versión de texto plano de la contraseña en el servidor, ya que el mecanismo de autenticación implica que tanto el cliente como el servidor realicen las mismas matemáticas en la contraseña ingresada (que generalmente no producirá la misma salida cada vez que la contraseña se combine con un 'nonce' generado aleatoriamente, que se comparte entre las dos máquinas).

A menudo esto puede fortalecerse ya que el compendio puede ser computado en parte en algunos casos, pero no siempre. Una mejor ruta es que la contraseña se almacene con cifrado reversible; esto significa que las fuentes de la aplicación deben estar protegidas, ya que contendrán la clave de cifrado.

Digst auth está ahí para permitir la autenticación sobre canales no cifrados. Si utiliza SSL u otro cifrado de canal completo, entonces no hay necesidad de usar mecanismos de autenticación de resumen, lo que significa que las contraseñas se pueden almacenar con hash en su lugar (como contraseñas podrían ser enviados texto plano a través del cable de forma segura (para un valor dado de seguro).

Trate de no imponer ninguna limitación a menos que sea necesario. Tenga cuidado: podría y será necesario en muchos casos diferentes. Tratar con sistemas heredados es una de estas razones. Asegúrese de probar bien el caso de contraseñas muy largas (¿puede su sistema tratar con contraseñas de 10MB de largo?). Puede encontrarse con problemas de Denegación de Servicio (DoS) porque las Funciones de Defivación de claves (KDF) que utilizará (generalmente PBKDF2, bcrypt, scrypt) tardarán mucho tiempo y recursos. Ejemplo de la vida real: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

Las contraseñas de solo 8 caracteres suenan simplemente incorrectas. Si debe haber un límite, entonces al menos 20 char es mejor idea.

Creo que el único límite que se debe aplicar es como un límite de 2000 letras, o algo más increíblemente alto, pero solo para limitar el tamaño de la base de datos si eso es un problema