it-swarm-es.com

¿Por qué algunos sitios web y programas restringen las características de la contraseña?

Hay algunos sitios web e incluso programas que utilizo que tienen restricciones de contraseña ridículas. Muchos foros, por ejemplo, restringen las contraseñas a ~ 32 caracteres. Otros hacen cumplir un juego de caracteres restringido.

¿Qué haría que un desarrollador imponga tales restricciones? Siempre que realice el hash inicial de una contraseña en el cliente, no hay carga en el servidor por tener que calcular el hash de enormes contraseñas autogeneradas. Parece que no hay beneficio de usar tales restricciones

22
TheLQ

Creo que la razón es la misma que para cualquier otra validación de entrada; para asegurarse de que no cause ningún problema durante el procesamiento y el almacenamiento. Ahora, para las contraseñas, esto es, por supuesto, completamente equivocado, ya que deben ser hash y, por lo tanto, no deben almacenarse ni procesarse realmente en texto sin formato.

Tomaría tales limitaciones como una indicación de que los desarrolladores no saben lo que están haciendo de manera segura, y probablemente van a almacenar la contraseña en texto sin cifrar. Mantente alejado.

21
Jakob Borg

Voy a seguir con: las mismas razones por las que la gente hace cosas extrañas.

  • Porque parecía una buena idea en ese momento. Los desarrolladores podrían tener buenas intenciones pero estar mal informados. No es necesario limitar la longitud de la contraseña, pero tal vez los desarrolladores no lo sepan. Tal vez los desarrolladores ni siquiera lo pensaron.

  • Porque era más fácil que las alternativas. Quizás están usando una API que no puede manejar contraseñas de longitud arbitraria; eso podría hacer que sea más fácil limitar la longitud de la contraseña que usar una API mejor. Tal vez tengan fallas de inyección SQL en su base de datos, y en lugar de codificar las cosas correctamente para evitar la falla de inyección SQL, es más fácil incluir en la lista negra algunos caracteres (por ejemplo, prohibir a los usuarios incluir comillas simples en sus contraseñas). Quizás por alguna razón fue más fácil usar una matriz de longitud fija que una cadena de longitud variable. Quién sabe.

En pocas palabras: no hay una justificación realmente buena para tales límites. Estoy seguro de que estamos acostumbrados al hecho de que el software disponible comercialmente a menudo contiene todo tipo de errores de diseño extraños. Sucede. Es un hecho de la vida. Es una consecuencia del hecho de que "suficientemente bueno" es mucho más barato que "perfecto".

11
D.W.

Una razón racional para limitar la longitud de la contraseña y el posible juego de caracteres es solicitar al usuario que aplique las técnicas adecuadas de administración de contraseña. En palabras simples, si una contraseña es enorme o está llena de caracteres extraños, esto aumenta la probabilidad de que el usuario escriba la contraseña en algún papel (tradicionalmente pegado bajo el teclado) y/o reutilice la misma contraseña en varios sistemas .

Conceptualmente, la forma en que el usuario maneja sus propias contraseñas es su responsabilidad, y no es asunto del sitio web. Pero, en la práctica, los usuarios no tienen idea de la seguridad y no pueden aburrirse con nada que no tenga una retribución inmediata (especialmente cuando los usuarios son clientes potenciales). Por lo tanto, depende del sitio web intentar hacer lo que pueda para proteger al usuario.

Tenga en cuenta que no afirmo que intentar hacer cumplir una buena administración de contraseñas es la razón por la cual un sitio determinado limita la longitud de la contraseña; es solo una razón por la cual I imaginaría una limitación de longitud de contraseña en mi propio sitio (si tuviera que administrar un sitio web con contraseñas de usuario).

Otra razón para un juego de caracteres permitido limitado es promover la interoperabilidad: preferiblemente, el usuario debe poder escribir su contraseña en una amplia gama de dispositivos de entrada. Los caracteres no ASCII no son buenos para nada que se parezca a un teclado estadounidense (es posible escribir letras no ASCII en un teclado estadounidense, lo hago todo el tiempo, pero los métodos varían según el sistema operativo y la configuración). no funciona bien con la escritura a ciegas, como es habitual con la entrada de contraseña). Los teléfonos inteligentes tienen restricciones aún mayores. Una vez más, la interoperabilidad es (en mi opinión) una buena razón para imponer un conjunto de caracteres limitado, pero muchos sitios web tendrán esa restricción por mala razones (por ejemplo, para que la contraseña se pueda volcar descuidadamente en un SQL solicitud sin escape de cadena adecuado, algo que solo puede describirse como ingeniería descuidada).

11
Thomas Pornin

Pensé que teníamos una pregunta como esta, pero mi búsqueda fué débil esta noche o estaba en otro sitio.

Básicamente, en la mayoría de las aplicaciones o bases de datos tiene sentido definir límites útiles en las cadenas de entrada. Esto le permite detener la entrada una vez que se alcanza el límite (lo que puede evitar desbordamientos, etc.) y también le permite predecir el rendimiento del código.

También es posible que necesite almacenamiento temporal al validar las contraseñas antes de que se mezclen; nuevamente, permitir una entrada arbitrariamente larga puede causar problemas.

¿Por qué 32? Una cifra razonable para la mayoría de los propósitos: la entropía en 32 caracteres es enorme. Por supuesto, en algunos entornos esto no será suficiente, pero para muchos de ellos un certificado o segundo factor (como un token) puede ser más apropiado de todos modos.

3
Rory Alsop

Como mi primera pregunta no dio en el blanco, proporciono una respuesta por separado. La razón principal es que se requieren límites. Aunque la preocupación con respecto al espacio de almacenamiento y la cantidad de datos es precisa, existen algunos problemas.

Primero, si lees mi respuesta original a continuación, verás que una de las recomendaciones es el hashing iterativo (es decir, pbkdf). Esto requiere una gran cantidad de iteraciones para ser realmente efectivo. Si un usuario puede enviar una cadena grande, el costo de calcular este valor hash iterativo rápidamente se vuelve más costoso de lo esperado para una función de autenticación simple.

Cualquier tarea computacionalmente costosa en un servidor, especialmente una que está explícitamente disponible para un usuario no autenticado, está sujeta a abuso por parte de un usuario malintencionado para realizar un ataque de denegación de servicio.

En segundo lugar, al implementar una contraseña de longitud fija, brinda la oportunidad de terminar antes de tiempo si se envía una solicitud extremadamente larga. Si los parámetros en la solicitud están fuera de la longitud esperada, es simple emitir un mensaje de error y cerrar la conexión.


La razón por la cual los requisitos de complejidad de la contraseña se aplican en muchos sitios es para evitar que los usuarios elijan una contraseña débil. Existen numerosos ejemplos en la historia reciente que muestran que la mayoría de los usuarios seleccionarán contraseñas débiles, fáciles de ingresar y fáciles de recordar sobre contraseñas complejas. Cuando esto ocurre, el propietario del sitio se pone en riesgo, ya que los usuarios invariablemente culparán al sitio si se roba o se rompe una contraseña, y cualquier resultado que pueda tener tanto para el sitio como para el usuario afectado.

Al implementar requisitos de contraseña segura, reduce la probabilidad de que un atacante pueda adivinar fácilmente la contraseña. Las contraseñas también deben protegerse contra dos rutas de ataque diferentes. El primero, los ataques en línea, requiere que un desarrollador del sitio tenga una política que evite que los ataques de fuerza bruta tengan éxito. Esto se logra al requerir que un usuario seleccione una contraseña compleja y adecuadamente larga, y al restringir el número de intentos fallidos de inicio de sesión antes de reducir la velocidad (es decir, bloqueos temporales, captchas, etc.) o detener los intentos de inicio de sesión (bloqueos permanentes, restablecimiento obligatorio de contraseña, confirmaciones de cuenta , etc.).

El segundo ataque es un ataque fuera de línea, donde un atacante adquirirá una copia de una base de datos de contraseñas e intentará usar una tabla Rainbow o un descifrador de contraseñas fuera de línea para descifrar varias cuentas. Este tipo de ataque se previene mediante el uso de un algoritmo de hash fuerte junto con una sal por usuario, y preferiblemente pbkdf2 o bcrypt/scrypt rehashing para aumentar el costo computacional del craqueo fuera de línea.

En última instancia, ambas técnicas fallan si los sitios no alientan a los usuarios a seleccionar una contraseña única para sus diversas cuentas. Muchos usuarios seleccionarán las mismas contraseñas para varias cuentas, y cuando se expone esa contraseña, especialmente con su cuenta de correo electrónico, es posible que un atacante use esa credencial en otro servicio. Por esta razón, es mejor generar contraseñas únicas y seguras para cada sitio, o al menos diferentes grupos de sitios, y utilizar un administrador de contraseñas seguro para almacenar todas las contraseñas diferentes.

1
ygjb