A Security (encryption) Dilemma

Question

I have an internal WPF client application that accesses a database.

The application is a central resource for a Support team and as such includes Remote Access/Login information for clients. At the moment this database is not available via a web interface etc, but one day is likely to.

The remote access information includes the username and passwords for the client's networks so that our client's software applications can be remotely supported by us. I need to store the usernames and passwords in the database and provide the support consultants access to them so that they can login to the client's system and then provide support. Hope this is making sense.

So the dilemma is that I don't want to store the usernames and passwords in cleartext on the database to ensure that if the DB was ever compromised, I am not then providing access to our client's networks to whomever gets the database.

I have looked at two-way encryption of the passwords, but as they say, two-way is not much different to cleartext as if you can decrypt it, so can an attacker... eventually. The problem here is that I have setup a method to use a salt and a passcode that are stored in the application, I have used a salt that is stored in the db, but all have their weaknesses, ie if the app was reflected it exposes the salts etc.

How can I secure the usernames and passwords in my database, and yet still provide the ability for my support consultants to view the information in the application so they can use it to login?

This is obviously different to storing user's passwords as these are one way because I don't need to know what they are. But I do need to know what the client's remote access passwords are as we need to enter them in at the time of remoting to them.

Anybody have some theories on what would be the best approach here?

update The function I am trying to build is for our CRM application that will store the remote access details for the client. The CRM system provides call/issue tracking functionality and during the course of investigating the issue, the support consultant will need to remote in. They will then view the client's remote access details and make the connection

Answer 1

There are a few ways to do this; the best solution will depend on how your support team accesses the clients' sites, how many members belong to the support team, and the architecture of you application.

The best way to do something like this is to use something like Kerberos. This way, members of the support team don't have to be entrusted with the clients' passwords—passwords that they could write down and use later to attack customers. The support team can instantly revoke the access of member without any action by the client.

However, I'm guessing that this is a more dangerous system where team members get a password to access client systems via Remote Desktop, SSH, or something like that. In that case, a great liability is assumed when client passwords are revealed to team members.

Personally, I wouldn't accept that kind of risk. It isn't that I don't feel like I can trust my team, but more that I can't trust my customers. If something happens at their site (or even if they merely pretend that something happened), all of the sudden I'm a suspect. I'd rather design a system where no one can access the customer systems acting alone. This protects the customer from a bad apple on my team, and protects me from false accusations.

Anyway, one approach would be to generate keys for each team member. These could be password-based symmetric encryption keys, but then some secret key must be kept centrally. Better would be to use an asymmetric algorithm like RSA. Then only public keys of team members are kept centrally.

When a new password is received from a client, encrypt it with the public key of each team member that needs a copy. This encrypted password can be stored in the database, and given to a team member each time they request it, or it can be actively pushed out to team members for them to store. In either case, when it is needed, the password is decrypted with the private key held by the team member (in a key store encrypted with a password that they choose).

There are downsides to this. Reiterating the point above, team members get access to the clients password. Are they worthy of this trust? What if the client has a security breach unrelated to this system, but wants to pin the blame on someone? Second, while no decryption keys are stored at the server, trust still needs to be established for the public key of each team member. Otherwise, an attacker could slip their own, rogue public key into the collection and receive passwords that they can decrypt.