8

I am working on a system that can connect to any number of different systems. Someone inputs the credentials for a system to connect to, and my system remembers the credentials and uses them to authenticate and communicate with it at a later date (which will happen without user interaction).

All of the other questions like this have the answer "hash hash hash!", but you can see hashing won't work for me as I need to decrypt the password later to connect to the other systems (which are agnostic of mine).

Right now I'm thinking I should dynamically generate a random key for each new system and store it on disk, then store the password (encrypted with a symmetric algorithm) in the database. That way the info in the database alone isn't enough to decrypt the key.

Is that the best I can do?

  • From what I understand, you need a Single Sign One (SSO). You don't need to store the password in your service. Is that web-based or windows form application or both? – Bruno Costa Jan 31 '12 at 16:47
  • It is web-based. Unfortunately I don't have control over the remote sites, and they don't support any form of SSO. –  Jan 31 '12 at 17:48

2 Answers2

4

You are correct if the system you are connecting to can accept nothing but a password as a credential. If this is how the remote system works, it is unfortunately designed, and should be extended if possible to accept some other kind of token. Examples of more appropriate tokens are Kerberos tickets, SSH keys, OpenID credentials, or other custom per-application credentials.

All of the good authentication solutions have something in common: They allow the user to authorize you to connect on their behalf, without having to give you their credentials. A good system allows my administrative assistant to buy airplane tickets on my behalf. It doesn't require my admin to impersonate me.

If however, the remote systems are poorly designed and cannot accept this kind of delegated credential, then you have no choice but to store the passwords. It is traditional in that case to obfuscate the password in your database using some kind of "encryption key and algorithm." (For example, AES encrypting the passwords against a key stored on disk.) This should not be confused with real encryption; it is only obfuscation. But it can be useful obfuscation if you have no other choices.

A better solution than a single password stored on disk is a hardware key that performs the decryption for you. Such a device is often called a Hardware Security Module and often takes the form of a smartcard (sometimes it's a full rack-mounted device, a board, or a USB key). You present the encrypted password to the HSM, and it hands you back the unencrypted password. The advantage of this approach is that if someone clones your disk, they still cannot decrypt the passwords. HSMs are difficult to physically clone, making it much harder for an attacker to steal the credentials without being detected. In the best designs, the process that talks to the HSM has a credential that is hand-entered at boot and is only stored in memory. So random processes cannot query the HSM, and if the machine is unplugged it can no longer access the passwords. Even in this scenario, it is possible that the attacker might trick the system into decrypting all the passwords for him, but the attack surface is greatly diminished.

Rob Napier
  • 296
  • 1
  • 4
0

You should generate an encryption key from the user's password on your system.

This way, no-one can see any passwords unless they already have the user's password.

However, that means you cannot reset user passwords.

SLaks
  • 260
  • 1
  • 2
  • 8
  • Thanks for the reply - but one question: Wouldn't this mean I would have to store the local user's password unhashed? Remember I need to decrypt the remote system authentication data without user interaction. Unless I'm missing something would this shift the security problems to the local users? Thanks –  Jan 31 '12 at 16:39
  • 1
    @user1180510: I hadn't realized you needed unattended decryption. If so, my answer is inapplicable. – SLaks Jan 31 '12 at 16:40