1.3 How gnu-pw-mgr helps

Passwords must be long, not based on dictionary words, never repeated, and not recorded where they can be gotten at. You can’t do it by memory.

This program addresses the recording problem by not recording passwords. They get re-computed every time, based on two separate factors each of which is unlikely to come into the hands of miscreants. The first factor is a series of one or more password “seeds” or “salts”. You specify a tag for it and the seed itself is a block of text that contains at least 64 characters. The second factor is a transformation of the web site address. That transformation should be easy to remember, fairly easy to type, include odd capitalization, use multiple unusual punctuation characters, have a secret word or two and never, ever be written down.

The text, the URL transform and the tag get hashed together to construct the password. Since different web sites have different password requirements and allowances, the result is trimmed and tweaked until it meets the requirements. It is always possible that new requirements might pop up, and the password polishing code has been written to be extensible.

Using this program not only makes it simple to have different passwords for different web sites, it actually makes it inconvenient to use the same password. It does not support the same password, so you would have to remember the jumble of letters and numbers for any alternate web site. You won’t do that.

gnu-pw-mgr works by storing the seed in a private configuration file and obtaining the password identifier either from the command line or by reading it from standard input. This configuration file must be secured from reading and writing by other users, but obtaining access will not reveal passwords. The key to this is the password identifier. It is the second factor in the authentication (password re-creation) that is never recorded.

The configuration file does not need to be super secret. What needs to be super secret is the transformation used for constructing password identifiers. That transform includes a prefix, a suffix, alternate capitalizations and a variety of word separators. For example, you could prefix every domain name with “access” and suffix it with “por-favor”, then use an unusual spelling of the domain, perhaps “ExAmplE.moC”. This yields a password id of “access/ExAmplE+moC=por-favor”. You can remember that fairly easily. If a bad actor gets your seed file, they won’t work out the transform any time soon.

On the other hand, if someone does happen to see you create the transform, it will still do no good, unless they also get the second factor: the seed file. This is true even if they also get one password. There is no way to derive the seed file from the password id and the resulting password. It is a one way hash function. It is not an encryption.

Every site has their own set of attributes that make for acceptable passwords, so the hash of the inputs must be modified. The hash of the password id by itself is used as a key to look up any previously established password constraints (see section password options). These password attributes are length, character types required and/or prohibited from being in the password and some hint about your login name or id. That name need not be exactly your login name, just something that will remind you about which one you use for the site. It may be omitted, if you are sure you can remember.

These site specific options are then used to constrain the alphabet used to construct the password.

This document was generated by Bruce Korb on June 30, 2018 using texi2html 1.82.