My non-approach to password management tools

October 5, 2018

In response to my entry on why I don't set master passwords in programs, Bill asked a good question:

Does your skepticism extend to password-management tools in general? If so, then what do you store passwords in? [...]

There are two answers to this. The first one is that I simply assume that if an attacker compromises my machine, they get essentially everything no matter what I do, so I either record a password in an unencrypted form on the machine or I don't have it on my machine at all. Access to my machine more or less gives you access to my email, and with access to my email you can probably reset all of the passwords that I keep on the machine anyway. In general and in theory, none of these are important passwords.

(In practice, these days I would care a fair bit if I lost control of some of the accounts they're for. But I started doing this back in the days when the only web accounts I had were on places like Slashdot and on vendor sites that insisted that you register for things.)

But that's the anodyne, potentially defensible answer. It's true, as far as it goes, in that I make sure that important, dangerous passwords are never recorded on my machine. But it is not really why I don't have a password manager. The deeper truth is that I've never cared enough to go through the effort of investigating the various alternatives, figuring out which one is trustworthy, competent, has good cryptography, and will be there in ten years, and then putting all of my theoretically unimportant passwords into it. This is the same lack of caring and laziness that had me use unencrypted SSH keypairs for many years until I finally motivated myself to switch over.

(Probably I should motivate myself to start using some encrypted password storage scheme, but my current storage scheme for such nominally unimportant passwords has more than just the password; I also note down all sorts of additional details about the website or registration or whatever, including things like login name, the tagged email address I used for it, and so on. Really I'd want to find a decent app that did a great job of handling encrypted notes.)

I have a long history of such laziness until I'm prodded into finding better solutions, sometimes by writing about my current approaches here and facing up to their flaws. I'll have to see if that happens for this case.

PS: The reason to encrypt passwords at rest even on my machine is the same reason to encrypt my SSH keypairs at rest; it's often a lot easier in practice to read files you're not supposed to have access to than to fully compromise the machine. On the other hand, SSH keypairs are usually in a known or directly findable location, and my collection of password information is not; an attacker would need the ability to hunt around my filesystem.


Comments on this page:

By OscarMcGlynn at 2018-10-05 07:14:17:

The purpose of Password Manager isn't only password storage but also strong password generation without need to memorize them. Without this, you make your own life harder and attacker life easier.

By cks at 2018-10-05 08:50:20:

I already have strong password generation via a program we have sitting around to generate strongly random passwords for new accounts (it uses the basic approach from here, using randomness from /dev/urandom). The current version generates passwords like XwpZ6NJ48ats, which I'm pretty confident are not going to be cracked any time soon, and of course I generate a separate one for each different use (website, vendor registration, etc).

By John Wiersba at 2018-10-05 10:14:44:

I also store my passwords alongside lots of extra related data. My approach is to use a flat file that I edit with vim. The file is kept encrypted and my access is via a script that decrypts it, edits it (swap file and viminfo turned off, etc.), then re-encrypts it if it has changed, and finally cleans up and overwrites the temporary files. There are a few other bells and whistles, but I wish I could find an open source program that used this model of a flat file password manager and got all the encryption/disk-avoidance details right. I also wish vim could read/write to pipes without creating temporary files; I suppose I could use a FIFO or unix domain socket to keep the data from hitting the disk.

A couple extra details: I keep an encrypted RCS archive of all changes to the file, in case something goes wrong and I also use a separate password generator script similar to yours, to generate virtually all my passwords like p+q8ftdR4%_sTVBh.

From 78.58.206.110 at 2018-10-05 10:21:45:

I suspect you'll eventually end up writing your own password-manager-in-disguise, as I've ended up doing myself. Naturally it's the most convenient tool I've used so far... as long as I don't have to use it via SSH on a tiny phone screen.

("Can't find a cross-platform app, I'll just use ~/accounts.txt for now." → "Indentation's a mess, let's write a Python script to reformat it." → "Since it parses the whole thing, might as well add some useful subcommands." → [many days of hacking] → "I've been using it for 8 years, time to implement encryption or something.")

From 78.58.206.110 at 2018-10-05 10:44:20:

@John: You could put the decrypted file on a tmpfs if you happen to run Linux. (Yes, it can get paged out, but so can your text editor.) Overall, your requirements sound rather similar to pass from the creator of WireGuard; it's all-CLI and supports storing free-form data along with the password.

(They also sound somewhat similar to my project, except for the part where it gets anything right at all. But hopefully it'll provide some inspiration.)

By Opk at 2018-10-11 06:24:46:

If you take a strong password generation program that uses random data and point instead to some secret data, you can reproduce the same passwords. Using pwgen for example, you can do:

pwgen -H /path/to/secret\#slashdot 12 1

So passwords are not stored anywhere, either encrypted or in plain text. The secret file needs to be kept secret. By defining zshaddhistory(), I prevent the pwgen command going into shell history. I could also encrypt the secret file, of course. I also keep a text file to record the tag, e-mails, and other notes like whether I gave them a fake date of birth and whether I had to roll over to the second password.

@Opk: I’m afraid I have bad news.

You are not storing the password anywhere, but you are storing a value from which the password can be derived (using a particular pseudo-random number generator). With encrypted password storage, the password is also not stored anywhere – only a value from which the password can be derived (using a specific decryption algorithm).

However, with encrypted storage you cannot derive the password from just the stored value – you also need the decryption key, which (hopefully!) isn’t stored anywhere. (Nor is any other value stored anywhere from which the decryption key can be derived. (Again – hopefully.)) This is ultimately what creates security: the data is incomplete somehow.

The security of your approach instead relies entirely on an attacker not knowing where you store the value from which your password is derived, and not knowing how you derive the password from it. This is known as security by obscurity.

In fact, as you are apparently using an off-the-shelf password generator (and have now publicly disclosed that this is what you are doing…), you are not even relying on secrecy of the algorithm. Your security rests entirely on the secrecy of your password storage location.

Bottom line: your approach is only marginally better than just storing a base64-encoded version of the password.

Sorry.

By Opk at 2018-10-13 19:11:21:

@Aristotle Pagaltzis: I'm aware of the security limitation of my approach and as I mentioned, I could encrypt the secret file taking away the obscurity element. However, I tend to think that if someone has got in a position to get hold of my secret file, I've got bigger problems anyway because they're likely on my system and have access to my e-mail and can reset my passwords anyway. But the approach has advantages: the secret is a static unchanging file so an old backup is as good as a new one if I ever lost my disks. This would also mean no syncing is needed if I had a laptop or whatever to which I wanted to sync the password database to. I also like the security by obscurity element that there is often no trace that I even have an account on a particular site.

In short, “I just save my passwords in a file in an unusual filesystem location and then keep its existence secret by keeping it out of my shell history”. Sure, you can do that. I am saying only that using pwgen does not change the fact that this is all you’re doing.

Written on 05 October 2018.
« Thinking about what we want to be alerted about
Go basically never frees heap memory back to the operating system »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Oct 5 01:37:46 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.