Disadvantage: If any website you use has it's password database leaked, an attacker can then do an offline brute force attack to recover your master password. Then, the attacker can then generate your password to every other site you use, such as banks and email, just by trying a couple values of n.
My point is that this is dangerous. The security of this method is equal to the strength of you master password + the least secure website you use. If that website has a password breach, the only thing standing between an attacker and a compromise of every website you use is the strength of you master key. (And GPUs are pretty good at brute forcing PBKDF2 - so it has to be really strong.)
This is unlike a stateful password manager. There the security of the system is related to the strength of your password + the strength of the security of the place you store your password db. If you pick a place that is serious about security, your almost certainly better off. Critically, a compromise of some random forum you signed up for doesn't impact the security of your bank account in any way.
> The security of this method is equal to the strength of you master password + the least secure website you use.
Not exactly. It's equal to the strength of your master password only. Even if one of your passwords leaked, this function does not compute fast enough in the forseeable future to brute force your master password, as long as your master password is strong.
> And GPUs are pretty good at brute forcing PBKDF2 - so it has to be really strong.
Interesting, thanks for telling me this. But how much better? I mean, a GPU with 1024 CUDA cores surely cannot surpass 1024 CPUs. So all we need to do is bump up 100000 to a slightly higher number to make it GPU-proof if that's the case, no?
> There the security of the system is related to the strength of your password + the strength of the security of the place you store your password db. If you pick a place that is serious about security, your almost certainly better off.
The problem is that it's difficult to find some places that is serious, and that you trust to be serious. Most people will end up putting it on Dropbox or Google Drive because there isn't anything else that is accessible to them and easy to use on a phone. Also, what if you're on vacation, PC rendered in an unbootable state, and you need to reinstall your OS? This has happened to me at least 3 times.
> Interesting, thanks for telling me this. But how much better? I mean, a GPU with 1024 CUDA cores surely cannot surpass 1024 CPUs. So all we need to do is bump up 100000 to a slightly higher number to make it GPU-proof if that's the case, no?
The weakness of PBKDF2 is that it requires a small fixed amount of memory to run, making it ideal for brute forcing with a GPU. Algorithms like Scrypt / Argon2 are designed to counter this by requiring lots of memory to run. Best reference I could find or current best GPU brute forcing speed is https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... - which seems to say that the test system could do like 100-200k password guesses / sec with PBKDF2-Sha256 @ 100,000 iterations (extrapolating from the numbers given).
I think the idea is that the master password can be memorable enough by picking say 6 random diceware words and still strong enough to resist all (pre-quantum) brute-force attacks for a long time.
The arithmetic then looks like this:
(7776 ^ 6) = 221073919720733357899776, because there are 7776 words in the diceware list.
(7776 ^ 6)/(10^12) = 221073919720 seconds to try all such password if the imagined hardware accelerated hash cracker can do one trillion hashes per second. In years this is:
