Follow

Web developers:

The entire "Bee Movie" script hashes to 128 characters using SHA-512 encoding.

You don't need to limit the length of your users' passwords.

re: silly 

@monorail I know right? I gotta start using SHA-512 instead of gzip

re: silly 

@noelle i hear it's more expensive to unzip though

silly 

@monorail @noelle Not that you can ever decompress it back. :blobnervous:

silly 

@Jo @monorail @noelle

You've got to admit, it's good for passwords. Not too sure about anything else, though.

re: silly 

@wiredgoddesslain @Jo @noelle help i compressed my password with sha-512 and it got longer and my websites won't accept it

@noelle Some hash algorithms, e.g. bcrypt, actually truncate their input. That could justify setting a maximum password length (but we're talking 55 bytes or so).

@noelle Well, but that's a boring movie - no wonder you can cut it down to this size. How do more action-packed movies compare? :P

@noelle the only issue with this is that really long passwords cost badwidth and processing time (especially when hashing passwords *correctly* using memory-hard hashes like scrypt/bcrypt)

if you let people put unbounded length passwords into your system, you open yourself up to ddos attacks (and no, rate limiting doesn't fix this because of, yknow, CGNAT and institutional NAT cf universities with hundreds of people on an IP)

however! like... a limit of 300 chars is still totally reasonable, so the sentiment of the post makes sense. 10 chars or similar is not a reasonable upper limit at all

tech 

@er1n @noelle hash once in browser/app, then again on the server
if one wants to be a pain for oneself, let one!

re: tech 

@er1n @noelle ...though then again noscript
hm

re: tech 

@sobsz @er1n @noelle

I tested it and on my machine, I can hash/verify 1GB per second with argon2. This looks to be pretty much independent of how much cost you have on your function.

And this makes sense, because argon2 internally does a pre-hashing using Blake2, so however fast Blake2 hashes, argon2 will hash, ignoring the expensive stretching part.

So if I wanted to DoS you, short passwords that can be sent quicker is still the way to go.

@noelle new secop check: can you paste the entire bee movie script into the password field without crashing the system?

@noelle I was just trying this out on a side project, basically sending down an iteration count and a salt to the client website, then have them hash it on the client side before sending it up.

Actually, I did it for both password and user name (different salts) so they could use emoji for both (and I will never show a user name back, so I didn't care about getting it out).

... then treat it as a password anyways and to a different salted encryption before storing it.

Sign in to participate in the conversation
Elekk: Gameing and Other Delightful Pursuits

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!