If it is true a few extra characters is as good as having sky-high iterations, the guidance should be on 'forcing' users choose long-enough passwords, not in this nitpicking over the 'right' # of iterations.
The cost scales exponentially with the length of the password, assuming a random password (stops scaling when you reach the hash size I think).
Both are important because you can't freely increase the password length, they become more annoying to enter and remember.
If we choose our password from only ~24 chars then you can get the same effect of 100K iterations form just 4 more characters, or ~1 more dictionary word.
That doesn't seem excessive
Also, teaching users enough of this to do it well is basically impossible. You have to have a threat model that includes your users being fairly shit at passwords. Especially when your product is solving the problem of users being shit at passwords.
The values you see are:
ae1fb1a0b0ee --> ???
f10abddc10a0 --> ???
What you're going to do is start bruteforcing letters until you find the matching passwords. You know that the passwords are hashed with 100k iterations, but you don't know how long the password is.
First you start with a, b, c, d, ... z. That's 26 combinations.
Then you do aa, ab, ac, ad, ... zz. That's another 26^2 (676) combinations.
The next length of aaa, aab, aac, ... zzz is >17k combinations and it keeps increasing exponentially.
Increasing the number of iterations applies a linear multiplier to the time. If it take 26ms to bruteforce all the one character hashes with 1000 iterations, it will take 2600ms with 100,000 iterations.
But increasing the password length adds a multiplier of 26 with each new character (and that's only assuming single case letters). Adding 4 extra letters is actually an improvement of over 450,000x (26^4).
(Assuming you are using the printable ASCII character set, that's actually 95^4 = 81,450,635x)
All those scenarios happen for me every couple of weeks and it's what's keeping me from using really long passwords with high complexity.
Obligatory xkcd: https://xkcd.com/936/
That damn XKCD is overly simplified at best. I really wish people would stop linking to it.
Like, if I go "street bologna drawer sunset fang", did I do well?
Other common methods include appending a particular character to each word or alternate words...creating a pattern of sort, but this again makes it difficult to remember, which was the reason why we preferred passphrases instead of passwords in first place.
In English. Not all books in all languages ever published are "somewhere out there".
I mean, they mostly are or can be. What's the point on relying on "nobody happened to catalog the book I copied my passphrase from"? Are you going to check every week that nobody uploaded it to an archive site?
There's easier schemes that don't rely on that.
It's unlikely it will be done for a lot of languages.
> There's easier schemes that don't rely on that.
Remembering random words is hard. This is how we got into this in the first place.
It's really not. You just make a story out of it. My memory is quite crap, I'm still able to remember the ~3 passphrases I actually need, and I'm able to rotate them as required.
Some things that are obviously good (you can calculate the entropy easily): diceware style schemes, generated with dice or a secure random generator.
Anything in the middle it's quite hard to say. Humans are really bad at being random, so words you pick out of your head I'd be fairly suspicious of. But it's hard to prove it's a bad idea.
From a dictionary/rainbow table perspective I'm curious how they would know to include the following in their lookup tables before going fill number crunching mode:
TO be or NOT two be - that is the question!!!!!!!!!!7872665398
1) the choice of quote. Say that's in the top ten quotes ever, so something like 3 or so bits of entropy.
2) the modifications and additions to the quote. Really depends what the scheme is, but few bits for which words are capitalized (~4), few bits for where the hyphen is (~3), few bits for how many bangs (~4), and a bunch of bits for which number goes on the end, (~30ish). Some bits to account for the scheme itself and its choices too, but I don't know how to put a number on that.
Do you see how little is actually coming from the quote? Your passphrase might as well just be "95!!!!78726653980" and if anything that's _easier_ to remember.
Compare against something like a diceware passphrase. _All_ of the entropy comes from the passphrase part, the part that's easy to remember and trivial to calculate how secure it is.
So a quote is bad because you can _make_ it secure, but you making it secure is just throwing crap at it until it's no longer functionally a quote in any real way. It's secure the same way a blank password is.
Even for badly pw parts which could traced back to me. Let’s say I use my girlfriends name, surname and birthdate. If someone targets me directly, definitely a bad idea. For a random bruteforcer or even a dictionary attack with rockyou.txt, as an example, it wouldn't change a thing.
Or do I miss something here?
Good question. 3 bits is based on the part I mentioned where "to be or not to be" is one of the top 10 quotes. log(10) is about 3. The reasoning for this is that this quote is going to be in a "dictionary" your attacker has. 10 is probably a bit unfair on my part, because an attacker is probably really going to be guessing from a larger pool of quotes, but it ends up not mattering _too_ much. If their pool of quotes is 1000 long, that's more like 10 bits of entropy (still far, far too little on its own).
> Are the cracking algorithms so good that they know to try "or not to be" after they get to "to be". Also, as far as I remember you can't get a "you are partially there" result. Either you get the password or not. So they wouldn't know that "to be" are the first five chars.
Yeah, it's not based on anything like this. Assuming whoever implemented the password input (bitwarden in this case) isn't _maliciously_ incompetent, an attacker would get no information from a partially-correct password guess.
> Even for badly pw parts which could traced back to me. Let’s say I use my girlfriends name, surname and birthdate. If someone targets me directly, definitely a bad idea. For a random bruteforcer or even a dictionary attack with rockyou.txt, as an example, it wouldn't change a thing.
This is not completely wrong, but somewhat incomplete. Names and birthdates/years (or dates in general) are both really common parts of passwords. So an attacker will have a dictionary of common names (or ~all names, there's not that many of us), and every date that's possible to be important to someone.
So that already reduces the entropy a lot. And yeah it's bad enough if someone targets you directly that it's just a horrible idea.
The other problem with schemes like this: if you're using a password of that form, you're probably reusing it multiple places. This allows any site you have an account at to trivially access any _other_ place you have an account at. Really, really bad news.
...and probably how they extend their search patterns.
P.s.: I wouldn't use the pattern in my example... :-)
Expected time to break = 1/2 * 36^L * iterations / (hashes per second your adversary can do)
So you'd want to pick how long you want this to remain secure (~50 years is probably beyond good enough). For hashes, a _very_ conservative choice might be something like the hashes per second done in all of Bitcoin, worldwide. One arbitrary result in Google suggests that that is 286,767,038,956,306,900,000 H/s.
If I did the math right, that works out to 17-18 characters long for 1000 iterations. The number of hashes per second there is obviously way too big, but I'm uncomfortable picking a lower one without doing more research than I'm interested in doing. There's probably a recommendation from some security experts out there somewhere, but I'd imagine it's going to be a bit of a struggle to get one of them to tell you anything except "use more than 1000 iterations".
I would aim for 70 bits (safely north of 64 bits) - the paranoid for 96..128 bits.
[1] 18*log2(36) ~ 93
If you are asking if the length of the password by itself be sufficient to create a secure password, then the answer is mostly no. You need many iterations of the hashing process otherwise brute force attacks become trivial given today's hardware.
What we really care about is how hard it is to determine the passphrase given the hash. With a 128 bit hash, an attacker requires an average of 2^127 guesses if they are guessing completely randomly. So as long as your passphrase is well before the first 2^128 guesses an attacker is likely to make, making it harder to guess is theoretically useful.
For example, "AAAAAAAAAAAAAAAAAAAAAAAAAAA" has more than 128 bits, but it's also going to be (relatively) easy to guess. As shorthand we say "it has less than 128 bits of entropy"
In the example that GP gave, you could advertise "I used 10 diceware words for my passphrase" and it would still be as hard for the attacker as attacking a 128 bit hash. 7 diceware words would be much longer than 128 bits, but if you advertised "I used 7 diceware words" it would give the attacker a significant advantage, since there are much less than 2^128 possibilities.