Don't use fancy combinations. Word phrases are even more random and much easier to remember. E.G. "touch-some-grass" is rander longer than any recommended minimum and hardly could be connected to any website.
I remember at some point Hotmail had a maximum length limit of sixteen characters.
https://arstechnica.com/information-technology/2012/09/secre...
For services there are often better alternatives.
Bcrypt for example would require at most ~6.4Mb of memory to do the hash, and more realistically only the 100k plus some constant. And modern CPUs are pretty efficient at doing the encryption steps, meaning little additional load for encrypting a larger value.
And if someone knows why banks are specially prone to having crapshit password requirements... Flashback to my french bank that had a password that needed to be exactly 8 digits, no letters or other, and that you could only type by clicking on a digital numpad that had the numbers randomly sorted.
<input type="password" hash="sha-256" />
For all the development that goes into browsers, HTML is really missing some basic stuff that tons of people need. Stuff like this or e.g. graphs. Why do you need to pull in huge javascript libraries and write code to draw a line chart? Why is drawing a pie chart harder than making a table?
In contrast, I can think of literally 0 websites that could even come up with the most contrived reason to need USB. The best I can think of is some incredibly bespoke CAD thing that uses a hardware dongle for DRM, and then why isn't it just an actual application? Why would the enablement for that go into a web browser? Or the vibration API. Or the sensors API. Who in their right mind would ever want these things to even be possible for websites to use? You know instantly that they will only be abused. Why is WHATWG working on this stuff and not taking common reasons people reach for javascript and adding standardized, declarative versions into HTML?
EDIT: Down voters. What pw hashing algo are you using instead of BCrypt or similair?
That said, a few MB is a lot for one client to post if you have a significant amount of traffic. Just hash client side first.
Actually, the only thing worse, is not being able to paste into the password field(s)... you create a long random password, and now you can't paste it... great.
Except for with me. I find phrases much more difficult to remember and use than passwords, personally. Although in either case, I'll need to have the ones I don't use daily somewhere where I can look them up, because there's no chance I'll remember them.
If you choose each of six words randomly from a list of the 2k most common words with that part of speech, you get 66 bits of entropy, which is slightly more entropy than a random 11 character alphanumeric password with upper and lower case, but vastly easier to remember, type, and say out loud if you need to tell someone.
Think of the words as just a view/rendering of a random bit string. You generate random numbers and then use that to index into your word lists to display those numbers. If you use an injective function for your view, you can choose it to have whatever "nice" (for humans) properties you want (e.g. grammatical validity), and no entropy will be lost (or gained).
[1] https://git.sr.ht/~jamesponddotco/acopw-go/tree/trunk/item/w...
For example, project gutenberg has Moby Word Lists by Grady Ward which is supposedly in the public domain (at least for the USA).
https://www.gutenberg.org/ebooks/3201
https://www.gutenberg.org/files/3201/files/
Last time I looked into it, there were a few different options floating around for word lists.
Although I just use a password manager but to each their own.
Yes, done correctly this is secure.
And yet our infrastructure demands so obscure passwords I keep forgetting them all the time.
So besides being of questionable security benefits, 0bScur3 passwords also bonk that advantage of nice-long-easy-to-remember passwords.
"The specific type of hybrid attack that cracked that password is known as a combinator attack. It combines each word in a dictionary with every other word in the dictionary. Because these attacks are capable of generating a huge number of guesses—the square of the number of words in the dict—crackers often work with smaller word lists or simply terminate a run in progress once things start slowing down. Other times, they combine words from one big dictionary with words from a smaller one. Steube was able to crack "momof3g8kids" because he had "momof3g" in his 111 million dict and "8kids" in a smaller dict.
"The combinator attack got it! It's cool," he said. Then referring to the oft-cited xkcd comic, he added: "This is an answer to the batteryhorsestaple thing.""
The entropy factors I see listed as in the xkcd comic are only valid if the cracking entity is doing a brute force attack. But skilled attacks won't be doing this. There's still nothing that beats a truly random string. But as others pointed out, it's also the most inconvenient to try to manage and remember.