Is it truly possible to store passwords securely, but be able to see the password?

Question

Every place I looked, people recommended that storing passwords via encryption is like storing passwords in plain text. But every place I've looked, everyone recommends using a password manager like KeePass.

I guess the real question I'm asking is how is KeePass or other password managers more secure than storing them in plain text?

The only reason I'm asking is that I'm planning on building a home server. I would like to eventually implement an online password manager that would send passwords through HTTPS to multiple devices. This is probably going to be solely for shits and giggles. I'm not trusting my crappy coding on all of my passwords. But it still interests me on how KeePass was able to do it.

Answer 1

Context is everything.

storing passwords via encryption is like storing passwords in plain text.

This advice is about client programs implementing a faux password manager that stores password to access online service in encrypted format so you don't have to type the password to access that service at all. This kind of encryption is moot because to allow zero password login, the decrypting key for the password manager itself must be stored along side the encrypted password itself, this gives you no more security than just storing it plain text.

A proper password manager, on the other hand, encrypts your password using a master password (or more commonly, the master password encrypts the master key used to encrypt your data). This is secure because you can't unlock the password manager without the master password. This does mean that you must type the master password every time the password manager throws away the decryption key (e.g. definitely over reboot and when the password manager process is killed and depending on settings, possibly over hibernation, suspend/sleep, or screen off).

Answer 2

There are a few different things to consider here.

1. Managing passwords for web applications and authentication purposes

You mention that people are saying that "storing passwords via encryption is like storing passwords in plain text". I think that what they mean (although I have no idea who 'they' are) is that storing passwords in a database for website authentication purposes is a horrible idea even if they are encrypted. I'd agree with that.

Having even an encrypted copy of people's passwords is a horrible idea for any website because it presents a lovely target. Instead, what you should do is implement a one-way hashing algorithm that takes my password - "awfulpassword" and consistently turns it into the same random gibberish like "DF5A FL23 IA92 76S4 0K7S". That way you have a list of strings like the one in quotes and no passwords to speak of. And because hashes are like making sausage you can never get the password from the ground beef. You can however consistently take an input and check it against a hash. If you want to implement this you should also lookup Salts which add a good deal of security too.

2. Managing passwords for personal use

Any decent password manager is a great deal more secure than plan text storage of passwords. If they're worth their salt they require a password to decrypt, and sometimes a keyfile or other verification to unlock. Which makes it very difficult to steal your passwords if you pick a good key. The concerns about malware are legitimate but if you're got key logging malware you'll probably be screwed to the same degree as if someone miraculously managed to crack your encryption. TLDR: Use a password manager. There are lots of other benefits too.

On the home server note If you don't trust your code for a home server that is a password manager why not just buy a USB and install a password manager on the USB. You can copy your password file to it and roll around with all your passwords easily accessible in the encrypted USB. You also don't really have to worry about losing it with a strong password because it is encrypted. Yay!

Try keepass out before you build your own faulty server please!

Answer 3

There are two things that affect any security generally:

1. What do you have to do.
2. What do attackers have to do to overcome your security.

The second is the most obvious; the easier it is for attackers to "break" the security, the less secure you are. The first though is also important; if your security prevents you doing what you have the system for, then it's pointless but this is often a contrary pressure because you can't shut down a possible use of the system to protect it if doing so makes it pointless.

Now, let's look at two password storage scenarios:

1. Passwords are stored on a server so that users can be authenticated.
2. Passwords are stored so that the user can make use of them.

These two scenarios are different by both criteria:

"What do you have to do."

In the first scenario, there is no need for the password itself to be retrieved; we only need to be able to establish that a password pass to us on log-in matches it.

In the seconds scenario, we need to be able to retrieve the actual password itself.

"What do attackers have to do to overcome your security."

With reversible master-password-based encryption, attackers have to obtain the password store and either break the encryption or obtain the master password.

If the decryption itself is being done on the same server as the password checking, then in any case where attackers have gained access to the password file they are also quite likely to have gained access to wherever the master password is being stored and while that might e.g. require decompiling some code or something, they have all they need to read the passwords.

If the decryption is being done based on the user knowing the master password, then obtaining the password store does not make you any more likely to have obtained the master password, because that is only in the user's memory.

As such, encrypting passwords for the sort of uses KeePass and other stores (PasswordSafe, LastPass, etc.) are intended for is both not providing more functionality than is actually needed (unlike for verification, where retrieving the password itself is pointless) and not as weak.

They can also have greater security again by not having the computers that have a copy of the store operating as 24/7 servers where they can be attacked at a known location 24/7, though that part goes away if you use cloud storage or a repository to store the password store.

KeePass is certainly less secure than having none of the passwords stored anywhere, but almost nobody is capable of storing reasonable passwords like d@[email protected],xve1Q+W.CkocPL/,XWbky each separate service.

Having an encrypted store of passwords for such use is a reduction in security that brings with it functionality that allows us to avoid greater reductions in security.

Having an encrypted store of passwords on a server for verifying log-ins is a much greater reduction in security (because we have to be less secure with the key's storage too) that allows no increase in functionality, except for some things that are in themselves a very bad idea (telling users their passwords).