Hacker News Reader

Comment by just2n | Hacker News Reader

You could really support an arbitrary password size by locally hashing the password to a length at least as long as the one you store in the database to preserve entropy, then send the fixed length hash as the user's "password", and hash it again on the server using something slower, like PBKDF2 with a few thousand rounds.

View on HN

How do you think hashing functions work?

At least on the web, hashing isn't usually done locally (ie, in Javascript).

this doesn't add extra security - the first hash becomes a substitute password. A cracker could modify their steam account to take said hash as input and sent it directly over the wire.

It doesn't remove any security, either. If you perform a hash on the server that sends an arbitrary input size to a fixed number of bits, the attacker needs only to try O(2^n) different inputs where n is the number of bits of that hash. By using a hash with at least n bits as a substitute password, there's no less security. It does mitigate the DoS vector, however.

no it doesn't remove any security, but why implement a feature that doesn't add anything?

It does add something: users can use any password they want. Any unicode string. You just UTF-8 encode then locally hash into a constant size. This alleviates the issue mentioned in the grandparent that supporting arbitrary length passwords introduces a DoS vector, especially when a slow hash is used on the server.

arbitrary length passwords simply aren't necessary though, and are unlikely to be used - if you were to cap passwords at, say, 128 characters, who would run into that limit?

I'm not arguing that if this functionality were already present in an app that you should remove it; however if it's not there already there's very little value it could add that would justify any development time. That's just my opinion though.

Reply on news.ycombinator.com