I'v used a shared dropbox folder with a KeePassX instance in it with a shared password for that container. If needed we could just change the password on the KeePassX container and/or remove the access to dropbox.
Same goes for any centralized service you may use. You are still able to copy passwords manually into a text file, local keepass, etc. True, it is easier with a shared keepass, but the challenge is the same if you truly need to make sure a former employee can no longer access anything.
Used the same approach, but with a google drive document instead of dropbox. But you can't skip updating all (or at least, most of the perimetral ones ) passwords when a employee leaves (unless you trust him even after he leaves). If he made a local copy of the Keypassx file (or even pasted every password in a document, to cover most of the other alternatives) removing access to dropbox or changing master password will not stop him to keep accessing the old passwords. And the same goes with certificates.
you don't - you use an directory (LDAP, Active Directory) or AAA service (RADIUS,TACACS+) to manage that. There should never be a shared password. If it is a cloud shared service, same rules apply. You have to know who did what when, and with a shared PW you cannot. Even if all people have the same privileges, you gotta know who did what.
This is fine for things your organization controls. It isn't possible when dealing with lots of outsourced services. Too few services provide a way to hook into your LDAP or Active Directory.
True, but there still shouldn't be a shared password. Personal accounts for everyone.
For the few truly top-level master accounts around, a printed password in the safe will do fine. It should be painful and feel dangerous to use those, because it is.
This isn't possible for every service. For example, our company Twitter account. Twitter doesn't allow any way for individuals to have their own passwords and post to the account. We have a social media team, all of whom need to be able to post to the Twitter account. There is no way around sharing a password for that (and it's just one example of many). It's great to be idealistic and say don't share passwords, but in the real world, it's not always possible.
If you have a good internal service for auth/z, you can store passwords for less-critical outside services in plain text files on a network filesystem, with permissions locked down so that only the relevant people can read those files. In terms of security this seems similar in strength to what Passpack does--it lets authorized users see the actual passwords if they want to, or you can build applications on top to read from the file and log in to outside services. I did something like this once for FTP-style logins, and it worked all right.
Apart from that case, you really can integrate Kerberos or similar into your own applications, using e.g. SASL.
In my experience this is what it often boils down to. If access control isn't possible, it immediately and totally rules out using that service. For many companies this is how they have to operate for auditing purposes, and they have to be audited otherwise their clients can't use them, etc.
Although to be honest, out sourcing things like this is often not possible in itself. For internal passwords, everything should be linked to a single-sign-on system of some sort I think.
The problem is that for them to log you in they have to store your passwords in clear. It seems like the data is encrypted in their back-end but the webapp has probably the decoding key. https://www.meldium.com/security
With my last client we used to have a spreadsheet on Google Docs. Not at all secure but people weren't putting bank passwords in that either. More like test logins to various WP sites we had and stuff.
We used to have a spreadsheet with a silly password that could be hacked in 1 minute using rainbow tables.
Now we moved to a shared Google spreadsheet. Not really that much more secure, but at least it's easier to manage.
We are using LastPass for credentials to external services (e.g., Amazon Web Services, Twilio, Tropo). It has the advantage that all encryption/decryption happens on the client, so passwords are not stored in cleartext on LastPass's servers.
While I use 1Password myself, a few companies I've worked for now have been using Passpack (https://www.passpack.com/en/home/) which provides a neat way to "share" passwords securely in the event that an employee leaves so you don't lose any accounts. This is in addition to AD or Google Apps depending on the company's infra.
We've been using PassPack for a while but it's more of a pain to use than a pleasure.
The biggest issue is that password entries are owned by a single user and then selectively shared to other users. It means that if you want to have an overview of all the passwords you need to make sure to have a "owner" account to whom you transfer ownership to, and then make sure to share the password back with you and potentially others.
It would be much more practical to have a notion of bucket/group that a list of users can access and modify.
There are still a lot of service providers that don't support multiple user accounts per organization, so if you want to share admin privileges (a good idea for redundancy) you're forced to share credentials.
We used LastPass [1] for the following reasons:
1. Works across multiple OS and device types.
2. Passwords can be either "shared" (used to auto-fill forms but not viewed) or "given".
When we did a small layoff, I insisted that we quickly change the passwords for everything [2], and LastPass made it a no-brainer to distribute the new passwords around the organization.
[1] http://www.lastpass.com/
[2] It felt somewhat harsh at the time, but I'm glad I insisted on this, because shortly after one of the founders started hypothesizing that a software bug might be due to ex-employee hacking. I was able to squash his paranoia by reminding him that the exes no longer had access. Eventually we determined that it was a pre-existing bug.
> Passwords can be either "shared" (used to auto-fill forms but not viewed) or "given".
What's preventing someone from filling a password box and reading its value from memory? The fact that this is even a feature makes me suspicious about their security claims.
Lastpass acknowledges this and tells you that a shared password can be retrieved, but for most employees, it would be more work than it is probably worth to view that password. Also, as another commenter pointed out, as soon as a employee leaves the company, Lastpass makes it VERY easy for one person to change the passwords and everyone with access gets their version updated automatically.
I've had a lot of luck with Roboform Enterprise and KeePass. Storing the passwords in a place folks can find them has never been a problem- in a protected spreadsheet, in a heavily-locked down Sharepoint site, or in an internal-only Wiki. The real hassle is changing them all when an employee leaves, which happens a lot. Roboform has been great for storing those passwords, protecting them, and keeping us from having to give plaintext access to the passwords where it isn't required.
When you have 20+ techs accessing many different systems for many different clients each day, that feature was huge.
You should first ask yourself why you have the shared password at all. Unless there is simply no other way, shared passwords and logins should be avoided for the obvious reasons.
Next you need to document the procedure for resetting each of these passwords and accounts when an employee with access is fired or quits. Resetting the password needs to happen the minute the employee leaves the building.
As for documenting the password itself, the best approach is a shared document or file with built-in access control and auditing so you can tell exactly who has seen this document (for instance, google docs. Or an "enterprise" wiki).
While you can't use technology to prevent it, there should be a policy that employees cannot distribute these passwords, period. This is why having the password reset procedure is so important.
There are plenty of necessary sites that just don't let you have multiple accounts for management. I can think of a few but there are tons more - ebay and PayPal are the first two that come to mind. You also get into "concurrent licensing" issues - lots of companies make you pay for each "person" you have tied to the account (like an infrequently used fax number). Account sharing is a necessary evil - but the other comments you mentioned are dead on.
I researched this 3 years ago for our startups and couldn't find anything really good that lets me easily and securely share passwords on a need-to-know basis to team members and see who has access to what. Which baffles me because this is a problem that every single startup and small company must have.
In the end, we went for https://www.passpack.com/. They're clearly a small shop but it's been designed from the ground up for teams, they appear to care and know what they're doing when it comes to security (only have their word for it though obviously). Their web interface doesn't look like much but it's insanely fast and really well thought out, making inputing and looking for password really quick and easy. For some reason their pricing is ridiculously low - it costs next to nothing.
Two bad points: no native mobile app, making it a huge pain to look up password on the go + paranoid on the security front, which means that logging in is always a big pain. That unfortunately means that we were never able to convince anyone to really embrace it. Convenience and security is always a balancing act and Passpack is definitely leaning on the security side (understandable obviously). TBH, if they had a good native iOS app, I think it could make a difference for them. Instead of being this really annoying tool you're forced to use at work, they could become something that everyone uses as part of their daily personal life which would make it easier to get it adopted at work.
I've used passpack as part of a team and the workflow is pretty much spot on.
I have doubts about the security (cryptography in javascript) and the long-term prospects of such a small provider; I worry about them disappearing one day with all my passwords.
We've been doing research on this at StartHQ (https://starthq.com) since we offer a web app launcher and new tab replacement extension (like the old Chrome New Tab page, but better) & SaaS password management would be a logical extension to that.
Out of the 20+ companies we've interviewed so far one had heard of Okta & none had heard of Bitium and Meldium, the main players in this space. One was using LastPass.
Most do not have a strict password policy and the current solutions include storing them in other web services like Trello and Google Docs, or sharing logins within a team using post it notes or via email.
One trend that I've clearly spotted though is the use of Google Apps to consolidate identity management in the cloud. This is often synced with AD via LDAP. Whenever possible, companies encourage but do not enforce the use of Google for logging into third party services. This makes offboarding a lot easier and that is the main pain point, as opposed to onboarding of new employees. This is further confirmed by SaaS providers saying that they see up to 60% of all their logins being done through Google Apps.
My company uses LastPass. It's a nice service.
- The admin will have control over what service you need to have access to.
- Change password often and will be accessible by team mates without having to remember anything.
Simplifies a lot of other things, all you have to remember is the master password.
There's a sharing feature (multiple vaults) in the new 1Password 4 for Mac—but it hasn’t yet migrated to any of the other versions (including 1Password 4 for iOS).
Haven't tried it yet. But the key would be sharing individual passwords with the right people - not just having a shared vault where it's all or nothing.
The ideal is to avoid shared passwords on role accounts -- have individual user accounts with user-selected passwords (and ideally MFA), with the ability to then selectively upgrade access to role accounts.
I generally use 1Password standalone, but it's a bit weak for sharing.
68 comments
[ 2.4 ms ] story [ 184 ms ] threadFor the few truly top-level master accounts around, a printed password in the safe will do fine. It should be painful and feel dangerous to use those, because it is.
Apart from that case, you really can integrate Kerberos or similar into your own applications, using e.g. SASL.
Although to be honest, out sourcing things like this is often not possible in itself. For internal passwords, everything should be linked to a single-sign-on system of some sort I think.
[1]: https://meldium.com/
The problem is that for them to log you in they have to store your passwords in clear. It seems like the data is encrypted in their back-end but the webapp has probably the decoding key. https://www.meldium.com/security
The biggest issue is that password entries are owned by a single user and then selectively shared to other users. It means that if you want to have an overview of all the passwords you need to make sure to have a "owner" account to whom you transfer ownership to, and then make sure to share the password back with you and potentially others. It would be much more practical to have a notion of bucket/group that a list of users can access and modify.
We used LastPass [1] for the following reasons:
1. Works across multiple OS and device types. 2. Passwords can be either "shared" (used to auto-fill forms but not viewed) or "given".
When we did a small layoff, I insisted that we quickly change the passwords for everything [2], and LastPass made it a no-brainer to distribute the new passwords around the organization.
[1] http://www.lastpass.com/ [2] It felt somewhat harsh at the time, but I'm glad I insisted on this, because shortly after one of the founders started hypothesizing that a software bug might be due to ex-employee hacking. I was able to squash his paranoia by reminding him that the exes no longer had access. Eventually we determined that it was a pre-existing bug.
What's preventing someone from filling a password box and reading its value from memory? The fact that this is even a feature makes me suspicious about their security claims.
When you have 20+ techs accessing many different systems for many different clients each day, that feature was huge.
Next you need to document the procedure for resetting each of these passwords and accounts when an employee with access is fired or quits. Resetting the password needs to happen the minute the employee leaves the building.
As for documenting the password itself, the best approach is a shared document or file with built-in access control and auditing so you can tell exactly who has seen this document (for instance, google docs. Or an "enterprise" wiki).
While you can't use technology to prevent it, there should be a policy that employees cannot distribute these passwords, period. This is why having the password reset procedure is so important.
In the end, we went for https://www.passpack.com/. They're clearly a small shop but it's been designed from the ground up for teams, they appear to care and know what they're doing when it comes to security (only have their word for it though obviously). Their web interface doesn't look like much but it's insanely fast and really well thought out, making inputing and looking for password really quick and easy. For some reason their pricing is ridiculously low - it costs next to nothing.
Two bad points: no native mobile app, making it a huge pain to look up password on the go + paranoid on the security front, which means that logging in is always a big pain. That unfortunately means that we were never able to convince anyone to really embrace it. Convenience and security is always a balancing act and Passpack is definitely leaning on the security side (understandable obviously). TBH, if they had a good native iOS app, I think it could make a difference for them. Instead of being this really annoying tool you're forced to use at work, they could become something that everyone uses as part of their daily personal life which would make it easier to get it adopted at work.
I have doubts about the security (cryptography in javascript) and the long-term prospects of such a small provider; I worry about them disappearing one day with all my passwords.
It's a nice service, although the UI/UX could be polished and simplified. We haven't switched away.
Out of the 20+ companies we've interviewed so far one had heard of Okta & none had heard of Bitium and Meldium, the main players in this space. One was using LastPass.
Most do not have a strict password policy and the current solutions include storing them in other web services like Trello and Google Docs, or sharing logins within a team using post it notes or via email.
One trend that I've clearly spotted though is the use of Google Apps to consolidate identity management in the cloud. This is often synced with AD via LDAP. Whenever possible, companies encourage but do not enforce the use of Google for logging into third party services. This makes offboarding a lot easier and that is the main pain point, as opposed to onboarding of new employees. This is further confirmed by SaaS providers saying that they see up to 60% of all their logins being done through Google Apps.
[0] http://www.clickstudios.com.au/
[1]: https://github.com/comotion/cpm [2]: https://github.com/comotion/cpm/wiki/Revision-control [3]: http://gitlab.org/
Simplifies a lot of other things, all you have to remember is the master password.
Plus they've been hacked and proven that provided you use safe passphrasing on your part, your data cannot be comprimised.
There's no good way to share the passwords though... unlogged chat / IM / onetimesecret.com
I generally use 1Password standalone, but it's a bit weak for sharing.
1Password 4 introduces "Shared Vaults"
https://agilebits.com/onepassword/mac#sharing
It's specially designed for companies that manage lots of passwords across lots of projects. It's a self hosted solution.