Hi -
Just saw a few informative posts about this, and especially enjoyed one by
James [log in to unmask] - thank you.
Mark [log in to unmask] also mentioned lastpass.com for password
storage. Interesting.
I'm retired now, but for 10+ years I've been using a software package called
Gorilla - hosted these days at https://github.com/zdia/gorilla {note the
https connection}.
It's a small program that works under *ix or Windows, and can live on a USB
drive containing the software and password database.
Data is stored in a tree, with URL, user name, password and notes for each
entry. The database is protected by a password, and the software takes quite
a few steps to protect the contents.
The HELP file is worth reading, even if you don't care for the software. For
example, when properly configured, they suggest when you change a password
on a web site, change Gorilla first. The new database is saved first, then
the web site is changed using the new Gorilla value. If "bad things" happen
in the process, the Gorilla backup has the old password.
(No, I don't plug the USB into an alien machine. I carry a "dump" of the
Gorilla data on my Palm widget, which is password protected. But you could
if you wanted.}
I have several domains, so I also have many email addresses available. I
could, for example, have "[log in to unmask]" for a user name. This also
tells me when my email info is betrayed, and I can take action as needed.
Gorilla has several hundred entries for me - besides my passwords I keep a
user list for the family tree web site I run - any of my user's can be reset
to a known (initial) state.
James said: "I have just five or so separate passwords . . . "
Gorilla lets me have unique user names and passwords for each site, and each
has a random password.
". . . keep on a single slip of paper . . ."
My Palm (and various backups) take care of this need.
". . . disposable passwords . . ."
Good idea. May I suggest you change the password on the way out, rather than
in? My understanding is that bleed occurs -during- the logged in period -
changing it on the way out might minimize this.
". . . do not use https and yet require a user login . . ."
Strangely, some banks used to do this. The HTTP page offers a login, and
then the protocol (presented after login) changes to HTTPS. Sweet :)
". . . 'smart cards' or 'flash' . . ."
Not me thanks. I'm not quick enough to be trying to out-run electrons. If it
can access one password, it can access them all. With Gorilla, if necessary,
I could make a special USB with only one login for the task. But that
doesn't serve my needs. My fingers still know how to type.
". . . so-called two-factor authentication . . ."
Useless in some cases. For example, my sister and I both require on-line
access to the bank account of my mother's trust. Whose phone should be
called for the confirmation?
My action plan for this heart-bleed issue is to generate a long (35
character or so? 75 characters?) password, use the first (16 characters?)
part for a password, then "circular shift left" to a new one as I log out.
I'll convey the big password securely (2 parts, via US Mail / fax) to my
sister and send an email every time the account is accessed.
James closes with some very fine observations which I agree with. I would
also add though, have you read the TOS for your debit / credit cards or
online banking? Seems that one of my previous banks took the position that
if their software messed up, it was my fault. Never mind what the friendly
teller says to you - what does the agreement say to the judge?
So I guess I rely more on old-style security (I still insist on paper credit
card signatures) and do not delegate trust (to lastpass or other
organizations) to keep my information private. I'm sure a committed party
could get access to my information, but I hope they would find easier
targets somewhere else :)
Finally, Stan just said: "I don't want *any* computer outside my control to
have my passwords,encrypted or not!" Amen! :)
--
Regards -- Tony B. Shepherd -- [log in to unmask]
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
