0

Situation:

  • We have several service accounts (AD) that need to use a limited set of credentials.
  • These service accounts run scripts (PowerShell & Python), etc on different servers, requiring these credentials. These servers all run different versions of Windows Server (2012 - 2016)

Currently the credentials are stored clear text, which is gaping security hole that needs to be fixed.

As we are a Microsoft shop, I initially wanted to opt for DPAPI, but this becomes unwieldy when multiple servers and accounts are used (as you have to store each credential in each combination of vault/server).

The second option was to store the credentials encrypted, on a SMB file share, with NTFS security to limit the accessibility to only the service accounts. The credentials would be encrypted with a certificate, which would be stored in the LocalMachine certificate store of each server. To access a specific credential, the service account would decrypt the file using the certificate.

This seemed like an OK approach:

  • Servers only need to be provisioned with the same certificate (public key is sufficient).
  • Only administrators can access the LocalMachine Certificate Store
  • The credentials are encrypted and stored in a share secured by NTFS permissions.

I then came across a similar implementation as a PowerShell module: PowerShell Credential Vault. The major difference, as far as I can see, is that it stores a randomly generated key, encrypts the credentials (password only) using this key, and then encrypts the key using the certificate. The credentials and the encrypted key are stored together in an XML file.

Is there any advantage over just using the certificate to encrypt the credentials?

1
1

Your approach seems sensible from the point of view that a given server will be able to pull a file (presuming each file has only one password), decrypt it and extract a password. Knowing that other servers will be able to pull the same file but won't be able to decrypt it. And whoever holds the set of public keys will be able to decrypt the files if they can extract them.

There's caveats that you should be aware of however:

  • Trusting that only local admins can access the certificate is simplistic. For example if the file system can be read off a snapshot or by cloning a VM or in some other way outside of the environment of the running server, this information will be accessible and the code tasked with pulling the file and decrypting the password will be visible;

  • The way the actual password is handled on the server will dictate how much of it is left behind in memory or on the registry, etc. This would include decrypting the file [left in memory or on the file system], running the task that uses the password [password shown in cmd line and left in memory whilst and after the process terminates], closing/deleting the decrypted file [left behind on the file system], etc;

  • Passwords are also exposed at the time of encryption, where all the information is (very likely) available to obtain the password, decrypt the file and possibly extract all keys and decrypt all files to extract all passwords;

All these things, depending on how you implement the details of the system, could have a manageable risk. It's entirely up to you and your business to measure and assess what's acceptable.

Generally, unless you run a very careful audit of the code that implements the powershell module, I'd be wary of using it to handle sensitive data. The chances of it being broken or easily hackable will vary from very low to trivial, so until you know, I'd err on the side of caution and assume it is trivial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.