A vendor recently suffered an issue with multi-megabyte passwords, effectively causing a denial of service. Can you explain why this happened? Is input validation the best mitigation?
Ask the Expert
Got a vexing problem for Michele Chubirka or any of our other experts? Ask your enterprise-specific questions today! (All questions are anonymous.)
Sometimes you can have too much of a good thing, as Django users discovered last September. A vulnerability was found in the Python-based Web application framework's authentication component that made Django applications susceptible to a denial-of-service (DOS) attack.
Essentially, Django did not have a maximum password length, potentially allowing attackers to submit unusually large plain text passwords that require a significant amount of time and computational power to hash. Hashing is the one-way process by which a plain text password is converted into an encoded string through the use of a cryptographic algorithm. This is done to prevent the storage of passwords in clear text, which makes them more susceptible to compromise by a malicious actor.
Django defaults to Password-Based Key Derivation Function 2 (PBKDF2), which uses "key stretching" in order to make the password more resilient against attempts to brute-force it. This function creates an enhanced key by feeding the initial key into the algorithm many times in order to make cracking the password more difficult.
However, since the Django authentication component enforced no restriction on the maximum size, this created an attack vector that could make the application unresponsive. Once the issue was disclosed through a developer mailing list, the Django Software Foundation released a security update setting the password maximum to 4,096 bytes. Everything needs boundaries, even passwords.
What can a developer or sysadmin do to prevent authentication vulnerabilities in applications? This is where application-level security testing becomes critical. Fuzzing is a standard method used by pen testers to validate application security. The technique involves submitting unexpected data to a component expecting input and observing the behavior of an application. Does it crash, throw an exception or drop the tester to a more privileged level of access? By adding fuzzing to application deployments an organization can better identify risk. However, this can be time consuming. If resources are limited, it's worthwhile to consider third-party validation.
This was first published in April 2014