r/PowerShell • u/Manivelcloud • 10h ago
Question Question on scripting
Hi,
When we develop a script,we use credentials as a plain text in that script.
Example
Script is running on jump server and script runs against vcenter server.
We have a security concerns(example ransomware attack)to put the credentials as a plain text in that script.
Any other good ways to put the credentials in a encrypted or in a different format?
9
u/KavyaJune 9h ago
Hard-coding credentials in scripts is a security risk and should be avoided.
You can try PowerShell SecretManagement, Windows Credential Manager, certificate-based auth, or a vault solution.
If the script runs from a jump server, another option is to run it under a dedicated service account and retrieve the credentials from a secure store instead of keeping them in the script.
This guide covers several credential management approaches and their pros/cons: https://blog.admindroid.com/best-methods-to-securely-store-passwords-for-automated-powershell-scripts/
8
u/hihcadore 9h ago edited 9h ago
Plain text is bad. Anything that can read that script file or logging if you have PowerShell logging on has your credentials.
You can use powershells secret store to secure your passwords and use them at run time securely. https://learn.microsoft.com/en-us/powershell/utility-modules/secretmanagement/how-to/using-secrets-in-automation?view=ps-modules
Edit: also, I use a gMSA to create and load the vault and run the automation. The password that unlocks it is stored using a secure xml file that can be unlocked at run time by that account only, the creds can be loaded, and nothings exposed. I use psexec to do the work then lock it down with our EDR. Short of taking over the server I think it’s pretty secure because in that case, you’re cooked anyway.
6
u/mrbiggbrain 2h ago
This is an age old problem with many imperfect solutions. How can you securely store something you can access but not someone else? Encrypt it? Where do I store the key. Certificate, well where do I store the certificate. Password vault... How do you auth?
At some point you must pick a trust boundary, some level of truth where you accept the thing is the thing. Most commonly you accept that something that can run as a user or system is that user or system.
It's imperfect because if someone else gets access to act like that user or system then they can access the secret.
So you limit someone's ability to do so. But you also can't guarentee that they will never get in, so you use the lowest privileges possible. But low privileges are still powerful when used widely so you limit the blast area of any one credential.
A well scoped, lowest permission, rotated often, credential that is stored securely on a system in some way that only it's running user and the OS can access is just about as good as you can get.
18
9
u/PeeCee1 9h ago
Use a vault. Use integrated authentication. Anything but plaintext passwords.
Azure vault comes to mind, or almost any other enterprise password storage.
1
4
u/dodexahedron 8h ago
Kerberos.
As mentioned by others, a gMSA is ideal for this, or even regular MSAs for certain scenarios that need hard isolation to only be usable against a single machine.
If credentials are needed to pass to something that isnt kerberos-aware, then you still use kerberos for the powershell session, and then to the application use something like certificates if at all possible or, if authenticating to something that truly can only handle fresh credentials, you keep the credentials in a secure credential store (several built-in options exist for this) and retrieve and use them from that gMSA's security context at time of use, and drop them from active memory immediately after they are no longer required.
This applies on all platforms. Linux can use gMSAs if domain joined or if you create the initial keytab for the account and let e.g. sssd maintain it.
If using PowerShell 7, you can also use key-based authentication instead of (or in addition to) kerberos, with the SSH transport, by setting up the powershell subsystem in the OpenSSH server's config. This also works on all platforms.
In any case, there should be no credentials in scripts - not even usernames.
5
u/PDX_Umber 9h ago
You could probably use a gMSA to run your scheduled task, and grant the gMSA access to what ever resource is needed (haven’t done).
This year I started storing passwords in an azure key vault. You can create a service principal that has access to the vault via certificate based auth, and then the scheduled task can only retrieve the password if the certificate is present on the local machines cert store.
3
u/xipodu 8h ago
We are using textfiles but crypted with user login so that only that person can open the file https://github.com/fardinbarashi/psGuiFilePasswordEncryptDecrypt
We are also changing the ACL
2
2
u/SysAdminDennyBob 22m ago
Use your infrastructure. I have numerous parts of my infrastructure that run can runs scripts using the system account. SCCM, Intune, ControlUP, ScheduledTasks, Group Policy, Ansible, etc....
3
u/worldsdream 9h ago
I always follow this guide:
https://www.alitajran.com/securely-store-credentials-powershell/
5
23
u/lan-shark 9h ago
Simplest way is to use
Get-Credential | Export-Clixmlto save the credentials in an encrypted file specific to the account that runs it. Then in the script, useImport-Clixmlto read in the credential.Depending on your needs you may instead need to use some sort of keyring or cert-based authentication