One of the biggest causes of heartburn I’ve seen on projects is when organizations want single sign on.

It should be simple!

On the surface, it’s simple, right? Why remember a bunch of passwords, when you can just tie those systems together and have them use the same login across them. After all, you’re the same person, so why should you have to identify yourself differently to each program you use to do your work?

In practice, especially in the nonprofit world, many applications date from a time before a ubiquitous internet pushed applications from your local computer to a web server. Since most people would ever only need to access that application and a few others, and often identity was tied to a computer rather than a person, there really wasn’t a reason to build in a security nightmare of letting other applications access your users or tell you who someone was.

Additionally, lots of those applications date from the time when everyone tried to be everything to your organization. Some later applications (*cough*Convio*cough*) still think that way, and try to have a “component” to do each thing you want done, rather than being the best of breed in one area and letting other companies handle other aspects of your operation.

Additionally, there’s no good standard for sharing identities—your login—across application. Sure, there are plenty of standards, but no good ones. Some require you to go to a trusted third party website to authenticate, and some are enterprise-y schemas that aren’t implemented the same way across systems.

And guess what? There isn’t a standard that everybody supports. So almost no matter what scheme you try to use, no two popular systems likely use them. Most open source systems allow you to “hook in” to their login and put custom code in its place, but the more custom code that has to be written, the more development time, testing, and room for general bugginess—and it opens up new vectors for hackers.

So what do you do?

Fortunately, there’s a pretty easy solution: if your applications are web-based, every modern browser supports a “remember my password” function. It’s free, it’s already there, and you probably use it at home. I logged into hundreds of websites regularly when I was consulting, and I just had the browser remember the passwords. Sure, there’s that extra step of going through a login screen, but it turns out most shared identity systems actually make you go through a username screen, just without a password. Since the browser remembers it for you, you’ve lost zero time.

If for some reason that doesn’t work for you, then look into password managers. They’re great applications, and if you use Mac OS X, it’s built into the operating system. (Look for “Keychain”—it even syncs over iCloud!) Here’s a review of five different systems, most of which work cross-platform.

Yeah, but I want it! (And a flying magic unicorn pony.)

Be prepared to add 20%, minimum, to the cost of your project.

That’s a lot of features you’re giving up to save yourself a few seconds of using a password manager each day. Assuming your project is $120,000 and you have 20 users, each of whom (at an extreme) spends 30 seconds per workday dealing with password managers, that’s paying $20,000 to save you the equivalent of one person doing a week’s work. Unless your employees cost you $500 an hour, almost anything you do will get you more value for your budget.

Save the money, and just train yourself to click “Yes, remember this password,” when that dialog pops up.