[derefr]

If you allow truly unlimited-length passwords, malicious users can set gigabyte-long passwords. Whether you hash them or just store them, that's a DoS waiting to happen with every login.

So, there actually is a reasonable limit for the length of passwords, email addresses, and most other user-editable fields that end up either being hashed, or shoved through to the database. That limit is just probably somewhere around 100KB to 1MB, not "eight". ;)

More importantly, that limit is an infrastructure concern, not a business-domain concern; it's best enforced by something like nginx spitting out a 400, not the model-validation logic in your app server.

[fruchtose]

While this is true, hashes use a set number of characters. For example, SHA-256 hashes can be stored in 32-character hex strings. In that sense, there's no point in allowing for a variable length field for password hashes.

[pyre]

It's not only dealing with password length. You could DoS the server by tying up all threads in processing the upload. Uploading 4GB isn't instantaneous.

[jbrechtel]

For the application code to complain about password length then the 4gb upload has to have already occurred.

Protecting against a DoS attack this way is done in the webserver, which doesn't care about individual fields. Sure this means there's an implicit password length limit, but not in any application-level sense.

[fruchtose]

I'm not arguing with that. I wholly agree with you that a client should not be able to upload 4 GB for the password field. I think I misread your first point as if it dealt with server-side storage.

[just2n]

That's why the client should perform the hash and only submit the result.

[derefr]

No; this is effectively the same as doing no hashing at all. If your database gets stolen, people can replay the "hashed" passwords from it to the server, without having to hash them themselves.

[just2n]

I didn't mean to imply that you'd just store the hash the client comes up with. That's idiotic, of course. Not everyone uses SSL, even though they should, and it's not always secure, and even with the use of SSL, it seems that there would be a potential length attack that could be employed to effectively guess a user's password length. So in all cases, IMO, it makes more sense to be receiving a fixed-length thing that is fairly insensitive to attack in itself. So perhaps a user has 2 salts associated with their account, per password: an auth salt and a storage salt. Then an auth looks something like this:

    hash(saltFromServer + hash(password))

And then the server would do

    hash(user.salt + clientHash)

I'm not sure, but this seems reasonable to me.

[ajanuary]

Now you have quite a restricted domain, so if your database is compromised there are a lot fewer values an attacker needs to enumerate to try and crack the password.

[drostie]

Here is the attack scenario: Alice is trying to login to server Bob, but her WiFi access point Eve is running a protocol-mismatch attack: Alice communicates to Eve by HTTP, which Eve records and then transmits to Bob by HTTPS. We'll assume that Eve does not inject her own scripts but just eavesdrops on the conversation.

Your problem: clientHash is "password-like" and Eve can use it to log in.

One solution: use the HTTPS auth methods. Unfortunately, this is not the standard in the industry because the GUI is ugly.

The reason why this is an even bigger problem than you might think: what does the login method do? It probably sets a "remember me!" cookie, which is also "password-like" for just about every purpose. Eve sniffs the cookie and can use it to compromise the account in the future.

Also the 'remember me' cookie is probably stored in the clear in the database. So much for that, eh?

What you really want is a system based on digital signatures: whenever I make a request I digitally sign it. But the core problem is that I don't want to type in my password for every damn request, so this is being cached between requests and between page views. Depending on how it's cached, there are vulnerabiities -- especially if you just have your browser automatically fill in the password blanks, but also if you carry these "password-like" login cookies. A system of delegation and revocation can be done, but you come dangerously close to reinventing a public key infrastructure if you go too far down this road.

HTTPS auth methods can help out quite a bit, but can be hard to set up with a custom backend and hard to test against that sort of "downgrade attack" I mentioned in my first paragraph. The best of these ideas is to give your users client certificates and thus be safe forever, but nobody has found it useful enough to actually do this.

The only real alternative has been to remind the customers to always look for the s in the "https:// in the location bar. This is stupid and now there are some proposals for browsers to ship with lists which are "Expected to be secure", to avoid it, but yeah, we never really outgrew it.

[icebraining]

If you don't use SSL and the attacker can sniff the stream, chances are he can inject JavaScript to send him the password.

SSL is just indispensable nowadays for authentication.

[ema]

Couldn't you solve that by hashing it again on the sever?

[codesuela]

I'm not sure about the added security benefit. Basically the only additional security is if someone gains access to your server they can't capture plain text passwords anymore but once someone gains access all bets are off and they might as well just switch out the Javascript. In any case you should run a strong hashing algorithm like bcrypt with a salt and oh I don't know 1000 iterations? Also last time I tried something like that (which was a few years ago) I ran into big problems with different hashing algorithm implementations providing different results (JS.md5("password") != Python.md5("password")).

Also please correct me if I'm wrong.