7 ms·
There's really not much rational for capping passwords at anything beneath 256 characters. 256 characters makes for a fairly sizable passphrase, and doesn't re
by terminado 11y ago
There's really not much rational for capping passwords at anything beneath 256 characters.
256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space. In reality, even if they were stored as encrypted binary/base64 in a nosql file system of structured data files, 4096 is pretty much the de-facto floor for disk space occupied by non-zero-byte individual files on most modern file systems.
...variable data size being a concern in cases where the transformed value is encrypted rather than hashed.
- gherkin0 11y ago> 256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space. They shouldn't be storing passwords at all so storage space should be a non-issue. My 20 meg password should hash down to the same small(er) value as your 15 character one.
- bosdev 11y agoThere is a slight exception to this. If they are using an older statically typed language like C, it might make sense for them to have a limit on the buffer ready to store your unhashed password. Yes it seems crazy these days, but it might apply to some of the older systems which have password length limits.
- a_t48 11y agoWhen there will be multiple shorter passwords that hash to the same value, is there a point to a 20mb pass?
- elektromekatron 11y agoDepends. Can you guess them?
- a_t48 11y agoIf I'm an attacker who is running through hashes...yes. Faster than the 20mb one.
- gherkin0 11y agoI misspoke, I meant size.
- ColinWright 11y agoYes. Ideally you want users to be able to remember their pass-phrases. To do so usually implies significant internal structure and/or correlations, so to get the necessary entropy they will be large. The fact that they hash to the same value as other things is effectively irrelevant.
- 0942v8653 11y agoOn 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 agoFast 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 agoI'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 agoIf 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 agoIt 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.
- h0w412d 11y agoBCrypt has a character limit of 72.
- Freaky 11y agoHard limit of 72, beyond which many implementations will silently truncate, and reduced entropy from each character beyond 55 bytes. Probably a good idea to pre-hash. Or use scrypt.