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.
Exactly, using phrases is so much nicer and better in every way.
It annoys me when sites demand a password should have a special character or upper case letter in it. Or even worse: a max length.
I remember my annoyance when I banked with Wells Fargo and they had a maximum password length of something like 12 or 16 characters. Later I found out they would lowercase the password before sending it to the server.
What should this limit be?
Personally, I think the limit should be nothing smaller than a thousand characters. Or even allowing something like a hundred characters or more would be better.
I remember at some point Hotmail had a maximum length limit of sixteen characters.
Realistically speaking, the hash would be your smallest problem if you're being DDoSed.
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.
Yes but that's not what they're discussing, it's about the sites that have some low limit like 8-16 characters.
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.
Interconnected old mainframe systems fwiw... In the end, a lot of these banking systems are connected back to mainframe systems with a LOT of legacy cruft that nobody has the nerve to actually update. It may not even be hashed or encrypted, which is part of why banks also add a second factor/cookie, though the implementation could/should be better.
The sensible thing to do here is hash the password before sending it, not impose a character limit on the field. Ideally, browsers could even support this directly as part of the input element if they weren't busy adding things no sane person wants like webUSB or browser notifications.
You can do hashing in javascript, but I mean something more like
<input type="password" hash="sha-256" />
By default, salt with the domain. Have an optional `hash-domain` attribute to override it if needed. Have an optional hash-extra-salt field that you can use to target e.g. a username input. Make it quick and easy to do the right thing, and for a linter to check that you did the right thing (e.g. warn if a password input is missing hash options).
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?
I wrote an authentication platform a few years ago... I had a setting to allow a max passphrase length (because it was a govt requirement for a client), but if unset, it would be 1024 as a pragmatic limit on the payload (considering the hash length was less), I always thought that was reasonable.
I'm not particularly familiar with this stuff, but aren't the cost factors for hash algorithms essentially the number of times to nest the hash function? i.e. `hash(hash(hash(hash(hash(input)))))` type of thing. So it would cost more, but only for the first round? After that the size is reduced to the size of the image of the hash for future rounds?
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.
My password manager is generally set to 30 random characters with all options. Max lengths bug the crap out of me, or limited character options... I mean, just use utf8 + normalization before hashing. Min-length should be the only requirement (if that). If I want to write in morse-code using dots and dashes, let me (I don't but had a friend that used to do that).
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.
> using phrases is so much nicer and better in every way.
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.
Your example is misleading; “touch-some-grass” is hardly random. “horse-battery-staple-correct" is presumably randomly chosen, and is therefore a better example phrase.
Yep, lazy example, but even grammatically correct sentences are a lot. The idea though is for the passphrase to be something invoking a distinct image for the owner and I'm coming from a vacation. :)
It's 100% safe from dictionary attacks. You can even make it grammatically correct. Just choose something like adjective-noun-adverb-transitive_verb-adjective-noun.
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).
For anyone looking for a dictionary for diceware passwords (or passphrases, or whatever you call them), I have one available over here[1] with over 23000 words with a minimum of 3 characters.
You can just append whatever character requirements they have. So instead of "correcthorsebatterystaple", you can do "CorrectHorseBatteryStaple123!". Should meet most requirements.
Although I just use a password manager but to each their own.
But with transformer models it would probably be trivial to predict the top 10 next words if your passphrase is grammatically correct. Interesting password cracker idea …
Done correctly, you choose words (uniformly) randomly from some dictionary, so the best a model can do is predict that all words from the dictionary are equally likely. All a model does is approximate probabilitly distributions, but the distribution isn't a secret; it's uniform. The dictionary doesn't need to be a secret either. The strength comes from the dictionary size and number of words.
Yeah, streaming accounts are probably the only ones in my password manager that aren't randomly generated for that reason. "Gimme movies now!" (not my actual passphrase)
"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.
The xkcd method is a truly random string with 44 bits in the example (4 words each chosen from a 2k dictionary). There is no better way to crack it than brute force. The words are just a rendering of a 44 bit random number. You could also render it as 44 digit binary number or an 11 digit decimal number or as an 8 digit base 64 string. It doesn't matter; it's still a 44 bit number and requires exactly as much work to crack.
