Shared Password Management

[dscherertfm]

One of the things Snipe-IT is "missing" is the ability to manage and assign shared passwords. We currently store these in a password protected excel sheet and users who have access to a password are basically sent the password in an E-mail and they then have to store it.

Being able to setup services with passwords stored (encrypted in the database :) ) would basically make Snipe the piece de resistance (my French sucks) of asset management. I've only found one other system that does everything Snipe does as well as manage shared passwords, but it's hella expensive and difficult to convince management to shell out money for something because "excel sheets work". This is why I went OSS (plus the ability to customize it a bit once I get a chance without rolling it entirely on my own).

So when I assign a shared password to a user, they could then click a link and have it decrypted and saved on their clipboard or something. A feature like this would be incredibly useful for possibly a lot of companies as I imagine shared passwords for some sites/accounts are not uncommon. It's likely also not uncommon for IT teams to have no clue who really has access to what and what passwords should be changed following an employee being off-boarded.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[snipe]

What kind of shared password are you talking about? That's not really what Snipe-IT was built to do, and if it were to be done securely, introduces more complexity to the system. Seems like something like Mitro (although they're shutting down) or Passwork would make more sense there.

[dscherertfm]

Well, having everything in an excel file and dishing out passwords without a good way of keeping track of who has been given what isn't exactly secure. This is something I would expect (hope) people would only use when running the system behind a local network and firewall. Having everything in one place, and keeping it on-prem, is the goal for me. We've been moving toward authenticating all internal apps with active directory because everyone's excuse for not doing something was they couldn't login, and getting them to remember they need to use their windows username and password to login to stuff is difficult (for some reason telling everyone to login like you login to your computer makes them think they need to use their email address, I don't get it).

I'm trying to reduce complexity by managing as much as possible in one place. Honestly, in my use case where Snipe is running on our local network and behind a firewall with only myself having direct database access I could care less if the passwords were stored plain text. If someone gained access to our network it would take an idiot 20 minutes with a piece of OSS pasword cracking software to get access to all of the excel files that currently hold these passwords, or the unprotected excel files that users are likely storing the passwords they've been given it, or if someone walked into their office and found them on sticky notes.

At least having them in Snipe means I can audit who has access to what, what passwords absolutely need changed when a user leaves the company, etc.

Basically anything is going to be better than what we're doing now, I'm just reluctant to introduce another system that not do I need to maintain, but users need to remember how to get to and login and all that. Am I making sense or have I just started to ramble?

[dscherertfm]

The specific types of passwords range from access to the shared WebEx account we use for screen sharing sessions to train clients and do demos to our carrier accounts where we login to get spot quotes for volume shipments and download client invoices and process claims on behalf of our customers. We have a lot of shared accounts, most of which are pretty trivial. Some applications we bought for whatever reason only have 1 admin login that needs shared by a few different people to do certain things. That kinds of stuff.

[snipe]

Well, you might be okay with storing passwords in cleartext, but I'm not. Someone will get pwned, and my software will carry the blame. You might use it only for trivial accounts, but other users will use it for root access to their production servers and other crazy stuff. As much as I like being in the news, I'd prefer not to end up there that way. We would need to be able to handle this securely, or not at all.

[dscherertfm]

I don't have a problem with encrypting the passwords, there are a few great libraries that exist in PHP for doing this and doing it the correct/most secure way. At some point however, the user has to accept responsibility for their actions and realize there's only so much a software vendor (OSS or otherwise) can do to keep their data secure. Obviously Snipe can handle encryption, but it's up to the user to make sure they're using these features in a secure environment especially if they're going to be storing passwords that grant root access to production servers. However, nobody should have password authentication turned on for their root accounts and should be issuing public/private key pairs in addition to restricting shell access to the local network or VPN.

Chances are, their root passwords are already stored in excel files which are probably protected with a horribly inadequate password that can be guessed extremely quickly, which isn't much better than storing it in plain text. At least my mysql Servers are heavily locked down with full disk encryption and our intranet sites use HTTPS. It would take someone a significantly longer time to gain access to my MySQL server than it would to gain access to our excel files.

I understand your point though, however there's only so much security you can bake into Snipe before it's up to the user to lock it down.

[snipe]

I work in information security, and present on it in conferences all over the world. I cannot encourage or even facilitate poor security practices, and still sleep the few, frantic hours I sleep at night.

[dbiers]

There's plenty of other apps that already do this. I would recommend Vaultier (https://www.vaultier.org/) as it's pretty easy to use.

I have tried Teampass (http://www.teampass.net/) but I have experienced a multitude of issues with it.

[ESWBitto]

@dscherertfm you could try keepass enterprise edition. I believe you can use one encrypted database on possibly a shared drive or folder within your network and then install the app locally on each workstation. From there you just point to the "shared" database.

[dscherertfm]

I'm aware of many of the password management solutions out there, I use some of them for storing my own passwords both at work and at home, however we have an incredibly small group of people who deal with IT/IS (and we all wear all the hats). So having yet another system that needs to be maintained, in addition to the flagship products we develop (which get priority since they cannot be down for even a second, ever), is both a logistical and training obstacle. I still have users who cannot figure out how to accomplish the apparently endlessly complicated task of logging into portal.office.com from home to check E-mail or install office at home. Adding yet another place they need to remember to login to, and how to get there, and what their credentials are (because even if they're AD credentials, they still somehow forget) is going to be an endless PITA. I support a herd of idiots each day.

What we do now, quite possibly along with about a million other companies, is store this stuff in excel files which isn't exactly security at it's finest. I'm not proposing this be used to store root passwords to servers (mainly because root passwords to servers should not exist) though I don't deny there's that one person who would try, and might even get pwned (but his password was probably temp123! to root accessible over 22 on the public network anyway). Encrypting the passwords being stored, and doing it all securely is great, but the people installing and maintaining the system also need to be aware there are things they need to do too, and this applies for any on-prem solution you would download and install. A healthy "Don't be a fool" banner for this feature wouldn't be unwelcome.

[snipe]

I too support a herd of idiots each day.

My point is that if we could not find a way to handle this securely (that would still be easy enough to install that it wouldn't quadruple the number of support tickets I have to manage), it's not going to happen. I will not maintain an app that facilitates or encourages bad practices. It's that simple.

[dscherertfm]

For the sake of keeping things easy to install, the encryption key could be stored in an environment variable or file outside the web root, and for the feature to be activated force HTTPS connections. Beyond this and implementing an actual Key server and going full on PCI-DSS, I'm not sure how much more secure you can make it. At the end of the day the user needs to be aware of how they will use the feature and take the steps they feel are necessary to secure the environment they're hosting this in. Providing a guideline for maintaining a secure system could be helpful as well.

There are some other models that could also be fairly simple for an end user to setup during the install, but this seems pretty straight forward and effective. At the end of the day, if they get root access to the server you're pretty much screwed either way, even if the passwords were stored in another purpose-built system or an excel file as the encryption key/password is going to be found eventually.

Does this meet your requirements of security and simplicity, or am I misunderstanding?

[mdaniels5757]

IMHO, the app should focus on its core function: asset management. I would have that perfected before branching out. That said, vault could help with some of the security considerations for the backend.