4 ms·

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

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.
nknighthb 13y ago
Purely in the spirit of "because I can", I fired up a 244GB EC2 instance: 1MB -- 0.310421895981 seconds 10MB -- 0.317299044132 100MB -- 0.409169948101 1GB -- 1.3299703002 10GB -- 10.8254830956 100GB -- 133.936514747 I noticed during the 100GB loop that the process oscillated between 100GB and 200GB, making me suspect that the 100GB string is actually being copied somewhere, which is inefficient and surely has a significant effect on the timings at larger string sizes. As such, I didn't go for a 200GB string. And just 'cause most of us don't see 200GB python processes every day: https://dl.dropboxusercontent.com/u/14571816/python%20200gb.png https://dl.dropboxusercontent.com/u/14571816/python%20200gb....
throwaway125 13y ago
now enter the first 72 characters of that password in the bcrypt verification function and it'll still say it's correct. bcrypt is a valid technical reason to limit passwords to 72 characters.

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.

nknighthb 13y ago

Purely in the spirit of "because I can", I fired up a 244GB EC2 instance: 1MB -- 0.310421895981 seconds 10MB -- 0.317299044132 100MB -- 0.409169948101 1GB -- 1.3299703002 10GB -- 10.8254830956 100GB -- 133.936514747 I noticed during the 100GB loop that the process oscillated between 100GB and 200GB, making me suspect that the 100GB string is actually being copied somewhere, which is inefficient and surely has a significant effect on the timings at larger string sizes. As such, I didn't go for a 200GB string. And just 'cause most of us don't see 200GB python processes every day: https://dl.dropboxusercontent.com/u/14571816/python%20200gb.png https://dl.dropboxusercontent.com/u/14571816/python%20200gb....

throwaway125 13y ago

now enter the first 72 characters of that password in the bcrypt verification function and it'll still say it's correct. bcrypt is a valid technical reason to limit passwords to 72 characters.