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?

closed as primarily opinion-based by M'vy, Iszi, D.W., Scott Pack, Mark Jul 17 '15 at 2:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 22 down vote accepted

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.

  • 1
    I've written a (very simple) tool to generate such passwords for me. It uses salting and multiple rounds of several hashing algorithms to make it harder to go from a password back to the master. – Nobody Jul 16 '15 at 16:26
  • 3
    Of course salting would help, but it removes the benefit that was referred to in the Question where if the person went to a public computer they would be able to calculate their password just knowing their master password – Rоry McCune Jul 16 '15 at 16:28
  • @Nobody Salting? You mean peppering? Otherwise, where are the salts stored for each account? Wouldn't you still need a database? – Ajedi32 Jul 16 '15 at 16:38
  • Not sure which term is right, peppering in the sense that it's only one for all generated password, salting in the sense that it's against precomputed hash tables, not as an additional secret. @Rory McCune is right. – Nobody Jul 16 '15 at 17:02

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
  • 1
    Agreed, but an additional detail — some password managers like this allow you to set (and force you to remember) a counter of some sort, so you can generate a new password for an existing service by incrementing a number. – Joel L Jul 16 '15 at 20:43

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.

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...

  • 1
    "from a leaked password you could compromise all the others" this could easily be defeated by allowing the user to setup some generation parameters. Yes now the user would not only have to remember the master password but also some config parameters, but at least it would be almost impossible to break the other passwords from a leak because the algorithm would not be enough, you'd also need the generation parameters. – gaborous Jul 16 '15 at 17:00
  • 2
    stuff like selecting different algorithms or chaining them in different ways? that's what I meant with "how and what you are hashing" I just tried to keep it more general because I'm sure there are other things you could vary and I'm not sure chaining is really a good idea, that's just what came to my mind. – Nobody Jul 16 '15 at 17:09

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.

  • 2
    SQRL isn't a password manager; it's an alternative authentication mechanism based on asymmetric cryptography that does away with passwords entirely. – Ajedi32 Jul 17 '15 at 13:14
  • Yes, SQRL is not a a password manager. But given the system that the OP was suggesting, I'd suggest that SQRL is the logical result of thinking his idea fully through. If you are worried about having your password stolen from your local system, you should also be worried about having it stolen from the remote system. SQRL solves both problems. He asked for why people were not using an idea like his and were there isssues he didn't see. This was an idea in that path. – Walter Jul 18 '15 at 17:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.