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

23

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

¿Qué causaría que un desarrollador ponga tales restricciones? Mientras haga el hashing inicial de una contraseña en el cliente, no hay carga en el servidor por tener que calcular el hash de las enormes contraseñas generadas automáticamente. Parece que no hay beneficio de usar tales restricciones

    
pregunta TheLQ 09.01.2011 - 22:31
fuente

5 respuestas

21

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 almacenamiento. Ahora, para las contraseñas, esto, por supuesto, es completamente erróneo, ya que deberían estar ocultas y, por lo tanto, no se almacenan ni se procesan realmente en texto claro.

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

    
respondido por el Jakob Borg 10.01.2011 - 02:20
fuente
11

Voy a ir con: los mismos viejos motivos por los que las personas hacen cosas extrañas.

  • Porque parecía una buena idea en ese momento. Los desarrolladores pueden tener buenas intenciones pero estar mal informados. No hay necesidad de limitar la longitud de la contraseña, pero tal vez los desarrolladores no lo saben. 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 tienen fallas de inyección de SQL en su base de datos, y en lugar de codificar correctamente las cosas para evitar la falla de inyección de SQL, es más fácil simplemente agregar a la lista negra algunos caracteres (por ejemplo, prohibir a los usuarios incluir comillas simples en sus contraseñas). Tal vez por alguna razón fue más fácil usar una matriz de longitud fija que una cadena de longitud variable. Quién sabe.

Conclusión: no existe una buena justificación para tales límites. Estoy seguro de que estamos acostumbrados al hecho de que el software disponible comercialmente a menudo contiene todo tipo de características de diseño extrañas. Sucede. Es un hecho de la vida. Es una consecuencia del hecho de que "lo suficientemente bueno" es mucho más barato que "perfecto".

    
respondido por el D.W. 10.01.2011 - 05:19
fuente
11

Una razón racional para limitar la longitud de la contraseña y el posible conjunto de caracteres es hacer que el usuario aplique las técnicas de administración de contraseña adecuadas. En palabras sencillas, 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 un pedazo de papel (tradicionalmente pegado debajo del teclado) y / o reutilice la misma contraseña en varios sistemas .

Conceptualmente, la forma en que el usuario administra sus propias contraseñas es su responsabilidad, y no pertenece al negocio del sitio web. Pero, en la práctica, los usuarios no tienen ni idea de 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 de la página web tratar de hacer lo que pueda para proteger al usuario.

Tenga en cuenta que no reclamo que tratar de imponer una buena gestión de la contraseña es la razón por la cual un sitio determinado limita la longitud de la contraseña; es solo una razón por la que 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 conjunto de caracteres limitado permitido es promover la interoperabilidad: preferiblemente, el usuario debería poder escribir su contraseña en una amplia gama de dispositivos de entrada. Los caracteres que no son ASCII no son buenos para nada que se parezca a un teclado de EE. UU. (Es posible escribir letras que no sean ASCII en un teclado de EE. UU. Lo hago todo el tiempo, pero los métodos varían según el sistema operativo y la configuración, y 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 tal restricción por razones malas (por ejemplo, para que la contraseña pueda ser descartada en un SQL). Solicitud sin escape de cadena adecuado, algo que solo puede describirse como ingeniería descuidada).

    
respondido por el Thomas Pornin 10.01.2011 - 15:28
fuente
3

Pensé que teníamos una pregunta como esta, pero mi búsqueda es 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 garantiza que pueda predecir el rendimiento del código.

También es posible que necesite un almacenamiento temporal al validar las contraseñas antes de que se las borre. De nuevo, 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 un segundo factor (como un token) puede ser más apropiado de todos modos.

    
respondido por el Rory Alsop 10.01.2011 - 02:06
fuente
1

Desde que mi primera pregunta perdió la marca, 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 verdaderamente efectivo. Si un usuario puede enviar una cadena grande, el costo de calcular este valor hash iterativo se vuelve más caro de lo esperado para una función de autenticación simple.

Cualquier tarea individualmente 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 si se envía una solicitud extremadamente larga. Si los parámetros en la solicitud están fuera de la longitud esperada, es sencillo emitir un mensaje de error y cerrar la conexión.

La razón por la cual los requisitos de complejidad de contraseña se aplican en muchos sitios es para evitar que los usuarios elijan una contraseña débil. Hay 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 siempre culparán al sitio en caso de robo o descifrado de una contraseña, y cualquier resultado que pueda tener tanto el sitio como el usuario afectado.

Al implementar requisitos de contraseñas seguras, se reduce la posibilidad 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 el desarrollador de un sitio tenga una política que impida que los ataques de fuerza bruta tengan éxito. Esto se logra requiriendo que un usuario seleccione una contraseña compleja y adecuadamente larga, y restringiendo el número de intentos de inicio de sesión fallidos antes de ralentizar (es decir, bloqueos temporales, captchas, etc.) o deteniendo los intentos de inicio de sesión (bloqueos permanentes, restablecimiento de contraseña obligatorio, confirmaciones de cuenta) , etc).

El segundo ataque es un ataque sin conexión, donde un atacante adquirirá una copia de una base de datos de contraseñas e intentará usar una tabla de arco iris o un descifrador de contraseñas sin conexión para descifrar varias cuentas. Este tipo de ataque se evita mediante el uso de un algoritmo de hash fuerte junto con una sal por usuario, y preferiblemente el rehashing estilo pcrkdf2 o bcrypt / scrypt 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 distintas cuentas. Muchos usuarios seleccionarán las mismas contraseñas para varias cuentas, y cuando esa contraseña esté expuesta, 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 seguras y únicas para cada sitio, o al menos diferentes grupos de sitios, y usar un administrador de contraseñas seguro para almacenar todas las contraseñas diferentes.

    
respondido por el ygjb 10.01.2011 - 02:05
fuente

Lea otras preguntas en las etiquetas