4 ms·
Not really. Even if you're worried about that, (36 alphanumeric + 10 symbols)^10 is roughly 4E16. Even at 2B checks/second/CPU (which is incredibly generous if
by dataflow 5y ago
Not really. Even if you're worried about that, (36 alphanumeric + 10 symbols)^10 is roughly 4E16. Even at 2B checks/second/CPU (which is incredibly generous if the web developer has any competence) that's around 10M CPU-seconds, i.e. 115 CPU-days. For cracking one single password. An ASIC will speed it up, but again, remember this is one single password, and it can be an overestimate by like a factor of > 1 million if the developer actually used a KDF (and I'm not sure why they wouldn't, if they're already hashing). How paranoid do you have to be (and how big of a target do you have to have made of yourself? and exactly how valuable are your credentials?) to worry about a threat like this for most websites? Maybe it makes sense for your primary email, but do average accounts really benefit? Compared to the inconvenience of when something goes wrong and you have to type a long password manually.
- GoblinSlayer 5y agoIf you don't let users use their preferred password structure, they'll have to use a shitty password like hunter2, letmein or dragon. Those can be recovered with a few attempts, even online. If you really want a 10 character password, you can hash the user's password, then imagine the first 10 bytes of the hash are the user's password, then do whatever you want with them.
- singlow 5y agoHow does one more iteration help? Your hash algorithm is already hashing multiple times. Seems it would be easier to increase the work input to PBKDF2 by 1 than to implement your own multi-hash. Even better increment it by 2000. But the point is that you don't control the website's hashing algorithm, or whether they hash at all, or whether they store their hashes in a public s3 bucket. They may tell you what they do, they may not. But you have to trust them either way. A long random password using a variety of characters is the only control I have when setting my password. If they have a good hashing system and protect their hashes, my long random password will not hurt anything. If they truncate my password before hashing, it will still be the best password I can make for that app. If I use 5 5 letter words as my password and they truncate after the first 10, how would I know? My password might be "horseapple" instead of "horseapplehappygreennymph". If I give them 10 alphanumerics and they leak their md5 hashes, I'm pwned in a few days, assuming they even salt it. If I give them 20 random alphanumeric+symbol then I can't imagine what exotic thing they could do wrong to make it less safe than any other password I choose. I might make an exception for some streaming service that I have to enter by hand on a tv remote control, but otherwise i am going to generate it with max entropy because I am never going to look at it anyway.
- deleted 5y ago[deleted]