Powershell, How to store your credentials

The first step working with automation and PowerShell is completing an authentication process against a remote server and providing the right credentials. In the previous article our aim was to raise the awareness of how SecureString can be used in a very unsafe way, now we simply would like to show you what to avoid and how to store your credentials.

Three things to avoid:

  1. [always] clear text passwords It’s obvious. Think that you source code and software development is always evolving and maybe one day your local repository of code will be managed differently thru a proper development pipeline. The first steps towards should be implementing source-code management, quality assurance, testing or simply published to GitHub and your precious secrets too. Malicious software can harvest hard-drives and file shares looking for credentials. Other users with less privileges can maybe execute the script and read the file and access to your secrets. So on and so forth..
  2. [if possible] security thru obscurity
    What seems a good idea is making clear text password or strings not human readable or just more obscure is most of the time counter-productive. If you think about it this is also popular technique used by attackers with powershell or javascript exploits.
    In short: obscurity is not a recipe for security and can generate false positive results when looking for malicious code and just delay of few minutes an attacker.
    Please have a look at this example:

  3. [if possible] store passwords in the registry

More secure than store the credential in clear text in your source code, but the registry is always accessible by any users and application and the references in your source code to the registry key (HKCU, HKLM) are easy to find out.

How to store your credentials

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API . This ensures that only your user account can de-crypt the contents of the credential object.

Is this method bulletproof? No, within the same user session can be considered a trivial exercise to decode the credential.

How to manage credential under different user session/context

Can became a quickly convoluted, but I suggest you to use a KEY (a new password) to encrypt your secret :

Now your key is another password to store in a secure place.


Protect credential is a very delicate task and most of the time very difficult to achieve. Whenever possible prefer an interactive method. Clear your cached credential from your session as soon is not required any more.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.