Coping with the Avalanche of IDs and Passwords?
Bitwick asks: "The number of web sites and other systems I need IDs and passwords for is finally becoming overwhelming. Right now, I tend to use a small selection of IDs and passwords. I know this isn't an ideal situation, but so far it has been the most practical. However, it has become clear to me that this needs to change. I am planning to get a USB keyfob and a password manager to keep track of my IDs and passwords. What experience have you had with password managers? What's good, what's bad, what features are important? Are there other reasonable and secure alternatives?"
A text file with your usernames and passwords slightly obsufucated may work depending on the sort of person you expect to find your thumbdrive.
You can run Openoffice on a thumb drive and save your list of passwords in a encrypted document if you need added security.
Stop the world; I need to get off.
hNo .vimrc:
/dev/null'
matter where I'm at, I am always ssh'ed into my server. So, I put the following into my
augroup encrypted
au!
autocmd BufReadPre,FileReadPre *.gpg,*.asc set viminfo=
autocmd BufReadPre,FileReadPre *.gpg,*.asc set noswapfile
autocmd BufReadPre,FileReadPre *.gpg set bin
autocmd BufReadPre,FileReadPre *.gpg,*.asc let ch_save = &ch|set ch=2
autocmd BufReadPost,FileReadPost *.gpg,*.asc '[,']!sh -c 'gpg --decrypt 2>
autocmd BufReadPost,FileReadPost *.gpg set nobin
autocmd BufReadPost,FileReadPost *.gpg,*.asc let &ch = ch_save|unlet ch_save
autocmd BufReadPost,FileReadPost *.gpg,*.asc execute ":doautocmd BufReadPost " . expand("%:r")
autocmd BufWritePre,FileWritePre *.gpg '[,']!sh -c 'gpg --default-recipient-self -e 2>/dev/null'
autocmd BufWritePre,FileWritePre *.asc '[,']!sh -c 'gpg --default-recipient-self -e -a 2>/dev/null'
autocmd BufWritePost,FileWritePost *.gpg,*.asc u
augroup END
And I have a pw.gpg file that I just store everything in a "usage username/password" format. Works like a champ, and I'm not bound to a proprietary file format from the password-manager of the week. Seriously, I tried most everything before, from palm-based managers, os x's keychain, kde's wallet, and this is by far the easiest to use, most robust, and the most future-proof.
Problem statelment: How to associate one string (domain name) with another string (username/password combination)? a.k.a. translate strings.
Here's a whacky possible solution: use a translator pen, such as this:"SuperPen Translator" - which supports 'custom dictionaries' , to store passwords. Run the pen across site's address bar displayed on the computer screen, and the pen translates it to your username/password for that site.
Here's another of those pens: C-Pen.
Of course, if none of their dictionaries are user-editable, and if they have no SDK, this won't work.
Here's a more sensible solution: Javascript password generator
(Video about it - flash format)
Save the following html page to your computer or usb device
http://angel.net/~nic/passwd.html
Come up with a master password, enter the domain name of the particular site you are browsing and a unique password is generated for that site. All you have to remember is your master password. The page uses javascript, no data is passed to the internet. Whenever you need a password, just run the saved html page, enter master password, enter domain name, click generate button and you have your password
I used to use a USB key with a list of sites, usernames and passwords on it. All protected using a secure zip drive. It became a pain in the ass to get the passwords out, so I gave up. It also concerned me as a single point of vulnerability (if someone stole it and cracked it they have access to my life).
So now instead I use this algorithm:
$password = MD5($sitename . $single_password)
So I don't have any passwords written down, just the single global password in my head along with the algorithm. There's an MD5 calculator on every UNIX system, and there's javascript ones available on the web too.
The benefits of this system:
Some websites don't support 32 character passwords, for those I just use the first 10 or 20 characters of the MD5 hash.