Rambling about the pain of dealing with passwords for online services

Posted: January 23rd, 2012 | Author: | Filed under: Fedora, Security | 11 Comments »

Over the last 6 months or so, I’ve become increasingly paranoid about password usage for online web services. There have a been a number of high profile attacks against both the commercial world and open source project infrastructure, many of which have led to compromise of password databases. Indeed, it feels like my news feed has at least 1 article a week covering an attack & user account compromise against some online service or other. And this is only the attacks that are detected and/or reported. Plenty more places don’t even realized they have been attacked yet, and there are likely plenty of cover-ups too. This leads me inescapably to my first axiom of password management:

  • Axiom #1: Your password(s) will be compromised. There is no “if”, only “when”

It follows from this, that it is the epitome of foolishness to use the same password for more than one site. Even if you are diligent to watch for news reports of site compromises & quickly change your passwords across all other sites, you are wasting hours of time, and still vulnerable for the period between the attack taking place & being reported in the media (if at all). Out of curiosity, I made a list of every website I could remember where I had registered an account of some kind. I was worried when the list got to 50, I was shocked when it went over 100, and I stopped counting thereafter.

There is a barrage of often conflicting suggestions about how to create strong passwords for accounts. Most websites simply say things like “you must use a mixture of at least 8 letters, numbers and special symbols“. Google have been trying to educate people about how to make up more easily remembered passwords, but XKCD points out the flaws in these commonly suggested approaches. Even if you do decide upon some nice scheme for creating your passwords, you quickly come across many websites which will reject your carefully thought up & remembered password. Compound this with the fact that many websites (typically financial ones) also require you to enter “passwords hints” based on questions that are supposedly easy to remember, but in fact turn out to be anything but. Now multiply by the number of sites you need passwords for (x100). This leads me inescapably to my second axiom of password management:

  • Axiom #2: It is beyond the capabilities of the human brain to remember enough strong passwords

There have been a great many proposals for shared authentication services, whether owned & managed centrally by a corporation like Microsoft Passport, or completely decentralized & vendor independent like OpenID. Today out of all the 100+ sites I use, I can count the number that allow OpenID login on the fingers of one hand. More recently the big social networks have been having some success with positioning themselves as the managers of your identity & providers of authentication to other sites. I am not happy with the idea of any social network being the controller of not only my online identity, but also controller of access to every single website I register with. I don’t trust them with all this data, and they are an extremely high value target for any would be attackers if they control all your website logins. Letting them control all my logins, feels akin to just re-using the same password across every website. I know they have marginally stronger login procedures than most sites, by allowing you to authenticate individual clients used to login, but this isn’t enough to balance the downside. In fact I’m not really convinced that I want any online service to be the manager or all my login details for websites. It is just too big a single point of trust/failure.

A minority of online banking websites now provide you some form of hardware key token generator, or pin entry device to authenticate with. This is clearly not going to work for most websites, due to the cost & distribution problem. Even within the limited scope of financial websites the practicality is limited – if every financial institution I dealt with had key token generators, I’d have a huge pile of hardware devices to look after ! I do like hardware authentication devices and now use them for login to any personal SSH servers that I manage, but with a few exceptions like Fedora, they are not a solution for the online password problem today or the forseable future. I am depressingly lead to my third axiom of password management:

  • Axiom #3: Widespread password authentication is here to stay for many, many years to come

Hmm, perhaps the problem is better described by mapping to the 5 stages of grief

  1. Denial – only careless people have their details compromised, i’ll be fine using the same 4-5 passwords across all sites
  2. Anger – how could $WEBSITE have been so badly run / protected, to let themselves be compromised
  3. Bargaining – if I just let Facebook handle all my logins, they’ll solve all the hard problems for me
  4. Depression – the industry will never get its act together & solve authentication
  5. Acceptance – passwords are here to stay, what can I do to minimize my risks

Well I think I am at step 5 now. I have accepted that passwords are here to stay, that sooner or later one or more of the sites I am registered with will be compromised, and it is impossible for me to remember enough passwords. My goal is thus to minimise the pain and damage.

My conclusion is that the only viable way to manage passwords today is to do the one thing everyone tells you never to do

  • Write down all the passwords

Of course this shouldn’t be taken too literally. I am not suggesting to put a post-it on the monitor with the passwords on it, rather I mean store the passwords in some secure location, which is in turn protected a master password. ie use a password manager application.

Using KeePassX for managing passwords

After looking at a few options on Linux, I ended up choosing KeePassX as my password manager because it had a quite advanced set of features that appealed to me. Before anyone comments, I had discounted any usage of a password manager built into the web browser before even starting. The browser is a directly network facing process of great complexity and frequent security flaws – they just aren’t the right place to be storing all your valuable secrets. The features in KeepPassX that I liked were:

  • Passwords are stored encrypted in a structured database
  • It is possible to specify many different metadata attributes with each password, username, site URL, title, comment, and more.
  • It can copy the password to the clipboard, allowing paste into web browser forms, avoiding the need to manually type in long password sequences
  • It automatically purges passwords from the clipboard after 30 seconds to minimise the window when it is visible
  • The database can be set to automatically lock itself against after 30 seconds, requiring the master password to be entered again to access further password entries
  • The password database can be secured using a password, or a keyfile, or both. The keyfile is just a plain file with random bytes stored somewhere (like a USB key)
  • An advanced password generator with many tunable options

I have several laptops and I want the password database to be usable from either machine. At the same time though, the password database should not become a single point of failure / data loss, so there needs to be multiple copies of it.  Using a password database does have the downside that it becomes a nice single point of attack for the bad guys. It would thus be desirable to have separate password databases for websites used on a general day-to-day business vs security critical seldom used sites ie bank accounts, and other financial institutions. With this in mind the way I decided to use KeepPassX is as follows

  • I purchased 4x USB stick 4 GB capacity for < 5 GBP each, two coloured black and two coloured white
  • All 4 USB sticks were split into 2 partitions, each of 2 GB size.
  • The primary partition is formatted with a Fedora 16 LiveCD. This is to facilitate easy access to the passwords, should I find myself without one of my own Linux laptops close by
  • The second partition is setup with LUKS full disk encryption and formatted with ext4.
  • The partition with the encrypted filesystem is used to store the KeePassX database files and any other important files (GPG keys, SSH keys, etc)
  • The black coloured USB sticks are used to store a database for financial account details
  • The white coloured USB sticks are used to store a database for any other website logins
  • One USB stick of each colour is the designated backup. The backup sticks are kept in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’
  • A shell script which will synchronize files between sticks, to be run periodically to ensure recent-ish backups

With that all decided there merely followed the tedious task of logging into over 100 websites and changing my password on each one. I decided that my default policy would be to let KeePassX generate a new random password for each site made up of letters, numbers and special characters, with a length of 20 characters. Surprisingly the vast majority of sites coped just fine with these passwords. BugZilla turns out to be limited to 16 characters and a handful of ecommerce sites had even shorter limits, or refused to allow use of special characters!

Using E-Mail “plus addressing” for accounts

It is often said that when bad guys have compromised a website’s account database they will try to reuse the same email and password on a number of other high value sites. Since many people reuse passwords & many sites allow login based off an email address, the bad guys will trivially gain access to a significant number of accounts on other non-compromised sites. I am already generating unique passwords for each site, but to add just one more roadblock, I decided that while changing passwords, I would also set a unique email address for every single site.

My exim mail server supports what is known as “plus addressing”, whereby you can append an arbitrary tag to the local part of an email address. For example given an address “fred@example.com” you have an infinite number of unique email address “fred+TAG@example.com” where “TAG” is any reasonable string. Sadly when I tried using plus addressing, I immediately hit problems, because many (broken) form data validation checks think “+” is not a valid character to use in email addresses, or worse they would accept the address but all email they sent would end up in a black hole. Fortunately, it is a trivial matter to reconfigure Exim to allow use of ‘-‘ as the separator for plus addressing, ie to allow “fred-TAG@example.com“.

Out of > 100 websites I updated my account details on, only 1 rejected the use of ‘-‘ in my email address. So now more or less every account I am registered to has both a unique password and unique email address.

In the end, the main thing I an unhappy about is that using a password manager presents a single point of attack for a local computer virus/trojan. Given the frequency with which websites are being compromised these days & the number of sites I need to remember passwords for, I think overall this is clearly still a net win. I will remain on the lookout though for ways to improve the security of the password manager database itself.

11 Comments

secure tux said at 11:01 pm on January 23rd, 2012:

Nice read, I’m also using KeePassX with a similar setup, nearly 70 passwords, changed all my passwords some time ago and using 5 different email addresses, maybe I will also store my databases in an encrypted container.

Hopefully someday we will have faster/better alternatives.

I haven’t tried this jet:

https://browserid.org/
http://identity.mozilla.com/
https://github.com/mozilla/browserid


A happy Fedora KDE user

Let’s be paranoid and secure our penguins.

PS: nobody_should_know_how_I_store_my_passwords@every_server_can_be_compromised.de -> ERROR: please enter a valid email address.

Daniel Berrange said at 9:49 am on January 24th, 2012:

> PS: nobody_should_know_how_I_store_my_passwords@every_server_can_be_compromised.de -> ERROR: please enter a valid email address.

IIRC, domain names are not able to have underscores in them, only hyphens.

Daniel said at 7:54 am on January 24th, 2012:

Instead of using KeePassX, a port of KeePass 1 to X11, you can also use KeePass 2 directly. This rewrite brings some nice new features ( http://keepass.info/compare.html ) and is written in C# with some care for portability, i.e. it can be used via mono, which is available in Fedora ( https://bugzilla.redhat.com/show_bug.cgi?id=751719 ).

Daniel Berrange said at 9:40 am on January 24th, 2012:

Thanks for the tip about KeePass2, I will have to take a look at that too. Just a shame it uses mono ;-)

Seth Vidal said at 5:00 pm on January 24th, 2012:

I use keepassdroid, too. Really great for managing the same. You just copy over the kdb file and you’re done.

Pete Zaitcev said at 12:16 am on January 25th, 2012:

Mono is absolute non-starter.

I simply keep passwords in a tab-separated text file and encrypt it with gpg. In addition, I use some basic empty space sweeps.

Daniel Berrange said at 9:52 am on January 25th, 2012:

I used todo the same with a USB stick containing GPG encrypted password files. IMHO, using KeePassX is a huge step forward in both usability and data security, the latter because you’re not polluting the terminal’s history buffers with your passwords.

Wolfgang said at 7:05 am on January 26th, 2012:

When searching for a passkeeper, did you ever come across a tool that plays nicely with .netrc (ftp accounts)
I am currently working with a tool that handles only my .netrc; basically it asks me to allow access for some program (usually ftp, could be wget, curl, even firefox). I cn then give a master password to allow or deny. If I allow, and the same program tries to connect within 5 minutes, it will be allowed without asking

Daniel Berrange said at 1:59 pm on January 26th, 2012:

No, I’ve never had any need to use .netrc, so I didn’t look.

Cristian Ciupitu said at 2:29 pm on March 8th, 2012:

You could also generate passwords instead of storing them. There was a discussion on Hacker News about this.

Jan said at 12:17 pm on November 19th, 2012:

Very nice idea. I don’t either like the idea of entering email address and/or user names for every f…ing site. Seems like we have to live with it. The result is that I become slightly more careful to where I register. I may certainly reuse passwords on less important places or don’t use very strong passwords on them.
But, correct me if I am wrong, I don’t think that the problem is about cracking bad passwords, unless they are stored in plaintext, which no serious site should do. Hashes are one-directional so the only way to find out, would be brute force. One problem is that the solutions by which you can reset a password are not safe enough. Well, don’t exactly understand the crypto mathematics, but given the same password to two user accounts will anyway result in different hashed password!
For the second, if you have the same passwords in sites A and B, and someone manage to reset your password at site A, they still wouldn’t know hoe to get in to B, as there is still the old password – unless they are connected with some passport or similar. If the hacker get access to your email account, the situation would of course be bad, as they could receive a link how to reset passwords. So in this sence, your idea to use a separate email for each site is very nice.
If you would have a hardware device for bank accounts etc., it need not to be one for each bank, it could be a common personal smart card, where there is plenty of room for storing information of all sites. It’s a pity though, that smart card have never been much used for this, the only exception are the mobile phones’ SIM cards, and those are used for authentication on some Finnish sites, at least.

Leave a Reply





Spam protection: Sum of 0ne plus s3ven ?: