Password ManagementIn light of the LinkedIn's recent password leak, I resurrected this post on password management from an older blog I used to operate. This post is nearly 4 years old and my reviews may be for out-of-date solutions, but the main thrust of the post is still sound.
Of all the tasks that a system administrator is charged with, I would have to say that managing passwords is by far the most banal, frustrating, and frightening. This is true whether one is in a corporate environment or even doing the best to illuminate non-technical family members on the merits of strong protection (perhaps an analogy to teen pregnancy might make them sit up and take notice!).
We all know, and agree, that we need to protect our assets and information from unauthorized access. Further, we need to ensure the confidentiality, integrity, and accessibility of our data. So passwords are better than nothing. But they're far from perfect. This fact is exacerbated by the myriad ways in which password policies are implemented and enforced. For sysadmins this is amplified by the fact that we are responsible for overseeing these policies for everyone and everything on top of remembering account credentials for every system and service we manage in the enterprise.
Simply imagine all the devices and services a sysadmin interacts with and logs onto on a daily basis. I personally have accounts for all the equipment I manage (i.e. Cisco routers, Netgear switches, Windows and Linux hosts) and the services I operate (i.e. email, instant messaging, databases). I've also got numerous personal accounts for banking, blogging, personal email, my credit cards, Facebook, and the fantasy football league. I'm swimming in dozens of credentials!
The intent of this post is not to wax technical about the technologies such as single sign-on or 2-factor authentication that aim to address and simplify this problem as it exists in limited, corporate environments; those are huge topics of their own that each deserve individual attention. In fact, I probably will write about them in future postings. Rather, the scope of this discussion is much broader in that it encompasses password management for several disparate systems, services, and my need to maintain various personal account credentials.
Users hate passwords. And sysadmins hate dealing with password-related issues (password resets, account lockouts, etc.). And no matter how much training you provide to your users, you will inevetiably field a call to assist a user with a password problem. There has been an ever-evolving arms race, if you will, between those that need to implement security and those that work to tear security down (or circumvent it). To wit, the battle has unfolded as such:
- Passwords were implemented.
- Users selected weak passwords subject to easy guessing or brute-force dictionary attacks.
- Password complexity rules were implemented to force users to select stronger passwords and prevent password reuse.
- Users, frustrated with those rules, invariably stored their passwords on Post-It notes strategically hidden around their cubes. Wary passers-by could easily collect that information, sometimes without having to look hard to find it.
So, without segueing into a discussion about 2-factor authentication (that _will_ be my next post!), how do we address this issue when it's magnified across mutiple accounts? I usually suggest to my users that they think up clever passphrases whose characters are slightly mangled. For example, the following passphrase:
I love Technical Panacea
could be turned into a mangled passphrase thusly:
That may work for a single password, but what about your other accounts? You don't want to use the same password for all accounts; that's a huge risk in and of itself. If someone cracks my Facebook page, no big deal. But if they're savvy enough to try that same password to log into my Gmail or banking account, and I've used the same password, I'm up the creek. Long passphrases like the above example are also prone to being written down to ease the user's pain too.
It's at this point that I normally suggest the use of a common prefix or suffix that one combines with something relevant to the system or service that can easily be remembered. A good example would be if I used a service by ACME Inc. I really like ACME, I think they're the best at what they do (supplying Wile E. Coyote with innumerable gadgets to capture that speedy roadrunner!). Maybe I decide on the following suffix:
Since it's ACME's website I'm logging onto (to order some anvils), I create an account with the following password:
I can apply this formula to all my accounts now:
Every time I log in to a system or service, I only need to remember that special initial key (i.e. acme, warnerBrothers) and my suffix. I have unique passwords derived from a very simple algorithm. However, we still have an issue. For every system or service that I log onto, the username requirement is likely to be different. Some websites like you to supply an email address. This is convenient as you don't need to think up a clever name anymore ('wileecoyote' is often already taken!). Some services require something different such as a full name or a name limited to 8 characters. We're still in the same boat as before: multiple accounts with different requirements and too many to remember.
Caveat: To be honest, though, the above method has a serious downside: if someone manages to figure out your system, it's pretty easy to guess all of your passwords. So, it's generally a bad idea to follow that model.
Now, I neither agree with, nor condone users that maintain their password information on paper around their desks. But some have been savvy enough to lock that information in their desk drawers. They at least have a physical layer of access to protect that sensitive information. For that, I applaud them. This very same idea has struck many others as well. Why not maintain a list of credentials in a secured fashion that only the user can access? Without a doubt, the credentials used the most will be remembered the easiest (kind of like cached data), so maybe this isn't necessary. But what about those credentials used less often? When's the last time you _had_ to log into your Cisco router? Those things just work!
I've researched a few solutions that may provide an answer to this problem. Now, anyone that knows me knows that I cannot stand duplicated effort. In almost all cases, there's no need to reinvent the wheel; many good products are available that will suit most, if not all, of your needs. I don't want to waste precious resources, like time, spinning my wheels when I could be more productive elsewhere. That being said, there are times when it is appropriate to roll your own solution (as we'll see below).
Before we proceed, let's define the scope of the problem so that we can easily apply a solution.
- I want a single, simple, secure place to store my account credentials.
- That information must be easily updated.
- I'll pay for a solution but would prefer something free.
- GPG-encrypted CSV File
Billing itself as a "web rolodex", Clipperz will store your account credentials, bank account information, addresses, and more online using what it calls a zero-knowledge application. This simply means that the folks at Clipperz know nothing about you or the information you're storing. They simply provide an interface that you use to access your information. The account you create with them is not linked to you in any way (not even via your email address). On the flip side, if you forget your account credentials for this service, don't bother shooting an email to the Clipperz admins; they cannot and will not help you. Remember, they know nothing about you or your account so they have no way to authenticate you.
Each collection of information is stored in what they call a card, keeping with the rolodex theme. After logging in to the service all of your cards are available to you in a simple, clean interface. You can import data from various sources (including most of those bulleted above) and exported for printing or JSON applications.
I really like Clipperz. You can store all sorts of information on top of your account credentials and it offers a very handy feature called 'direct logins'. With direct logins, you can copy the code around the login function for your favorite website (via a simple bookmarklet they provide), store that along with your username and password, and simply log in to that site with a single click! I've used this for some minor services I use (i.e. Facebook, Yahoo! Sports) but I wouldn't use it for anything I deem sensitive like banking information. Call me paraniod, call me old school, but I prefer to take a 'trust but verify' approach to some things, especially in the realm of security. It's fun and exciting to be on the bleeding edge of technology, testing new software and experiencing new services. But it's called "bleeding edge" for a reason. I won't store my important information online with Clipperz or a similar service. The risk outweighs the benefits at the moment.
Verdict: The direct login feature is slick and I like the idea of storing information in "cards" but Clipperz is more than I need and I don't fully trust the service.
Keepass is a clean, lightweight, open source solution for Windows systems with available ports for other platforms and a standalone binary that can be deployed on USB sticks. It's bascially a database encrypted with a master password, a key file, or both (referred to as a composite master key). The first time you launch KeePass you will be prompted to create a master password. This is the password that will be used to encrypt the database. I didn't create a key file so I don't have details on that process.
The interface provides 4 general password groups that allow you to organize your passwords into the most common categories (i.e. Windows, Network, Homebanking). You can also create additional groups if you see fit. Adding, modifying, and deleting entries is very easy. Plug-ins from third parties are also availabe that extend the program's usefulness including browser plug-ins that will fill web forms with standard information including account credentials. KeePass' author notes, however, that not every plug-in has been tested or verified for malware. Caveat emptor.
Being open source, KeePass' code is available for scrutiny. At the moment, I'm not inclined to do so other than to determine that it's written in C++. Other than that, I'm unable to comment on how strong the encryption may be or how well the code is written. I can tell you that the database file created by KeePass looks like a garbled hot mess in Vim. I can also determine the number of entries in the database since it appears to be a simple flat file. This by itself isn't interesting, but knowing the structure of the file may lend itself to further cracking. This is similar to the fact that certain letters in the English language are used more often than others; character frequency analysis is a simple tool often used to crack cryptographic codes.
Verdict: KeePass is a good program but it's an overly complex solution based on the fact that it's written in C++ and uses a database backend. In security, the simpler a thing is, the easier it is to manage and therefore less prone to cracking.
Both PasswordPlus (http://www.dataviz.com/products/passwordsplus/pwp_techspecs.html) and RoboForm (http://www.roboform.com) are proprietary solutions. They both cost about $30 for a license and offer cross-platform support. Another feature to note is that they provide support for mobile devices (see their respective websites for more information). I don't have any need to store my sensitive information on my mobile phone but this may be a requirement for others. Any road warriors out there reading this?
I haven't tried either of these programs but felt they deserved a mention. They provide many of the features described in the previous two offerings as well as additional support for mobile devices.
Verdict: I didn't want to pay for these programs as there are perfectly good free/open solutions available. Either I'm a spendthrift, or I'm cheap...
Remember when I stated that I wanted "... a single, simple, secure place to store my account credentials"? Now that I think back on it, and have reviewed a few solutions, I think that requirement needs to be amended:
I want a single, simple, secure place to store my account credentials that leverages open, proven standards.
Open, proven standards. This is a biggie, especially in the world of security. I'm one person; if I had evaluated KeePass and determined it to be safe, my judgement is constrained by my experience and knowledge of cryptography. Someone else may make a completely opposite determination. But what about openly scrutinized solutions that have received attention from the brightest collective minds in the world? If hundreds, maybe thousands of people from all walks of life and various professions have scrutinized and certified certain solutions (i.e. SSH, PGP) for use in securing information, then it follows that I can be reasonably assured that those same solutions are viable options for me. This led me to my final solution, the one I have actually implemented in the field.
I'm a simple guy, ask my wife. I like cold craft brews (like my own) on a hot summer day, and a good scotch, neat, in the evening. So it is with my choice of password management: a gpg-encrypted CSV file containing all of my sensitive information. I've generated a very strong key pair and locked it up with a very strong (and exceptionally hard to guess) passphrase. I implement additional security by physically separating that data onto a USB stick that I carry with me. I only edit the file from the USB stick and never make copies to any other media. It's important to understand the behavior of your editor of choice. I prefer a WYSIWYG editor like Notepad or Vim because they're, you guessed it, simple. More importantly, they don't save temporary copies of your data in some far off (i.e. not local to the USB drive) directory and forget to clean them up, like Microsoft Word. When I'm finished modifying the file, I encrypt it. Before deleting the decrypted version, I run a shredding program against it a few times, to be safe.
My encryption program of choice is GnuPG (gpg) and I use a standalone version run from my USB stick. gpg is well proven and uses open encryption standards; it's everything I need. Even though my private key is stored on the USB stick, the passphrase required to unlock it is horrendously hard to guess and is therefore well protected.
The fields in my CSV file are based on my requirements. I need to know what the account is for, the username, password, and potentially add some notes. I also like to track the last time the password was updated so that I can easily determine if I've been using a given password for too long.
Verdict: A gpg-encrypted CSV file fits all my requirements. It's a single source for my information; it's simple, secure, and uses open standards for encryption. I can easily update the data using a WYSIWYG editor such as Notepad or Vim. And best of all, it's free.
While my solution is simple, secure, and free, it's important to recognize that it is not 100% free of issues. In fact, no security measure is ever a complete solution, hence the need for defense in depth. Of particular note is that I would never insert my USB stick into a public or non-trusted terminal to access my sensitive information. For all I know, a keylogger could be in place that would capture my private gpg key's passphrase. Even worse, with my sensitive data open in an editor, it's available in memory. A savvy cracker could cull that information and then have all the keys to my castle.
What I've selected as a best fit for me may not work for you. Remember that before making any decision, for security purposes or anything else critical, it's crucial to define your needs or project parameters and strive to implement a solution that fits most (hopefully all) of those needs.
Ultimately, there will be a few credential sets that I will decide not to store and will always need to remember. Call me paranoid, call me old school. But you'll never be able to call me a hypocrite: the guy that tried to enforce good security in the form of password management but didn't implement it himself.