I talk a lot on Twitter about my password manager. I use 1Password and love it. It auto-generates random passwords for me of any length I choose, auto-fills web forms for me, and remembers both the web page and the hideously complex password I have chosen. It automatically synchronizes across all my computers so I am never without all my current passwords. The file is encrypted with AES-128 and they handle encryption keys securely, so I believe the product is pretty secure. Now, rather than having a couple good passwords for the handful of sites I care about – and a single generic password for the 300 sites I don’t – every single one of my web accounts has its own strong password. Or I should say as strong a password as each site allows. I always worried about having the application crash and losing every single one of my passwords. Irrational fear. I back it up like any other application. In hindsight I can’t figure out what took me so long to change over.
Another irrational aspect of passwords dawned on me today: we automate password administration and enforcement, but require users perform a manual process. Why?
There are some basic problems with people and passwords:
- We don’t want random passwords – too hard to remember.
- We don’t want to choose long passwords – too hard to remember.
- We don’t like typing long passwords. Frankly they are a pain in the ass to type in, and a triple pain in the ass if you mistype the first attempt.
- We don’t want to rotate passwords – it means I have to learn three of four long passwords just for work.
- We hate calling IT to reset passwords – because that takes more time out of our day. And the guy in IT treats us like dorks every time we call.
Ultimately this is all because we suck at remembering passwords. Worse, we don’t care about the passwords – they are a necessary evil. Passwords are something we have to do. So why not automate the whole mess – especially for corporate IT users?
Today we centralize password policies and automate enforcement of those policies (length, character requirements, expiration, etc.). There is no reason we can’t automate the client side as well, but enterprise password managers are rare as hen’s teeth. For corporate environments we could even embed advanced capabilities with virtual RSA tokens, access tokens for shared services without shared credentials, or even SAML capabilities. And we could allow each user to maintain individual passwords, with separate password repositories in case a single user account is compromised. I acknowledge that it’s conjecture on my part, but I am willing to bet that automation will reduce user error and ultimately IT’s password management burden. I am not aware of a password management product that can fully support enterprises today – but several are not far off.
I think it’s time we see more password managers in corporate environments
Reader interactions
10 Replies to “FireStarter: The Time for Corporate Password Managers”
Yes, we should have password managers. There are a number of good ones for personal use. I use more than one.
The only question is, are there any available that fit corporate needs? This is a question I’ve asked and been asked around many a conference lunch table, with no good answer yet.
At our institution, we’re looking at deploying a password manager (PasswordSafe or KeePass) as a standard package, configured to store the encrypted archive on the user’s auto-mounted personal networked storage space.
Doesn’t provide remote password reset, but it does allow password management to be available independent of machine.
The only thing users have to say is usually: can you make it ask for my master password less often?
I’d caution that any automation that creates ease of use for users also creates ease of abuse by malicious actors. At least when there is *always* a present need of something I know, I have some relative assurance of control. I’m sure there’s a lesson in there from RSA this year…
I really think there is a problem with comparing the centralization of policies/rules and the automation of the actual password credential/token use on the client. I think that’s a flawed comparison, but I’m at a loss for words to describe why…
For instance, do you have a strong master password on your manager and rotate ir regularly? Do you rotate your stored passwords regularly, or would that be done automatically as well? Just because we add another layer doesn’t abscond these best practices.
At my employer, we actually allow people to self-serve for their forgotten passwords using a web site and security questions, but they certainly still can call in and have it done by desktop support. Most people still prefer desktop support assistance.
This also doesn’t solve the current problem of remote access using consumerland products. If I don’t know my passwords because I rely on my manager, what happens when I don’t have that manager at my fingertips? We might actually end up making our users dumber?
For the record, I think this is a great firestarter topic, but it sure would help to have actual product examples or detailed scenarios. 🙂
>>
Why do we try to kill these problems with centralized and Federated systems when decentralization is often a better model.
<< Cynic: More complex systems means more money for the vendor, a healthy ecosystem for system integrators, deeper hooks into the customer, etc. Optimist: While passwords are a problem for the end user, the enterprise problem is much more around provisioning and deprovisioning from a large universe of disparate systems. The federation and other complex idm systems solve that core problem while also solving the end user problem almost as a happy coincidence.
Adrian – I agree – we should be talking about credential managers rather than just password managers. Which can hold all sorts of credentials, including digital certs, one-time password algorithms, maybe even a true one-time pad (storage is cheap)!
Pure public key technology (without requiring the Infrastructure bit) offers a way round those 9 key pairs – since you can share the public key certs between any player. The Infrastructure (signing hierarchy) part gets in the way since it implies trust relationships, when you don’t always want a third party to be involved.
How do you use 1Password on your Linux machines?
The problem is that a lot of the tools out there don’t work particularly well at a corporate level, where lots of applications are a little bit ‘less than perfect’. Their screen scraping nature means they struggle to figure out all the different window names, URLs, input fields etc.
What would be really clever would be if we could collectively agree on an API style set of hooks that websites, applications etc. could implement to make the password management easier. That way, we’d not have to do what a colleague of mine is currently up to, ‘training’ the password manager to work with lots of different apps, any of which could break the next time we have to apply a patch.
Damian – I am arguing for a decentralized model. You break one manager and you just get one user’s stuff.
Andrew – Agree that it makes it easier to share, for some reason that is a feature of the corporate versions. Legacy applications don’t provide good means to break up admin responsibilities amongst several users so you will have that problem. Nothing against PKI credentials but I realize this is another management headache. Setting up my cloud services – just for myself – I have like 9 key pairs. Password manager to the rescue.
ds – I knew _someone_ would accuse me of setting up a straw man, and my response is if the concept is not controversial why is it radical? Password managers have been around for years but don’t get used in commercial settings. Why do we try to kill these problems with centralized and Federated systems when decentralization is often a better model.
-Adrian
Not very controversial for a firestarter. You describe Enterprise SSO, which has been around for ages. The problem is that, once it comes into contact with bespoke and legacy applications, it doesn’t work quite as simply as it does in a consumer setting.
Orgs that have a lot of applications tend to need SSO but might not be up to the complexity and ongoing management. Orgs that have fewer applications need it less and therefore may just live with the problem. The result is that ESSO doesn’t take off.
One issue with corporate password managers is that they can make it easier to share passwords. Of course, you may want to do this deliberately, e.g. for local admin passwords controlled and shared by the support team. Make sure you think through the risks!
But – I hope – such systems are only a tactical solution to current problems. Moving to public-key based credentials is much more strategic. That approach avoids the need to share any secret credentials, so the same credential can be used in many places, without the ability of any service to compromise the secrets.