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

If you need to retrieve the clear text password from the database then you're going to need to use a 2-way encryption scheme.

Don't put the key into your client application.

This way you can re-encrypt the data / change the key regularly if you're worried about the key being compromised. Though if your key is strong enough and isn't publicly available you should be safe

When sending the passwords over a network connection make sure to use SSL to encrypt the link.

The setup might look like this

client ---> server ---> DB

The server decrypts the the password and passes it over the SSL link to the client.

If you don't have a server and your clients are connecting directly to a DB then you can have your client call a stored procedure to retrieve the plain text password.

Answer 2

This sounds like a scenario DPAPI was designed for. Create a middle tier which can authenticate your clients, and then use DPAPI for encrypting data before storing it in the DB

Answer 3

You don’t need to keep your passwords in the database, just keep a hash of them (SHA1 as example). Then at login time just calculate the hash again and compare it with the sorted one.

Believe me, if you don't have stored passwords there is a lot of weight removed from your shoulders.

Answer 4

Store your passwords encrypted with AES and a good strong key. Instead of embedding the decryption key in the application, give it to your users (the support consultants). Then have your application prompt them for it when they need to look up the information. Not ideal, because everyone uses the same key, but it at least offers some protection if your database ever gets compromised.

Answer 5

A similar situation occurs at our company, where the database administrators wish to maintain a pool of credentials amongst themselves.

I was originally going to post this idea, but erickson beat me to it. However, it may be worth while to post some pseudo code to elaborate, so I suppose my time answering the question isn't completely wasted...

Things you will need:

• A database management system
• An asymmetric cipher (example: RSA):
• A symmetric cipher (example: AES)
• A key derivation function (example: PBKDF2, thanks erickson!)
  • This requires a cryptographic hash function (example: SHA-512)

First off, let's set up the database schema. These tables will be demonstrated shortly.

CREATE TABLE users (
  user_id               INTEGER,
  authentication_hash   BINARY,
  authentication_salt   BINARY,
  public_key            BINARY,
  encrypted_private_key BINARY,
  decryption_key_salt   BINARY,
  PRIMARY KEY(user_id)
)

CREATE TABLE secrets (
    secret_id INTEGER,
    -- WHATEVER COLUMNS YOU REQUIRE TO ACCURATELY MODEL YOUR PASSWORDS (CLIENT INFO, ETC)
    PRIMARY KEY(secret_id)
)

CREATE TABLE granted_secrets (
  secret_id      INTEGER,
  recipient_id   INTEGER,
  encrypted_data BINARY,
  PRIMARY KEY(secret_id, recipient_id),
  FOREIGN KEY(secret_id) REFERENCES secrets(secret_id)
  FOREIGN KEY(recipient_id) REFERENCES users(user_id)
)

Before a user can begin using this system, they must be registered.

function register_user(user_id, user_password) {
    authentication_salt = generate_random_salt()
    authentication_hash = hash(authentication_salt, user_password);

    (public_key, private_key) = asymmetric_cipher_generate_random_key_pair();

    decryption_key_salt = generate_random_salt()
    decryption_key = derive_key(decryption_key_salt, user_password)
    encrypted_private_key = symmetric_cipher_encrypt(
        input => private_key,
        key   => decryption_key
    )

    // IMPORTANT: The decryption_key_hash is never stored

    execute("INSERT INTO users (user_id, authentication_hash, authentication_salt, public_key, encrypted_private_key, decryption_key_salt) VALUES (:user_id, :authentication_hash, :authentication_salt, :public_key, :encrypted_private_key, :decryption_key_salt)")
}

The user can sign in to the system.

function authenticate_user(user_id, user_password)
    correct_authentication_hash = query("SELECT authentication_hash FROM users WHERE user_id = :user_id")

    authentication_salt = query("SELECT authentication_salt FROM users WHERE user_id = :user_id")
    given_authentication_hash = hash(authentication_salt, user_password)

    return correct_authentication_hash == given_authentication_hash

A secret can then be granted to a recipient user.

function grant_secret(secret_id, secret_data, recipient_id) {
    recipient_public_key = query("SELECT public_key FROM users WHERE user_id = :recipient_id")

    encrypted_secret_data = asymmetric_cipher_encrypt(
        input      => secret_data,
        public_key => recipient_public_key
    )

    execute("INSERT INTO granted_secrets (secret_id, recipient_id, encrypted_data) VALUES (:secret_id, :recipient_id, :encrypted_secret_data)")
}

Finally, a user that have been granted access to a secret (the recipient) can retrieve it.

void retrieve_secret(secret_id, recipient_id, recipient_password)
    encrypted_recipient_private_key = query("SELECT encrypted_private_key FROM users WHERE user_id = :recipient_id")

    recipient_decryption_key_salt = query("SELECT decryption_key_salt FROM users WHERE user_id = :recipient_id")
    recipient_decryption_key = derive_key(recipient_decryption_key_salt, recipient_password)
    recipient_private_key = symmetric_cipher_decrypt(
        input => encrypted_recipient_private_key,
        key   => recipient_decryption_key
    )

    encrypted_secret_data = query("SELECT encrypted_data FROM granted_secrets WHERE secret_id = :secret_id AND recipient_id = :recipient_id")

    secret_data = asymmetric_cipher_decrypt(
        input       => encrypted_secret_data,
        private_key => recipient_private_key
    )

    return secret_data

Hopefully this can help. It certainly helped me flesh out my ideas.

Answer 6

If you are worried about giving original user password to consultants then here is a food for thought.

What about generating a temporary password/token exclusively for your support member?

When a customer makes a call, create a token and put it in a map along with the userid. Send this token or encrypted token to your customer support member. Customer support member will then login by using username and token. System check for the token in validtoken map and finds its a valid token and grant access to the system.

Support memeber resolves the problem. Then token is removed from the tokenMap.

In this way you never reveal the original user password to consultants. Thus you can store the user passwords using your own favorite security techniques.

You may encrypt the token using consultant's public key before sending them.

Tokens may given an expiry time.