4 ms·

On the other hand, you might not want to be hashing a 20meg password. It is fast on my computer but it's fair to limit at something more reasonable. $ pyth

On the other hand, you might not want to be hashing a 20meg password. It is fast on my computer but it's fair to limit at something more reasonable. $ python -c 'print "8 bytes\n" * (20 * 1024 * 1024 / 8)' > 20meg.txt; time shasum -a 512 20meg.txt 59cb7f88ad8d6229e6d3a74ee422dff57e17f168c6e6fa44ef32c3f07a73a6e455d8b55c1265d5212b9ed5475b6d9364286645200dada59aa16905a9ce748561 20meg.txt real 0m0.289s user 0m0.284s sys 0m0.004s $ python -c 'print "8 bytes\n" * (16 / 8)' > 16byte.txt; time shasum -a 512 16byte.txt b6043d3a520424d5ec17dc0c23ba3b591d74517e2b9faa0df2d69d13c89a5f372d6dc35f95836687ee05be18433277e1c4b67393eb2771b475d655a832b16654 16byte.txt real 0m0.045s user 0m0.040s sys 0m0.004s

thaumaturgy 11y ago
Fast password hashing is bad anyway. Slow schemes are better (assuming they come from a thoroughly tested library written by someone that actually knows what they're doing).
rev_bird 11y ago
I'm admittedly not familiar with the details of the hashing process, but it could be done client-side, no? Then the compute power required falls on the user, PLUS the 20 megs never gets sent over the wire.
- Retra 11y ago
  If you're not sending 20 megs of data, you're not getting 20 megs of security. So why allow it if it doesn't add anything?
  - ColinWright 11y ago
    It doesn't add to the security, but I might find it easier to remember 20 MB of redundant and meaningful stuff than to remember 384 bits of literally random stuff. The entropy might be the same, but my memory is not a computer. I can remember vast amounts of material that is meaningful and use it as a password. I can't remember 384 bits that have no meaning. The benefit isn't in the entropy, it's in the abilities of your users to remember their passwords/passphrases in the first place.
    - 0942v8653 11y ago
      Maybe 1 or 2 KB, max. 20 million characters is a ridiculous password to remember.
      - ColinWright 11y ago
        That's not the point - the difference between 2 KB and 20 MB is purely a detail. You said: > If you're not sending 20 megs of data, > you're not getting 20 megs of security. > So why allow it if it doesn't add anything? You could just as equally say: > If you're not sending 2 KB of data, > you're not getting 2 KB of security. > So why allow it if it doesn't add anything? Your point is the same, and it's still wrong. What you're getting is not the security - that's only half the story. My point is that is does add something, it's just that the something it adds isn't the entropy for the purpose of security.
- mkagenius 11y ago
  No. Actually we would not want the hashing technique to be exposed in the source code.
  - ColinWright 11y ago
    That turns out not to be the whole story. Hiding the technique to compute the hash is relying on security by obscurity. Ideally you want a system that is secure even if potential attackers know what methods you're using.
- roblabla 11y ago
  That would assume your users have JS enabled. I've seen something like that done before, but always with a fallback in case user has JS disabled.
- GlennS 11y ago
  If you do the hashing on the client side, then the hash itself effectively becomes the password.

thaumaturgy 11y ago

Fast password hashing is bad anyway. Slow schemes are better (assuming they come from a thoroughly tested library written by someone that actually knows what they're doing).

rev_bird 11y ago

I'm admittedly not familiar with the details of the hashing process, but it could be done client-side, no? Then the compute power required falls on the user, PLUS the 20 megs never gets sent over the wire.

Retra 11y ago
If you're not sending 20 megs of data, you're not getting 20 megs of security. So why allow it if it doesn't add anything?
- ColinWright 11y ago
  It doesn't add to the security, but I might find it easier to remember 20 MB of redundant and meaningful stuff than to remember 384 bits of literally random stuff. The entropy might be the same, but my memory is not a computer. I can remember vast amounts of material that is meaningful and use it as a password. I can't remember 384 bits that have no meaning. The benefit isn't in the entropy, it's in the abilities of your users to remember their passwords/passphrases in the first place.
  - 0942v8653 11y ago
    Maybe 1 or 2 KB, max. 20 million characters is a ridiculous password to remember.
    - ColinWright 11y ago
      That's not the point - the difference between 2 KB and 20 MB is purely a detail. You said: > If you're not sending 20 megs of data, > you're not getting 20 megs of security. > So why allow it if it doesn't add anything? You could just as equally say: > If you're not sending 2 KB of data, > you're not getting 2 KB of security. > So why allow it if it doesn't add anything? Your point is the same, and it's still wrong. What you're getting is not the security - that's only half the story. My point is that is does add something, it's just that the something it adds isn't the entropy for the purpose of security.
mkagenius 11y ago
No. Actually we would not want the hashing technique to be exposed in the source code.
- ColinWright 11y ago
  That turns out not to be the whole story. Hiding the technique to compute the hash is relying on security by obscurity. Ideally you want a system that is secure even if potential attackers know what methods you're using.
roblabla 11y ago
That would assume your users have JS enabled. I've seen something like that done before, but always with a fallback in case user has JS disabled.
GlennS 11y ago
If you do the hashing on the client side, then the hash itself effectively becomes the password.