Is this idea for a password manager secure? If so, why doesn't anybody use it?

Question

I've been thinking of a problem with usual password managers: although they do provide better security than manually using passwords, there's a central database that can get lost, get compromised, etc. For example, malware could use a keylogger to get your master password and then compromise all the passwords in the password file. Cloud-based solutions also raise the privacy issue of the cloud service knowing when exactly you access your passwords. And there's always the possibility that the cloud service keeps around an unencrypted copy of all your information. Or somebody bribes LastPass's developers with a million dollars to have LastPass send everything to the attacker, or something. More realistically, password managers seem to decrease security in the event of a targeted attack.

I've had a random idea to have a stateless password manager that would basically operate by hashing together a username, the website domain (or some user-chosen site identifier), and the master password to generate the password for each account the user has. In this way, there's no database to be kept around, and it's possible for users to use their passwords on, e.g. public computers by, say, manually computing the hash using some online JavaScript hashing tool.

This sounds pretty secure, but it also sounds pretty obvious, and usually if an obvious idea isn't a thing it's because there's some pitfall. Is there? Why don't password managers do this instead of storing everything in a big file?

Answer 1

One problem with this kind of solution where a predictable algorithm is used to generate a secret from a master password/phrase, is that if your master password is compromised directly (e.g. keylogger) or indirectly (e.g. an attacker with a password of yours generated through this system who can carry out a brute-force attack on it), the attacker has effectively compromised the security of all of your accounts, as they would be able to easily generate the passwords you use for all sites.

Answer 2

In short, this method provides little to no additional security over a regular password manager (possibly even reducing security, depending on implementation), and has several usability issues that make it impractical.

Security

Let's take your example of malware using a keylogger to get your master password and then compromising all the passwords in your password file. Your proposed scheme provides no additional protections against that attack: if your master password is stolen through a keylogger, then the attacker has all your passwords for all services. (No need to even steal a database here, just the master password.)

Another threat you mentioned was the developers of your password manager compromising your security by updating their password manager to steal your master password or decrypted password database. This threat is not mitigated by your scheme either, as the developers of the program you use to generate your password hashes could do the same. (I'm assuming you're not writing your own hashing tool. That seems nearly as inconvenient and error-prone as writing your own password manager.)

You also mentioned the privacy issues of cloud-based password managers knowing when you access your passwords. While this threat is mitigated by your proposed scheme, it can also be mitigated with traditional password managers by always keeping a copy of the password database synced to each local device and referencing that file when looking up passwords, or by simply storing your password database completely offline. KeePass, for example, supports both of these methods.

Finally, there is one additional threat this scheme opens you up to. It allows any site that you sign up for, or any attacker who obtains the password database for such a site, to make an unlimited number of offline brute force attempts against your master password. This can be mitigated by using a strong master password and a slow hashing algorithm, but it is still a problem worth considering. You could also mitigate it by including a pepper as part of your hashing algorithm, but then you lose the main benefit of your proposed scheme by requiring the user to access a file containing the pepper to obtain their passwords.

Usability

As for usability, as you noted this scheme does have the benefit of not requiring the user to keep track of a password database. However, there are a few usability issues I see with this scheme that I believe greatly outweigh this advantage.

The first is that if your password for a specific service is compromised (e.g. a site stored their passwords in plaintext and has their database stolen, or the password is stolen in-transit through a man in the middle attack), you have no easy way to change the password for that service without changing the passwords for all your other accounts as well (e.g. by changing the master password). You could add an additional parameter to the hash generator, such as an incrementing number, to allow passwords to be changed, but then you have to remember this number for every service, which is rather inconvenient.

Similarly, if for whatever reason your master password is compromised, this scheme makes changing that password rather difficult, as not only do you have to change your password on every site you have an account on, but you also have to remember every site you have an account on to make sure you don't miss any when changing your passwords - there's no convenient listing of all those sites as with a password manager.

Another usability issue which is a bit less obvious but, from my experience with password managers, I believe this scheme might run into, is that it's not always apparent what the "name" of each site you're visiting is. You might think you can just plug the domain name of each site into your hash algorithm and use that as the site name, but that's actually not always the case. As a simple example, consider this very site, Information Security Stack Exchange. Assuming you choose to use a password-based login for this site and not federated login through a third party like Google or Facebook, what do you use for the site name in your scheme? security.stackexchange.com? stackexchange.com? stackoverflow.com? All of those domains use the same login. And once you choose which name to use, you have to remember it. Other sites can make this even less obvious, such as, for example, gamepedia.com, which requires that you log in with your "Curse Community" account, which is shared between multiple sites made by that company.

And finally, possibly the most significant usability issue with this scheme, is sites with restrictive password requirements. What if one site requires that your password contain a special character, while another site requires that you only use alphanumeric characters? You could add options to your hashing scheme to accomodate these requirements, but now you have to memorize and remember the password requirements of each site whenever you want to sign in.

TL;DR

While your proposed method does solve some problems, it also creates others, and doesn't provide any additional security.

Security:

• N/A: Doesn't protect against malware
• N/A: Doesn't protect against malicious developers of password management software
• N/A: Doesn't provide any privacy protections that existing password managers cannot
• Con: Exposes master password to brute force attacks from malicious sites and hackers

Usability:

• Pro: Frees the user from having to manage a password database file
• Con: Changing site-specific passwords requires remembering additional site-specific information
• Con: Changing the master password is inconvenient
• Con: It's not always obvious what site name to use as the input for the hash function
• Con: Managing sites with restrictive password requirements is very difficult

Answer 3

What you're thinking of has been done quite a few times already.

Here's an example: http://plevyak.com/dpg.html

It's called a Deterministic Password Generator, meaning it creates passwords based on other information that you enter. Just like you said, using your master password, some other information, and the name of the site.

Answer 4

Couple points about the question, too long for a comment, some stuff has already been mentioned separately:

• has been done lots of times, there are tools available
• from one leaked password the other passwords could in theory be compromised if someone guesses how and what you are hashing to get the passwords and then uses brute-force. Still much better than reusing passwords.
• if the master password (plus salt and hashing algorithms and whatever you set up) is contaminated, the the attacker doesn't just know your current passwords, but even ones you are going to set up in the future
• you can't easily change one single password. This seems to be the biggest usage drawback to me
• because of stupid password rules, sometimes you can't use the generated password. You can almost always get around this by generating multiple passwords according to different rules (say a 20-char alphanumeric and a 20-char ascii printable character password, and then use the maximum length and complexity which a website supports), but this is annoying because then sometimes you need multiple tries to get your own passwords right.

All in all, I think it's probably inferior to password databases for practical reasons but with similar security.

If you want to improve the security of password managers, I suggest you use a hardware based one. Probably those exist. Before building or buying one also consider just using a traditional notebook, it's pretty secure against any kind of hacker attack...

Answer 5

Look at SQRL for a system that replaces a "password manager" with somethings that works without needing a central DB and can defeat the keyloggers as well. The web servers that you visit will not require secret state about you (like a password) with this system. The id that is provided to each website is unique for each website, so an id token from one site will not work with another.

The best "password manager" would be a system that doesn't require saving a bunch of hashes around the Internet.