7 ms·
The number of iterations scales linearly with the cost of brute-forcing. The cost scales exponentially with the length of the password, assuming a random passw
by kadoban 4y ago
The number of iterations scales linearly with the cost of brute-forcing.
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.
- avsteele 4y agoIf your first two statements are correct I can't see how the third can't be. 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
- TylerE 4y ago10ms (or whatever) of computer time is a lot cheaper than 2 seconds of mine
- kadoban 4y agoIncreasing the iterations is basically free (up to the point where it requires human-noticable amounts of time to calculate), so there's no need to require 4 more characters. 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.
- KMnO4 4y agoImagine you're an adversary, and you've just stolen a list of hashed 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)
- mackatap 4y agoI never enter or remember any of the passwords bitwarden generates for me, I have an app and an extension for that.
- maxyurk 4y agoit's about the master password
- NoahKAndrews 4y agoThis is about the password you use to log into BitWarden itself.
- wkat4242 4y agoBut what if you need to enter it somewhere that doesn't support it? A physical device, a VM that doesn't allow copy and paste, a mobile app without support for copy/paste or password managers... 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.
- pjot 4y agoUsing a passphrase is the way to go. Easy to type, remember, and more secure. Obligatory xkcd: https://xkcd.com/936/ https://xkcd.com/936/
- jim02672 4y agoYou're assuming that a) a passphrase is acceptable to the system/app and b) that people can competently pick words for a passphrase. That damn XKCD is overly simplified at best. I really wish people would stop linking to it.
- Toutouxc 4y agoPlease elaborate, how can you pick bad words for a passphrase? (Except obviously a movie title or an everyday sentence) Like, if I go "street bologna drawer sunset fang", did I do well?
- hanniabu 4y agoWhat alphanumeric password length would be sufficient enough to still be protected with only 1000 or 5000 iterations?
- kadoban 4y agoI don't have great values for the constants, and it's a bit of a question of who your expected adversary is, but assuming a randomly generated alphanumeric password, the equation should be something like: 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".
- e12e 4y ago18 random characters out of 36 is equivalent to ~93 bits of entropy[1]- that's pretty conservative indeed. I would aim for 70 bits (safely north of 64 bits) - the paranoid for 96..128 bits. [1] 18*log2(36) ~ 93
- kadoban 4y agoYeah that sounds safe, I did end up even more paranoid than I intended.