6 ms·

There's no reason to limit the length of passwords whatsoever, except perhaps to be sure you're not trying to hash 20mb of text.

just2n 13y ago
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.
- Hello71 13y ago
  How do you think hashing functions work?
  - TillE 13y ago
    At least on the web, hashing isn't usually done locally (ie, in Javascript).
    - alexjeffrey 13y ago
      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.
      - just2n 13y ago
        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.
        alexjeffrey 13y ago
        no it doesn't remove any security, but why implement a feature that doesn't add anything?
        just2n 13y ago
        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.
        alexjeffrey 13y ago
        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.
nknighthb 13y ago
I won't say 20MB passwords wouldn't pose any practical problems, but the hashing itself isn't really an issue. A simple bcrypt test on my laptop (w/work factor 12) gave me these numbers: 1KB: 0.279 secs 1MB: 0.277 10MB: 0.293 100MB: 0.473 1000MB: 2.169 Getting the 1GB string allocated in Python locked my system up for longer than the 20 loops over bcrypt did. :) I should probably find a machine with a little more RAM to test 10GB...
- thaumaturgy 13y ago
  The primary problem here would be a DoS attack against a web server that accepted that much data in a submission form. edit: also, merely saying "bcrypt" isn't quite sufficient; we'd have to know what work factor you were testing with. bcrypt with a work factor of 2 is vastly different in performance from bcrypt with a work factor of 12.
  - nknighthb 13y ago
    > we'd have to know what work factor you were testing with Parentheses are not made to be ignored. But I don't think it matters, which is why it was a parenthetical. The point is the relative differences between different sized strings, not the absolute timings.
    - thaumaturgy 13y ago
      Whoops, sorry -- dunno how I missed that.
  - Spittie 13y ago
    Isn't the password length check done locally on the machine (with javascript or similar)? If so, an attacker could easily ignore that check and send as much data as he want. The check on that should (and, AFAIK, is) done server-side, with the server closing the connection after a certain amount of data or time.
- nitrogen 13y ago
  Doesn't most of bcrypt's work come from rehashing its output? So it only has to touch the 1GB input once, right? Edit: after reading https://en.wikipedia.org/wiki/Bcrypt#Algorithm https://en.wikipedia.org/wiki/Bcrypt#Algorithm, it looks like bcryt's make-work loop does refer to the key in each iteration. I can't tell on a cursory reading whether access to the original key can be memoized, though hashing the large input once before passing it into bcrypt would have the same effect.

just2n 13y ago

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.

Hello71 13y ago
How do you think hashing functions work?
- TillE 13y ago
  At least on the web, hashing isn't usually done locally (ie, in Javascript).
  - alexjeffrey 13y ago
    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.
    - just2n 13y ago
      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.
      - alexjeffrey 13y ago
        no it doesn't remove any security, but why implement a feature that doesn't add anything?
        just2n 13y ago
        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.
        alexjeffrey 13y ago
        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.

nknighthb 13y ago

I won't say 20MB passwords wouldn't pose any practical problems, but the hashing itself isn't really an issue. A simple bcrypt test on my laptop (w/work factor 12) gave me these numbers: 1KB: 0.279 secs 1MB: 0.277 10MB: 0.293 100MB: 0.473 1000MB: 2.169 Getting the 1GB string allocated in Python locked my system up for longer than the 20 loops over bcrypt did. :) I should probably find a machine with a little more RAM to test 10GB...

thaumaturgy 13y ago
The primary problem here would be a DoS attack against a web server that accepted that much data in a submission form. edit: also, merely saying "bcrypt" isn't quite sufficient; we'd have to know what work factor you were testing with. bcrypt with a work factor of 2 is vastly different in performance from bcrypt with a work factor of 12.
- nknighthb 13y ago
  > we'd have to know what work factor you were testing with Parentheses are not made to be ignored. But I don't think it matters, which is why it was a parenthetical. The point is the relative differences between different sized strings, not the absolute timings.
  - thaumaturgy 13y ago
    Whoops, sorry -- dunno how I missed that.
- Spittie 13y ago
  Isn't the password length check done locally on the machine (with javascript or similar)? If so, an attacker could easily ignore that check and send as much data as he want. The check on that should (and, AFAIK, is) done server-side, with the server closing the connection after a certain amount of data or time.
nitrogen 13y ago
Doesn't most of bcrypt's work come from rehashing its output? So it only has to touch the 1GB input once, right? Edit: after reading https://en.wikipedia.org/wiki/Bcrypt#Algorithm https://en.wikipedia.org/wiki/Bcrypt#Algorithm, it looks like bcryt's make-work loop does refer to the key in each iteration. I can't tell on a cursory reading whether access to the original key can be memoized, though hashing the large input once before passing it into bcrypt would have the same effect.