The past week’s Gawker password mess is as good an opportunity as any to talk about password management when you’re outsourcing work to 3rd parties. As a programmer for hire, I’ve seen just about every questionable practice you can imagine, and I’d like to think that it’s because I’m so darned trustworthy, but some of these incidents have happened a little too early in the relationship for my liking. Here are a few tips for your company, whether you’re the outsourcer or the outsourcee.
It’s not about trust
No matter how trustworthy the person you’re giving the keys to might actually be, things happen. Maybe they’ve set their browser to remember passwords and then someone gets access to the computer through theft or temporary use. Maybe they’re logging in on open WiFi and your service doesn’t use SSL, as demonstrated recently to be a huge problem. Maybe they’ve got a virus that captures any password input on any web page. There are lots of ways a secure password can get compromised without any actual action or intent.
Every service gets a unique password
Gawker’s breach also highlighted a common problem: people use the same passwords on many different sites all the time, or they use a consistent scheme like “add the number 55 to the end of the site name.” With apps like 1Password, there’s no reason not to use as many passwords as you have logins anymore, and there’s also no reason to make them easy to spell.
Every service gets an account, where possible
If you’re using a service that lets you authorize multiple users to the same system, by all means, create a user account for each person who needs access, and if there are secondary access controls like privilege levels, only give out as much power as is needed to get the job done. With a shared login ID, it’s hard to tell who did what in the event of problems, and it’s much more disruptive when you need to revoke access to the whole team rather than just one user.
When I’m granted access to a service by a client, the first thing I do is create my own credentials and then recommend they change the master password to something else. That way, I’m covered after I leave the project: I assume (granted, sometimes it doesn’t happen) that my account’s been revoked, so any incidents that happen later aren’t anything to do with me.
Keep a list
With services that have multiple accounts like I mentioned above, this is easy, but for everything else, keep track of who has access to the master login and password. You’ll want this for business continuity purposes in the event that you have to change the password (see below, but I’ve also heard a decent argument that by changing the password and only telling it to people who ask you’ve got a good way to clean house.)
Adhere to a change schedule
You should do this for your own passwords, but also for any shared accounts. You want to minimize the exposure window in the event that there is a breach at some point. Remember, if someone gets your password, depending on the service it might be more profitable to just sit back and read without changing anything that would tip you off.
Consider the worst case scenario
With all services, what’s the worst thing that could happen if someone got access who didn’t have your best interests at heart? How could you change your business to reduce the impact of this scenario? How could you monitor to make sure that you catch the problem as soon as possible in the event of an incident?
Try not to send logins and passwords by email. There are lots of gaps in the chain where someone could get at them, and the messages tend to hang around longer than necessary. I’m sure I’m not the only one who used to have a “passwords” mail folder (I don’t do this anymore…)
If not email, then how do you communicate them? Without resorting to encryption, over the phone or in person is good, or you could invent some kind of mechanism to deliver it in parts over different services. Honestly, I haven’t seen a technique that I really like yet, so I’m open to suggestions (PGP and other encryption schemes are still too tricky for most users.) I like some of what I see here, and there’s a good suggestion in there to require users to change the password after they log in so no records are left (though obviously this doesn’t work with shared logins.)
Speaking of email, if your email account password is compromised, you’re in a heap of trouble, since most services send password reset messages via that account, which means if someone has access to your mail, they own your life. You should change these passwords fairly often.
Do as I say…
Do I follow all of these rules? Personally, not always. I’m human. For clients, I try to follow protocol all the time – for their sakes and for mine.
Security covers a lot of areas, but basic access control at the password level is a good place to start that there’s really not much excuse for avoiding. If you’re not following at least the above tips, I urge you to start, and be wary of any 3rd party that seems to think these ideas aren’t important.