Can I ask what length your passwords are (roughly)? I don't understand the motivation for anything long in the context of randomly generated passwords for websites. 8-10 characters should be plenty.
My passwords are long because I don't actually use a password manager. I generate my passwords with a help of my algorithm that makes them easier to type in wherever I might need them (resemble real words) like in a terminal.
All my passwords are passphrases, randomly generated and stored in my password manager. Usually 10 words, for about 130 bits of entropy. EG PledgeRoutineSuitableBunkhouseExceptionCremeReassureChildishPhrasingNuclear, which is 76 ASCII characters but only 10 symbols.
They're stored in a password manager, but they're typeable if needed. My "security question" answers (mother's maiden name, etc) are generated the same way, unique per use, and also stored in my password manager.
Most sites don't need 128 bits of entropy. But things like banking or subscriptions should have at least 112 bits of entropy. And it's easy to just set the generator to 10 words by default.
Outside of things that need to be extremely secure like my AWS account password I usually prefer readable random words passwords over random text. Even random 2 word passwords usually surpass 20 characters especially after adding in numbers and special characters most sites require.
It's a lot nicer being able to check if I typed in my Peacock login at my parents home at a glance versus a string of random characters.
I usually generate passwords in the ~32 character range, using A-Za-z0-9, specifically to catch sites with dumb security policies (maximum number of characters, or considering `aceg1234!` a stronger password than `MgHm7MC8kEuXWKEzD7CvDgxCtWssz964`).
In most cases I just comply with their dumb policy and put a snarky comment for my future self in the Notes field of my password manager and it makes me feel better.
20 characters is fine. Even using only lowercase letters, in a worst-case scenario it'll take millions of years to guess by choosing characters, and a dictionary attack won't fare any better if you use four words that are moderately rare. Even if they're only in the top 1000, four words means the search space is 1 trillion guesses. Increase the search space to 10,000, by including such obscure words as "villager" and "conserve" and "missionary" (9950, 9973, and 9991, respectively) the search space increases to the quadrillions, equivalent of a 12-character random password with symbols, 53 bits.
Is correct-horse-battery-staple guaranteed secure to the heat death of the universe? No, but good enough that it'll take a targeted attack several months to guess.
If you're using a random password, c29b90b0e25ece3f2dabcef496d22103 is fine for a password, 2^128 bits. It's a right pain to type in on a console though.
On the other hand, "rundown skyline pluck shawl pastrami radar refueling poach prankster durable" is far easier to type and is about the same entropy
The entropy is far greater than 2^128. Pastrami, refueling, and shawl don't appear in the top 30,000 English words list, so even knowing your password generation strategy, every word adds at least 15 bits of entropy, you're up to 150 bits, probably more.
I use a password manager and randomly generated ones for most everything, but I use diceware pass phrases I memorized for specific cases so that in an emergency, e.g. when traveling I can get access to some things even without any of my devices.
For websites, you're just making your own life harder for no real gain. Even with purely alphanumeric 10 chars, it's not like anyone can exhaust the 36^10 password space over a network with no one noticing. Yet whenever you run into issues with the website or the password manager (or some other non-routine thing... like you're on your phone and need to enter this on a different computer) and have to enter it manually, it'll be much more painful than it has to be.
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.
If 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.
How 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.
Not true. Offline hacking is not only a concern for passwords used on multiple sites.
There are many scenarios where an attacker might be able to grab the hashes, but still need to crack them in order to get access to other data from your account. If there is a sql injection vulnerability in the authentication service, for example, it does not mean they can necessarily overwrite the hash or access data in other parts of the application.
I once found a bug in a payment processor that let me download the user record including password hash for all users in that payment processor. But I couldn't use that to get their stored credit card numbers directly. However, if I had brute forced those hashes, I would have been able to log in as them and access their other account data and make transfers, etc. I am sure a large majority of those password would have been very easy to crack. If I was an attacker, those would have been my first targets.
It's trivial to choose a smaller pw for sites that are difficult, but for the ones where I'm only ever using a pw manager to access, there's no reason not to use a 20 char unique random string.
For me I have long 20+ character passwords because my password manager remembers them for me, and I can copy/paste or autotype or copy them into the in-browser password manager.
I very rarely have to manually type in a password.
(This isn't to excuse silent truncation.)