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.