security - tener - ejemplo de 8 caracteres alfanumericos
¿Debo imponer una longitud máxima en las contraseñas? (19)
Puedo entender que imponer una longitud mínima a las contraseñas tiene mucho sentido (para salvar a los usuarios de sí mismos), pero mi banco exige que las contraseñas tengan entre 6 y 8 caracteres, y empecé a preguntarme ...
- ¿No sería esto más fácil para los ataques de fuerza bruta? (Malo)
- ¿Esto implica que mi contraseña se almacena sin cifrar? (Malo)
Si alguien con (con suerte) algunos buenos profesionales de seguridad de TI que trabajan para ellos están imponiendo una longitud máxima de contraseña, ¿debería pensar en hacer algo similar? ¿Cuáles son los pros / contras de esto?
¿Debería haber una longitud máxima? Este es un tema curioso en TI en el que las contraseñas largas suelen ser más difíciles de recordar y, por lo tanto, es más probable que se anoten (un GRAN no por razones obvias). Las contraseñas más largas también tienden a olvidarse más, lo que a pesar de no ser necesariamente un riesgo para la seguridad, puede generar problemas administrativos, pérdida de productividad, etc. Los administradores que creen que estos problemas son apremiantes probablemente impongan longitudes máximas en las contraseñas.
Personalmente creo en este tema específico, para cada usuario. Si cree que puede recordar una contraseña de 40 caracteres, ¡entonces tendrá más poder para usted!
Sin embargo, las contraseñas se están convirtiendo rápidamente en un modo de seguridad desactualizado, las tarjetas inteligentes y la autenticación de certificados resultan muy difíciles o imposibles para la fuerza bruta, como dijiste es un problema, y solo una clave pública debe almacenarse en el extremo del servidor con el clave en su tarjeta / computadora en todo momento.
Creo que el único límite que se debe aplicar es como un límite de 2000 letras, o cualquier otra cosa increíblemente alta, pero solo para limitar el tamaño de la base de datos si eso es un problema
Creo que tienes mucha 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 DB en absoluto. Tener una longitud de contraseña abierta permite una variable más que un atacante de fuerza bruta debe tener en cuenta.
Es difícil ver cualquier excusa para limitar la longitud de la contraseña, además del mal diseño.
El único beneficio que puedo ver con una longitud máxima de contraseña sería eliminar el riesgo de un ataque de desbordamiento del búfer causado por una contraseña demasiado larga, pero hay formas mucho mejores de manejar esa situación.
El almacenamiento es barato, ¿por qué limitar la longitud de la contraseña? Incluso si está encriptando la contraseña en lugar de simplemente hash, una cadena de 64 caracteres no va a tomar mucho más que una cadena de 6 caracteres para encriptar.
Lo más probable es que el sistema bancario esté superponiendo un sistema anterior, por lo que solo pudieron permitir una cierta cantidad de espacio para la contraseña.
El límite máximo de longitud de la contraseña ahora se desaconseja mediante la Hoja de referencia 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 de adivinar para un atacante.
La aplicación debe aplicar la longitud mínima de las contraseñas. Las contraseñas de menos de 10 caracteres se consideran débiles ([1]). Si bien la aplicación mínima de longitud puede causar problemas con la memorización de contraseñas entre algunos usuarios, las aplicaciones deben alentarlos a establecer frases clave (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 establecerse demasiado baja, ya que evitará que los usuarios creen contraseñas. La longitud máxima típica es de 128 caracteres. Las frases de contraseña de menos de 20 caracteres generalmente se consideran débiles si solo constan de caracteres latinos en minúsculas. ¡¡Cada personaje cuenta !!
Asegúrese de que cada carácter que escriba el usuario esté realmente incluido en la contraseña. Hemos visto sistemas que truncan la contraseña en una longitud más corta que la proporcionada por el usuario (por ejemplo, truncado en 15 caracteres cuando ingresaron 20). Esto generalmente se maneja estableciendo la longitud de TODOS los campos de entrada de contraseña para que tengan exactamente la misma longitud que la contraseña de longitud máxima. Esto es particularmente importante si su longitud máxima de contraseña es corta, como 20-30 caracteres.
Intente no imponer ninguna limitación a menos que sea necesario. Tenga cuidado: puede 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 (¿su sistema puede manejar contraseñas largas de 10 MB?). Puede encontrarse con problemas de denegación de servicio (DoS) porque las funciones de definición de claves (KDF) que va a utilizar (normalmente PBKDF2, bcrypt, scrypt) le llevará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 más largas, o frases de paso, son más difíciles de descifrar, simplemente se basan en la longitud y son más fáciles de recordar que las que requieren una contraseña compleja.
Probablemente sea mejor ir por una longitud mínima bastante larga (10+), lo que restringe la longitud inútil.
Las contraseñas son hashed a 32, 40, 128, cualquiera que sea la longitud. La única razón para una longitud mínima es evitar contraseñas fáciles de adivinar. No hay propósito para una longitud máxima.
El XKCD obligatorio que explica por qué le está haciendo un flaco servicio a su usuario si le impone una longitud máxima:
Los sistemas heredados (mencionados anteriormente) o la interfaz de sistemas de proveedores externos pueden necesitar el límite de 8 caracteres. También podría ser un intento equivocado de salvar a los usuarios de ellos mismos. Limitarlo de esa manera resultará en demasiadas contraseñas pssw0rd1, pssw0rd2, etc. en el sistema.
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í, me dio un máximo de 8 y había recortado caracteres no alfanuméricos que estaban en mi contraseña anterior. No tenía ningún sentido para mí.
Todos los sistemas de back-end en el banco funcionaban antes cuando usaba mi contraseña de 20 caracteres con no alfanuméricos, por lo que el soporte heredado no puede haber sido el motivo. E incluso si lo fuera, aún deberían permitirte tener contraseñas arbitrarias 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 como están ... No necesito otro truco.
Permitir una longitud de contraseña completamente ilimitada tiene un inconveniente importante si acepta la contraseña de fuentes que no son de confianza.
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 pasa todo el tiempo, acéptela hasta que se quede sin memoria. Ahora suponga que esta persona le envía esta contraseña tantas veces como esté dispuesto a aceptar. Si no tiene cuidado con los otros parámetros involucrados, esto podría conducir a un ataque DoS.
Establecer el límite superior a algo así como 256 caracteres parece demasiado generoso para los estándares actuales.
Primero, no asuma que los bancos tienen buenos profesionales de seguridad de TI trabajando para ellos. Mucho 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 por el valor de usar diferentes contraseñas en cada sitio aparte por el momento), lo que aumenta la probabilidad de que simplemente los escriban. También aumenta enormemente la susceptibilidad al ataque, por cualquier vector de la fuerza bruta a la ingeniería social.
Si acepta una contraseña de tamaño arbitrario, entonces se supone que se está truncando a una longitud de cortina por razones de rendimiento antes de que sea 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 en el que ambas longitudes estén codificadas y controladas, pero esto utiliza más recursos.
Solo 8 contraseñas de larga duración suenan simplemente incorrectas. Si debe haber un límite, entonces al menos 20 caracteres es una mejor idea.
Una longitud máxima especificada en un campo de contraseña debe leerse como una ADVERTENCIA DE SEGURIDAD : Cualquier usuario sensato y consciente de la seguridad debe suponer lo peor y esperar que este sitio almacene su contraseña literalmente (es decir, no hash, según lo explica epochwolf).
En ese caso: (a) evite usar este sitio como la peste si es posible [ellos obviamente saben lo que es 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 otra parte .
Si está desarrollando un sitio que acepte contraseñas, NO ponga un límite de contraseña tonta, a menos que desee ser marcado con el mismo pincel.
[Internamente, por supuesto, su código puede tratar solo los primeros bytes 256/1028 / 2k / 4k (lo que sea) como "significativos" para evitar el crujido de las contraseñas de mamut.]
Una razón potencialmente válida para imponer una longitud de contraseña máxima es que el proceso de hash (debido al uso de una función de hash lento como bcrypt) ocupa demasiado tiempo; algo que podría abusarse para ejecutar un ataque DOS contra el servidor.
Por otra parte, los servidores deben configurarse para soltar automáticamente los manejadores de solicitudes que toman demasiado tiempo. Entonces dudo que esto sea un gran problema.
Una razón que me puedo imaginar para aplicar una longitud máxima de contraseña es si la interfaz debe interactuar con muchos backends heredados del sistema, uno de los cuales impone una longitud de contraseña máxima.
Otro proceso de reflexión podría ser que, si un usuario se ve obligado a utilizar una contraseña corta, es más probable que invente un galimatías aleatorio que una frase o apodo fácilmente adivinado (por sus amigos / familiares). Este enfoque, por supuesto, solo es efectivo si el frontend impone números / letras de mezcla y rechaza las contraseñas que tienen palabras en el diccionario, incluidas las palabras escritas en l33t-speak.
Una razón por la cual las contraseñas no pueden ser hash es el algoritmo de autenticación utilizado. Por ejemplo, algunos algoritmos de resumen requieren una versión de texto claro 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 operaciones matemáticas en la contraseña ingresada (que generalmente no producirá el mismo resultado cada vez que la contraseña) se combina con un ''nonce'' generado aleatoriamente, que se comparte entre las dos máquinas).
A menudo, esto se puede fortalecer ya que el resumen puede ser parcialmente calculado 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 a través de canales que no están encriptados. Si utiliza SSL o algún otro cifrado de canal completo, no es necesario utilizar mecanismos de autenticación de digestión, lo que significa que las contraseñas pueden almacenarse hash (ya que las contraseñas podrían enviarse texto sin cifrar por cable de forma segura (para un valor de seguridad determinado).