[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. Introduction to password management

This introductory chapter will superficially cover password management issues and describe how this program addresses them.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1 How evil-doers access your accounts

First and foremost, because people give them their credentials (user name and password). Not deliberately, of course. They leave them around or reply to a phishing scam or whatever. There’s nothing providers of security assistance can do about it. That’s the user’s responsibility. Be careful out there. Keep your systems clean of spyware and watch for phishers.

The next most common method is for a site to get “hacked” and the crooks make off with password files. Hopefully, they’ve been hash encoded, but they are sometimes in the clear. If they are hashed, then the crackers will try to reverse the hash and see how far and wide they can use your credentials.

Other possibilities are telescopes, line taps, wireless sniffing and so on. Unless you are a secret agent working on national security matters, these possibilities are not terribly likely possibilities.

The purpose of this software is to render useless, limit the potential damage, or, at least, make it difficult to gain much use out of any information captured. And, also, make it convenient enough to use that it is actually used. A very secure password scheme that is a nuisance to use, won’t be used, and is therefore not very useful.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 How to keep evil-doers at bay

First and foremost, make sure you know which web site you are interacting with when you supply credentials. Do not blindly click an email that looks like one from Pay Pal or your bank. Go to your financial institutions via a bookmark or a well-established link.

Next, use different passwords at different web sites. Unless you restrict yourself to very few web sites, this means you must manage them somehow. Pieces of paper get lost. Password list files can wind up getting compromised. If that happens, your entire online world is now open. Encrypted password list files can get decrypted, yielding the same possibility.

Do not use either words or common transformations of words for passwords. Such techniques severly limit possibilities and constrained possibilities are searched more quickly.

Use long passwords. The longer they are, the more difficult (compute costly) they are to break.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.4 The answers to security questions

Many sites now add security questions that you must answer when you first set up your account. There are several problems with these:

  1. The questions are often common, so if the answers become known from one site, the answers can be used at another.
  2. Some answers can be researched.
  3. Sometimes, you may select an answer that turns out to be difficult to remember or changes for you at some point.
  4. If an answer requires two words, you are often out of luck. “Pick one.”

It’s a mess. gnu-pw-mgr supports a ‘--confirm’ option for answers to confirmation/security questions. Give that option a word or two from the question, and it will print out a 12 character sequence of alphabetic characters that are unique to the web site and unique for the option argument. For example, in the gnu-pw-mgr program’s ‘base.test’ test, the confirmation option arguments dog and pet produce the strings xkzrraogchyh and brrxsbesatfj, respectively. These may be answers to the questions, ‘what was your dog's name’ or ‘what was your favorite pet’, for example. These answers are valid only for the ‘who’ password id and the test’s seed string. With a different password id or seed, you would get a different answer.

NOTE: I have finally figured out that it is inconvenient to have the security question answers change when passwords change. Therefore, this option will, henceforth, print *two* answers. The first will change whenever the password changes. The second will only vary on the input password id and confirmation text.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.5 Sharing a password with someone

Sometimes in a household or with a partnership it becomes necessary to have a common login to some web sites. To accommodate this and to not reveal to your partners how to login to the rest of your world, a new option has been added: --shared. Password seeds will be marked as either being “shared” or not and login ids will also be so marked. The emitted passwords for any login id will only be for those password seeds that match the shared/not-shared setting.

You are expected to transform a domain name into a password id using a method you would share with your partner and not use your personal transformation. To remind yourself that you need to use this alternate password id, you should put a reminder into the --login-id option for the usual domain transform.

FOR EXAMPLE:

Assume you wish to share your ‘nytimes.com’ login. Let’s say your id transformation is to apply “private %s” to your domain names, yielding “private amazon.com” for your normal Amazon login. You should not reveal that to your partner. Instead, you want to use, “shared %s” yielding a password id of “shared nytimes.com”. More likely than not, you will forget. Therefore, do the following:

 
gnu-pw-mgr --tag first --text \
    'She sells sea shells [...] sea shore.'
gnu-pw-mgr --tag xxx --shared --text \
    'Peter Piper picked [...] did Peter Piper pick?'\

gnu-pw-mgr --log 'multi-user' --shared shared nytimes.com
gnu-pw-mgr --log "private vs. shared" private nytimes.com

now when you try the standard transform of ‘nytimes.com’, you get the reminder, “private vs. shared”. e.g.:

 
$ gnu-pw-mgr --status private nytimes.com
password id 'private nytimes.com':
  login-id   private vs. shared
$ gnu-pw-mgr --status shared nytimes.com
password id 'shared nytimes.com' (shared password):
  login-id   multi-user
$ gnu-pw-mgr  private nytimes.com
seed-tag     login id hint: private vs. shared   pw:
first        vpEzyiue8oZwb00v

$ gnu-pw-mgr shared nytimes.com
seed-tag     login id hint: multi-user   pw:
xxx          7VB1er/hzJOlydM1
$ cat ~/.local/gnupwmgr.cfg 

<seed>
  <tag>xxx</tag><ver type=integer>1054726</ver><shared/>
  <text>Peter Piper picked [...] did Peter Piper pick?</text>
</seed>

<seed>
  <tag>first</tag><ver type=integer>1054726</ver>
  <text>She sells sea shells [...] sea shore.</text>
</seed>
<program per_pw_id>
<pwtag id="xWUK3...Pn+p">login-id  = 'multi-user'</pwtag>
<pwtag id="xWUK3...Pn+p">shared</pwtag>
<pwtag id="p5K9i...6tJL">login-id  = 'private vs. shared'</pwtag>

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.6 Keeping track of too many domains

I have been using this program for several years now. I have discovered that it is helpful to purge old clutter that I do not want to keep around any more. But I cannot because I do not know which entries in the configuration file are unused. There is now a new command line option:

 
--domain domain-name

Every time you use --domain example.com, a domain entry will be added or updated with the day count since 1970.

If you choose to use this, I must emphasize very strongly: do not use a password id. The names are stored in plain text. You are expected to use a transform to convert a domain into a password id. That transform should only be known by you and not be stored anywhere (outside your own brain).


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

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