Is there a password manager that combines a "master password" solution with a keystore solution?

Question

There are many posts online debating the merits of "master password" or "deterministic, site-specific" password generation tools.

The general idea is that a function hash("my_master_password", "facebook.com") could deterministically give you the password for your account at any website.

Benefits:

• Avoids a keystore like Keepass or LastPass which have their own risks inherent to password storage

• Still provides unique password per website account

Drawbacks:

• Can't update your password on a specific site

• If someone discovers your master password then they have your password for all accounts

Is there a password manager that combines this idea with a keystore solution to address these drawbacks?

It would effectively mean a password generation function hash("my_master_password", "facebook.com", "facebook.com_password_from_keystore")

my_master_password would not be stored anywhere, so you must memorize it or store outside the system. The keystore would have separate login key keystore_password in order to fetch the remaining arguments facebook.com and facebook.com_password_from_keystore.

Benefits:

• If keystore is compromised there is still no way for attacker to discover "my_master_password" so you have more time to reset your passwords once attack is discovered

• Cycle passwords by generating new random value for facebook.com_password_from_keystore

I would consider using a product like this because I like that there is information in the scheme that is never stored in or sent to a keystore. What are some additional drawbacks?

Additional Context: I don't think I really understand why solutions like LastPass or KeePass are trusted as much as they seem to be. I see how they are a great solution for the problem of password uniqueness and complexity, but there have been breaches on LastPass and other popular file storage solutions that may be common for storing KeePass files.

Answer 1

Original question

With only one master password, for both the final hash and the key store.

Your scheme adds no additional security on top of what standard password managers already offer.

So lets say that the password file from your password manager is leaked. Generally, these are encrypted using a key that is derived from the master password. So an attacker will need to crack the master password to get your site specific passwords.

If your master password and the key stretching algorithm are both good, that is a tall order. But for the sake of argument, lets say that the attacker succeeds. She then knows (a) the master password, and (b) all your site specific passwords. Nothing is stopping her from just calculating the hash you proposed.

An attack on your scheme would work exactly like an attack on say LastPass, with the addition of the calculation one simple hash at the end.

Updated question

With different master passwords for the final hash and the keystore.

You are using two passwords here. The relevant benchmark to compare against is using a normal password manager with one password that is as long as the two passwords combined.

You can argue if this is a security benefit or not. To gain access to all your passwords, an attacker needs to brute force first the keystore password and then the password for the final hash. To do the latter, the attacker would need one correct password that is in the keystore to compare the results against.

If the attacker have no such password, then your system is better.

If the attacker have such a password, a normal password manager is better. Brute forcing two passwords of length n/2 is sooooo much easier than brute forcing one password of length n.

So my recommendation would still be to use a normal password manager with a strong password. If you use a strong password, an attacker will be chanseless anyway.

Answer 2

You say you cannot trust a password manager because of the risks inherent to password storage. But I cannot really understand where is the improvement with your solutions:

1. Confidentiality:

   A password manager normally depends on something you have (an encrypted file) and something you know (a master password). Assuming you use a correct master password and a well implemented password manager, the security of the encrypted file at rest is assumed acceptable, and you can improve that by using local storage for the file if you are not that confident in your master password. The main vulnerability if that when you use it an attacker could read into the process memory to extract the decrypted database or what is the same the symetric key used for encryption - but that assumes that the system where you use if has been compromised.

   In your system, you still have a password manager, so same attack is possible, and you just add something you know (your master password). If your system is compromised, it can be intercepted too either with a keylogger or by reading process memory. In addition, as it is common to all site passwords, you will not easily change it, so it is really vulnerable to eavesdropping.

2. Integrity:

   You system depends on a password manager, so you cannot have any improvement here: if the password vault is modified you end with a no longer useable tool, and have to implement the same a way to identify unwanted changes

3. Availability:

   Your system depends on a password manager, so you should have a backup of the vault. You can argue that as you have an additional master password, your system is not vulnerable to a compromission of that backup.

   IMHO that is not a good practice, because the master password is only something you know and that is unlikely to change because you would have to change all of your passwords. So you are about to lower the defense on the something you have part because you think that you have enhanced the something you know part, while IMHO you have not.

TL/DR: Your algorithm is unlikely to be adopted by a major password manager application because it really adds little security if any. And as in security implementation details are where vulnerabilities hide, I strongly urge you no to roll your own. You should rather think again on what are the risks inherent to password storage and wonder how you can mitigate them.

Answer 3

With a password manager, which chooses site passwords at random and stores them in an encrypted file:

• An attacker who steals an individual site password randomly generated by the manager cannot thereby learn anything else, because it's a random password, uncorrelated to anything else. Since many sites practice insecure password storage (and defending against that is in fact one of the major motives for using a password management solution!), this is a really good safeguard to have.
• An attacker who steals a copy of the encrypted password vault needs at least to guess your master password to make any use of it. (With some password managers you also need to steal a cryptographic key stored separately from the vault; typically the point of this is that the encrypted vault may be uploaded to the cloud, but the security key never leaves the devices.)
• An attacker who gets a hold of your encrypted password file, master password and any other required keys will inevitably access to all of your passwords.

With the "hash a master password" approach, on the other hand:

• An attacker who steals an individual site password and nothing else can use it to launch a password cracking attack against your master password. This is because site_password = hash(master_password, site_metadata), and site_metadata is a low-entropy value that admits of the same guessing attacks as passwords do. Since many sites practice insecure password storage, this is very worrisome.
• An attacker who guesses your master password doesn't need to steal a password vault file to launch a guessing attack on your site_metadata, which gives them good chances to discover your site passwords.
• Some master password hash proponents also propose the use of a secret key as an argument to the hash, or of storing the site_metadata in files so the user doesn't have to (mis)remember it, etc. If you do any of that, then no less than the encrypted vault approach you've then created a file that the attacker could steal to aid their effort.

The advantage that master password hash proponents most often claim for their approach is that there is no encrypted password vault to steal. But the problem with this claim is that, this is actually a disadvantage—if there isn't such a file, that means that the passwords must be recoverable without such a file, from data that a user can memorize. Therefore an attacker might be able to attack the scheme without stealing any files at all. Master password hashing is strictly worse than encrypted vaults.