4 ms·

> ... stupid password requirements; max lengths ... > ... if they are hashing the passwords in any form then it doesn't matter how long the password is ... Ma

by frou_dh 13y ago

> ... 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).

mcherm 13y ago
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.)
- bradleyjg 13y ago
  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.
  - KMag 13y ago
    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.
- frou_dh 13y ago
  I didn't fail to understand it. Doing that clientside in JS is an anomaly.
- nollidge 13y ago
  > That 250MB password will be run through scrypt by javascript No, it will not. Nobody does this.
lmm 13y ago
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.
- frou_dh 13y ago
  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.
- calpaterson 13y ago
  Because your app has to load it all into memory. Submitting many, very large payloads is a well known denial-of-service attack
- michaelt 13y ago
  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-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g...
Spittie 13y ago
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.
TheLoneWolfling 13y ago
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.

by frou_dh 13y ago

mcherm 13y ago

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.)

bradleyjg 13y ago
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.
- KMag 13y ago
  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.
frou_dh 13y ago
I didn't fail to understand it. Doing that clientside in JS is an anomaly.
nollidge 13y ago
> That 250MB password will be run through scrypt by javascript No, it will not. Nobody does this.

lmm 13y ago

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.

frou_dh 13y ago
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.
calpaterson 13y ago
Because your app has to load it all into memory. Submitting many, very large payloads is a well known denial-of-service attack
michaelt 13y ago
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-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g...

Spittie 13y ago

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.

TheLoneWolfling 13y ago

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.