Hacker News Reader

Comment by frou_dh | Hacker News Reader

> ... stupid password requirements; max lengths ...

> ... if they are hashing the passwords in any form then it doesn't matter how long the password is ...

Max lengths aren't inherently stupid. Presumably no one thinks 250MB password submissions should be handled, so you will be picking some number (possibly imposed on you by your stack).

View on HN

A 250MB requests should get blocked by your web server way before it touches your code or your database.

But yes, you're right, limiting passwords can help avoiding edge cases where a long password is not handled correctly ecc... Just pick a sane length that no-one will hit, like 1000 chars or more.

English has at least ~0.6 bits of entropy per character, probably (much) more, depending. (Got that from Wikipedia, so don't know how accurate that is)

So even if you are using an English passphrase, the logical upper bound for a max password length is ~1.7x the length of the hash you use.

If you're hashing it who cares if someone wants to submit a 250MB password? They'll only be slowing their own session down - what I store in the database is always 256 bits either way.

Because your app has to load it all into memory. Submitting many, very large payloads is a well known denial-of-service attack

Like a good developer, you run passwords through a slow hash function. This leaves you vulnerable to denial of service by wasting CPU hashing huge passwords: http://arstechnica.com/security/2013/09/long-passwords-are-g...

Predictably this just regresses to what constitutes a big number. Take your pick for one that would cause noteworthy resource consumption in a given system.

I think you failed to understand the second point you quoted.

A 250MB password should be perfectly valid (if a bit foolish on the customer's part). That 250MB password will be run through scrypt by javascript running on the browser. (That may take a while, and a large amount of memory, but this is part of the CUSTOMER'S stack, not the server's.) Some amount, perhaps 512 bits worth, is then passed to the server. (Where it is run through another hash and then stored.)

It's not at all common or best practices to run an expensive key derivation function browser side. Doing so adds little to no additional security -- if you don't trust the TLS channel then you are screwed any way you look at it.

It's not common, but running an expensive KDF client-side still greatly slows down a bruit force attack if the password hashes are stolen, without increasing load on your server. The fast one-way function run server-side then prevents the client from being able to submit a stolen hash, forcing an attacker with a list of stolen hashes to perform the full expensive bruit-force attack.

> That 250MB password will be run through scrypt by javascript

No, it will not. Nobody does this.

I didn't fail to understand it. Doing that clientside in JS is an anomaly.

Reply on news.ycombinator.com