Share this story

For more than a year, Ars has advised readers to use long, randomly generated passwords to protect their digital assets. Now comes definitive proof that too much password length can be detrimental to security.

It comes in the form of just-patched vulnerability in the Django Web development framework. By default, it uses the PBKDF2 algorithm to transform plain-text passwords into long strings called cryptographic hashes. Like scrypt and bcrypt, it's one of the most secure ways websites can store "at rest" passwords, because it passes them through multiple hashing rounds that significantly increase the time and computational resources required. In the event of a breach that spills a large password database, the additional effort can literally add centuries to the process of cracking the raw passwords.

But as Django developers have learned, this enhanced security can be a double-edged blade. In an advisory posted Monday they explained why:

Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large—and guaranteed-to-fail—passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.

Shortly after someone disclosed the DoS vulnerability on a public forum for Django developers, maintainers quickly scrambled to patch it. The updates, which limit passwords to 4096 bytes, are linked to Monday's advisory. The post went on to reminded users that Django developers prefer to receive security disclosures privately at security@djangoproject.com so they can fix the vulnerability before it becomes widely known.

Well, I think this "bug" raises some interesting points about any authentication system:

For any cryptographic hash function, there is a function (call it D) that is the difficulty measured in number of integer ops to perform a computation on input of length L.

At any time in history with Moore's law applying to both the attacker and the host machines, and with any hash function, a particular hash function's difficulty D gives a lower bound, L_low, on L by "too easy to make hash tables" as per the MD5 password cracks of previous articles. This article says there is definitely an upper bound on L, L_high, as in "simultaneous logins crash our system".

As Moore's law continues, we either need L_low and L_high to steadily migrate upwards, or we need to increase D regularly by regularly finding more difficult hash functions. The first is a big problem for users, and the second is an even bigger problem for mathematicians.

This is a nasty problem with no obvious long-term solution beyond the red queen's race.

This is why tools like PBKDF2 and bcrypt have the concept of a work factor, which is stored alongside the hash, with the salt. When you want to increase the difficulty of D, you increase the work factor. Doing this is rather trivial: when a user tries to log in and you determine that their hash has an old work factor, you just re-compute their password with the new work factor and store the resulting hash. This allows you to regularly increase D.

With no offense intended, I feel the headline is somewhat misleading. I has assumed that it meant that there was some sort of reduction in end user security by having e.g. a fourty character password rather than a twenty. This seems like a problem with Django not placing some common sense security protocols rather than a problem with having large passwords.Edit: Headline corrected. Thank you.

With no offense intended, I feel the headline is somewhat misleading. I has assumed that it meant that there was some sort of reduction in end user security by having e.g. a fourty character password rather than a twenty. This seems like a problem with Django no placing some common senses security protocols rather than a problem with having large passwords.

Agreed. The combination of headline and contents read more like something I'd expect to read on a tech tabloid not a serious news site.

Since when are Denial Of Service attacks directly related to Security Risks?

Also it's not the *use* of practical long passwords (a 1MB password is not within anybody's realistic use case) that cause the problem, but the fact that the password acceptance code sets no upper limit to the size of passwords.

With no offense intended, I feel the headline is somewhat misleading. I has assumed that it meant that there was some sort of reduction in end user security by having e.g. a fourty character password rather than a twenty. This seems like a problem with Django no placing some common senses security protocols rather than a problem with having large passwords.

Agreed. The combination of headline and contents read more like something I'd expect to read on a tech tabloid not a serious news site.

Ditto. While technically true, "bad for security" is awfully broad. "Long passwords are good, but too much length opens the door for DoS attacks" would be more succinct and effective, though it would probably drive less clicks.

With no offense intended, I feel the headline is somewhat misleading. I has assumed that it meant that there was some sort of reduction in end user security by having e.g. a fourty character password rather than a twenty. This seems like a problem with Django not placing some common sense security protocols rather than a problem with having large passwords.Edit: Spelling

It's from the server's POV -- going down to user-submitted data generally being considered a security flaw.

I, like the posters above, thought the article would be about something else.

So, instead, I will post my own "rant" about sites that are unfriendly to long passwords.

GE Capital (https://www.gogecapital.com/en/consumer ... index.html) prevents users from pasting their own passwords into the login form. My password is at least 20 characters (random chars). Typing it in would take a very long time and be very prone to mistakes. However, since the site actually prevents users from pasting their passwords, they are, in effect, promoting easy to type passwords, which I believe are unsafe.

Yes, I do realize that I can get around this issue by going into the browser developer tools and enabling paste, but I don't think that is an acceptable solution.

In my software, I run passwords through SHA256 on the client side before sending them off (where the values are then stored salted/hashed separately of course). Obviously, this requires the user to have Javascript running, but it does significantly cut down on this kind of attack vector and it means that the user's password isn't ever sent over the network.

Well, I think this "bug" raises some interesting points about any authentication system:

For any cryptographic hash function, there is a function (call it D) that is the difficulty measured in number of integer ops to perform a computation on input of length L.

At any time in history with Moore's law applying to both the attacker and the host machines, and with any hash function, a particular hash function's difficulty D gives a lower bound, L_low, on L by "too easy to make hash tables" as per the MD5 password cracks of previous articles. This article says there is definitely an upper bound on L, L_high, as in "simultaneous logins crash our system".

As Moore's law continues, we either need L_low and L_high to steadily migrate upwards, or we need to increase D regularly by regularly finding more difficult hash functions. The first is a big problem for users, and the second is an even bigger problem for mathematicians.

This is a nasty problem with no obvious long-term solution beyond the red queen's race.

I, like the posters above, thought the article would be about something else.

So, instead, I will post my own "rant" about sites that are unfriendly to long passwords.

GE Capital (https://www.gogecapital.com/en/consumer ... index.html) prevents users from pasting their own passwords into the login form. My password is at least 20 characters (random chars). Typing it in would take a very long time and be very prone to mistakes. However, since the site actually prevents users from pasting their passwords, they are, in effect, promoting easy to type passwords, which I believe are unsafe.

Yes, I do realize that I can get around this issue by going into the browser developer tools and enabling paste, but I don't think that is an acceptable solution.

Chase bank: doesn't use case-sensitive passwords. (and we all know about blizzard, for that matter.)

You had me scared there, I work for a company that sells a web application that uses PBKDF2-hashed passwords. Boy was I relieved after reading the entire story, we're already limiting passwords to 255 characters because I was worried about this exact issue.

Since when are Denial Of Service attacks directly related to Security Risks?

Also it's not the *use* of practical long passwords (a 1MB password is not within anybody's realistic use case) that cause the problem, but the fact that the password acceptance code sets no upper limit to the size of passwords.

The headline is grossly misleading.

Generally when discussing computer security we talk about confidentiality (i.e. that stuff is kept secret), but there are two other aspects to computer security as well: integrity (is this data the correct data), and availability (can I access my data). This vulnerability targets the third aspect.

That said, I too thought the headline suggested that long passwords were less safe than shorter.

In my software, I run passwords through SHA256 on the client side before sending them off (where the values are then stored salted/hashed separately of course). Obviously, this requires the user to have Javascript running, but it does significantly cut down on this kind of attack vector and it means that the user's password isn't ever sent over the network.

No it doesn't. You still need to check the password length before hashing it on the server side.

I expected better from Ars - this is a very misleading headline. Also, a 4KB password would be thousand+ of characters long - I would take a wild stab here and say that less than 1% of regular users use passwords that long, and that's probably a wild exaggeration.

In my software, I run passwords through SHA256 on the client side before sending them off (where the values are then stored salted/hashed separately of course). Obviously, this requires the user to have Javascript running, but it does significantly cut down on this kind of attack vector and it means that the user's password isn't ever sent over the network.

No it doesn't. You still need to check the password length before hashing it on the server side.

Yeah, the proper thing to do for offloading is perform the key stretching client-side, not server-side. There is no need for the server to do any adaptive hashing if the client can provide a secure input, so it basically mass distributes the computationally expensive bit and lets the server perform a cheap single SHA operation. That provides both security and scalability.

Fly in the ointment there is mobile devices, which are sufficiently slow that performing a significant enough number of rounds might prove to be too much of a UI issue. That'll go away as mobile devices close the gap with desktops however, and even then a certain amount of work can still be offloaded, better then nothing.

Well, I think this "bug" raises some interesting points about any authentication system:

For any cryptographic hash function, there is a function (call it D) that is the difficulty measured in number of integer ops to perform a computation on input of length L.

At any time in history with Moore's law applying to both the attacker and the host machines, and with any hash function, a particular hash function's difficulty D gives a lower bound, L_low, on L by "too easy to make hash tables" as per the MD5 password cracks of previous articles. This article says there is definitely an upper bound on L, L_high, as in "simultaneous logins crash our system".

As Moore's law continues, we either need L_low and L_high to steadily migrate upwards, or we need to increase D regularly by regularly finding more difficult hash functions. The first is a big problem for users, and the second is an even bigger problem for mathematicians.

This is a nasty problem with no obvious long-term solution beyond the red queen's race.

This is why tools like PBKDF2 and bcrypt have the concept of a work factor, which is stored alongside the hash, with the salt. When you want to increase the difficulty of D, you increase the work factor. Doing this is rather trivial: when a user tries to log in and you determine that their hash has an old work factor, you just re-compute their password with the new work factor and store the resulting hash. This allows you to regularly increase D.

You don't need to worry about it, this is not an end-user problem, it's where someone slipped up on input constraints such that a pathological input could use up an inordinate amount of resources. It's got nothing to do with you directly except for possibly causing you not to be able to login during an active DOS. You should feel free to use whatever the site will allow, though in practice anything properly random and 20-30+ (picking from the full keyboard) should be just fine.

I, like the posters above, thought the article would be about something else.

So, instead, I will post my own "rant" about sites that are unfriendly to long passwords.

GE Capital (https://www.gogecapital.com/en/consumer ... index.html) prevents users from pasting their own passwords into the login form. My password is at least 20 characters (random chars). Typing it in would take a very long time and be very prone to mistakes. However, since the site actually prevents users from pasting their passwords, they are, in effect, promoting easy to type passwords, which I believe are unsafe.

Yes, I do realize that I can get around this issue by going into the browser developer tools and enabling paste, but I don't think that is an acceptable solution.

Thanks. It's good to know that we can usually find your plain-text password in your clipboard and in a file that's probably on your desktop.

I'm not sure why you would assume that. I use KeePass, so (hopefully) it is pretty secure, although I have no doubt that the NSA could get to it if they wanted.

Also, if you can get access to files on my computer, I think I have more important things to worry about than my online passwords (which, BTW, you could get using any number of methods assuming you have control of my computer).

Wouldn't it be better to simply use a fast but secure hash to preprocess the password? If the key hashing algorithm's running time depends strongly on password length it might also be susceptible to timing attacks.

Wouldn't it be better to simply use a fast but secure hash to preprocess the password? If the key hashing algorithm's running time depends strongly on password length it might also be susceptible to timing attacks.

PBKDF2 is (generally) built upon SHA 256, which uses a, IIRC, 64 byte block size. Since virtually every user will use a <20 character/byte password (character == byte in most cases, assuming UTF8) that means virtually every user will take the same amount of time to hash (only a single block of data). Even if the password was encoded as UTF16, that'd still be 32 characters (or fewer if extremely exotic characters were used, but those would doubly screw an attacker).

At most, you can save a bit of time by not even bothering if you figure out someone has a password that takes multiple blocks.

This attack works because it's >15,000 times as many blocks as a standard user would have (in addition to developers being naive).

Edit: Or if it takes null terminated strings and includes the null, drop that down to 63 characters (ASCII-centric UTF8) or 31 (common UTF16 characters only) characters for most cases.

Chase bank: doesn't use case-sensitive passwords. (and we all know about blizzard, for that matter.)

While we're on the subject of banks with crap security - Halifax: passwords are case-insensitive, no spaces, hyphens or special characters allowed. At least they allow 6-20 characters and require three letters and one number.