This seem far fetched, not sure what thought process would lead anyone to come to this conclusion. Even if you have a million users, you have ~8MB worth of passwords. I'd imagine even developers who are not competent in cryptography realise that.
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.
Also please correct me if I'm wrong.
hash(saltFromServer + hash(password))
hash(user.salt + clientHash)
I would expect the image of MD5 on its codomain is almost a bijection (would love to be demonstrated wrong here, if anyone knows of a paper that studies this, but it seems reasonable that any good hash would have this property).
This doesn't really protect against a dictionary attack, but to guarantee a collision, an attacker would still need to try approximately 2^128 passwords for each password in the database, which is already the worst case for the attacker, so no strength is really lost.
SSL is just indispensable nowadays for authentication.
However, my bank uses X.509 certificates to authenticate users over Internet. Out of curiosity, I've asked bank employee once and was told that most users do manage their certificates just fine, without any issues. Obviously, bank provides short and simple manuals, which explain how to generate a certificate request, obtain a signed certificate (by visiting bank in person), authenticate and renew expiring certs.
(My bank's not using in-browser PKI due to legal reasons and provides a small piece of software wrapping around the browser, but that doesn't really matter.)
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.
So sitting here trying to think about a way to solve that problem, what I come up with is essentially PKI. But if the attacker has the ability to inject code, they can always break this entirely by stealing my private key.
This feels to me like URLs are fundamentally broken, in that a user might try to go to http://mybank.com. Is there any secure way to get their browser to redirect to https://mybank.com? It seems like there might be something that could be done with dnssec, but that feels brittle too. Gross.
Say the URL is: https://mybank.com, but I go to http://mybank.com, and I haven't been there yet, so the STS rule isn't in my browser. How can a user reliably be switched to https without risk of having the connection hijacked by someone injecting code to the user?
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.
For those who don't know, for varchar(1) through varchar(256) the internal database representation in sensible databases is one byte to say how long the varchar is, followed by the actual data. There is therefore absolutely no difference between the representation of varchar(30) and varchar(256) - it is just an arbitrary restriction on what data is allowed to fit in there. But databases that support varchar(257) need 2 bytes in front for it.
Is this true in most modern DBs? (I'm thinking MySQL and Postgres particularly).
http://www.postgresql.org/docs/9.2/static/datatype-character...
Don't use MySQL.