I would second this request. This came up before, and the answer was that scrypt is strong enough to protect user from brute-forcing the master password if one of the generated passwords is leaked.
Well, the master password is a key to all passwords, and cracking it has enormous benefits, especially if account is of highly valuable and targeted individual. Modern cracking rigs are superior to the ones of yesterday, and the race is on to future-proof the PBKDF strength. Besides, no matter how many times you'll tell users to generate a random strong master password, they will still find shortcuts, and you will be subject to dictionary attacks and rule-based cracking.
One of the solutions that many modern password managers use is to add a second pre-shared high entropy secret to the master password. Take a look at 1Password whitepaper, for example: https://1password.com/files/1Password%20for%20Teams%20White%20Paper.pdf Such pre-shared key can be stored in iCloud, TPM, etc, where it's not easy to steal it.
Good news is, the change to master password algorithm to include such key is not very large: currently, MPA uses user name to generate salt for scrypt, and treats that name as part of public metadata. Instead, salt can be created from a secret pre-shared key. This would improve security of the algorithm and dramatically increase algorithm's resistance to brute-forcing and dictionary attacks.
Such a salt essentially renders the primarily purpose of Master Password moot. You now need a vault to store your PSK in. Lose your vault, you lose everything and have no way to recover.
Finally, note that this is not related to 2-factor authentication. Multi-factor authentication does not mean having multiple secrets. It means having multiple independent and unrelated authentication factors that work together to enable authentication. You cannot have multiple secret values. You could have one secret + one biometric test, or one secret + one proof of ownership, etc. Regardless, the discussion is actually irrelevant here since Master Password never actually performs any authentication. It is a calculator, not a gateway. There is just no way that 2-factor authentication can be made relevant to its algorithm.
Maarten, you are absolutely correct that Authentication is not a right word here - MPA is a calculator and it doesn't perform authentication. I am not sure why you are so strong about not having multiple secret inputs for your calculator.
If, for example, you store your second pre-shared secret in TPM/iCloud, you can unlock access to it by requiring a TMP login via biometric or Windows Hello authentication, or with fingerprint in iCloud/iPhone case. MasterPassword for iPhone uses iCloud to store :gasp: master password, so you are not completely opposed to storing stuff in cloud, right?
Another way of foiling a brute force attack was discussed at DefCon this year and requires offline HMAC with secret on a generated key. This prevents brute-forcing by throttling requests by user: https://www.usenix.org/node/190917 But this requires a major change in the algorithm and online access to generate password.
There are two main reasons for the second secret:
1) Users come up with lousy first secret (master password).
2) First secret can be leaked (accidentally used it as password somewhere, told to someone, etc.)
The relevance of this in the context of the Master Password algorithm has not been demonstrated.
The main point of Master Password is that the secret is memorable. As soon as you introduce secrets which are not memorable, you lose all the advantages you get from having exclusively memorable secrets. When you give up on those advantages, there is no longer any point in using the MP algorithm. You would be better off embracing the vault that you need (whether it exists on iCloud or elsewhere), and go full encryption on everything. You'll have better protection that way with fewer points of attack. It so happens that I'm just not willing to give up on those advantages.
The Master Password advantages emerge from the fact that you are independent from any state, device, hardware, software, storage provider or medium. If you are willing to give up on that, that is perfectly fine. But I don't see why you're then still generating passwords and deriving your key through a username+password scrypt pass. This is now a pointless operation.
Again, I don't disagree that PSKs are useful. I simply disagree with the fact that they are useful in MP, since they break the use case of MP and their necessity has certainly not been demonstrated. Use them by all means, but use them properly: drop the mpw algorithm.