How do you handle password in your code ?

[cramaboule]

Hello,
I have several scripts that has password in it. Like:
 

Run(@ComSpec & " /c " & '"C:\Program Files\PuTTY\plink.exe" -ssh -pw Pa$$w0rd administrator@192.168.1.1','', @SW_HIDE)

$sUsername = 'administrator'
$sPassword = 'Pa$$w0rd'

How do you handle password? because it is in clear in a "text" file.
or
Do you have some idea for more security ?

Thanks in advance.

C.

[ioa747]

the easiest but not the safest
Just to hide it from prying eyes
 

$sUsername = 'administrator'
;~ $sPassword = 'Pa$$w0rd'
;~ $sPass = StringToBinary($sPassword, 4)
;~ ConsoleWrite("$sPass=" & $sPass & @CRLF)
$sPass="0x5061242477307264"
ConsoleWrite("$sPassword=" & BinaryToString($sPass, 4) & @CRLF)

 

[cramaboule]

Quote

the easiest but not the safest
Just to hide it from prying eyes

Not bad

Edited yesterday at 09:19 AM by cramaboule

[SOLVE-SMART]

Hi @cramaboule 👋 ,

there are several criteria with different answers "it depends" 😁 .

1. Is your code public or private (in a repository)?
2. Runs your code/program only locally or on different machines?

If it's public, never use passwords, salts or other secrets in code directly.
Use the secret management of GitHub/GitLab (or other platforms).
Or use environment variables to store the secrets (but again, make sure the secrets are encrypted separately there).

If your code only runs on your machine locally, also use env vars or registry entries.
The way @ioa747 suggested, masking the secret (something like obfuscation) is "okayish" for local, private usage (in my opinion).
But for all other scenarios avoid secrets in code.

Best regards
Sven

Edited yesterday at 10:53 AM by SOLVE-SMART

[cramaboule]

5 minutes ago, SOLVE-SMART said:

Hi @cramaboule 👋 ,

there are several criteria with different answers "it depends" 😁 .

1. Is your code public or private (in a repository)?
2. Runs your code/program only locally or on different machines?

If it's public, never use passwords, salts or other secrets in code directly.
Use the secret management of GitHub/GitLab (or other platforms).
Or use environment variables to store the secrets (but again, make sure the secrets are encrypted separately there).

If you code only runs on your machine locally, also use env vars or registry entries.
The way @ioa747 suggested, masking the secret (something like obfuscation) is "okayish" for local, private usage (in my opinion).
But for all other scenarios avoid secrets in code.

Best regards
Sven

Hi @SOLVE-SMART,

Well, some code are only for me, some other are on my network or on servers running here and there...
Obviously, I won't make any sensitif info on Github public...
--> Use the secret management of GitHub
--> secrets are encrypted separately
more info on those?

[argumentum]

..I use an ini file with the crypt* functions. The decrypt part takes creativity. I use some string as "salt" plus the date-time of creation of said ini file in UTC but, shhhh, that's my secret

Again, my secret is creativity. Then again, just like you, these scripts are not for the public.

Edited yesterday at 09:41 AM by argumentum

[Jos]

Just to be clear: Whatever you do, the shell command requires the clear text password, so by definition no solution will be safe! 🙂
 

[cramaboule]

3 minutes ago, Jos said:

Just to be clear: Whatever you do, the shell command requires the clear text password, so by definition no solution will be safe! 🙂
 

Obviously... but I do not want the clear pw in my code.

[cramaboule]

7 minutes ago, argumentum said:

..I use an ini file with the crypt* functions. The decrypt part takes creativity. I use some string as "salt" plus the date-time of creation of said ini file in UTC but, shhhh, that's my secret

Again, my secret is creativity. Then again, just like you, these scripts are not for the public.

Hummmmm good idea ! will look at it !

C.

[argumentum]

Exit CmdLineDetails()
Func CmdLineDetails($sName = "plink.exe") ; run as admin
    Local $sRun = @ComSpec & " /c powershell ""Get-CimInstance Win32_Process -Filter \""name = '" & $sName & "'\"" | Select-Object Name,ProcessId,CommandLine,CreationDate | ConvertTo-Json"" "
    ConsoleWrite($sRun & @CRLF)

    Local $hTimer = TimerInit(), $iPid = Run($sRun, @SystemDir, Default, $STDOUT_CHILD)
    ConsoleWrite($hTimer & @CRLF)
    ProcessWaitClose($iPid)
    Local $sJSON = StdoutRead($iPid)
    ConsoleWrite($sJSON & @CRLF)
EndFunc

Like Jos said, the way that is running is not that safe anyway. But yes, keep passwords safe.

[argumentum]

..the "salt" could be a hash of a password you enter before loading whatever. Then while that's running ( the script you entered the password to ), your other scripts can ask via IPC what's the salt. ( an idea that just pop into my head now )

Edited yesterday at 09:54 AM by argumentum

[orbs]

one way would be to use it as intended: do not store the password in your script, instead have your script ask you for the password (via inputBox() for example). this is feasible when you don't need to do it too often. if you do, you can streamline the process by using an external password manager (KeePass for example), which can automatically insert the password when prompted.

but that's not how i would go about this.

i'd consider storing the username and password in the built-in Windows Credential Manager. you can query it to retrieve the credentials, and have your code insert them where required.

now, of course if a malicious actor gains access to your environment, any and all methods suggested are compromised. so i'm assuming the purpose is to prevent someone from discovering your password if all they have is the contents of your script.

P.S. if you compile your script to executable, that's the first barrier you can put against prying eyes. if those eyes belong to your over-the-average-curious end user, that should throw them off.

[cramaboule]

20 minutes ago, orbs said:

one way would be to use it as intended: do not store the password in your script, instead have your script ask you for the password (via inputBox() for example). this is feasible when you don't need to do it too often. if you do, you can streamline the process by using an external password manager (KeePass for example), which can automatically insert the password when prompted.

but that's not how i would go about this.

i'd consider storing the username and password in the built-in Windows Credential Manager. you can query it to retrieve the credentials, and have your code insert them where required.

now, of course if a malicious actor gains access to your environment, any and all methods suggested are compromised. so i'm assuming the purpose is to prevent someone from discovering your password if all they have is the contents of your script.

P.S. if you compile your script to executable, that's the first barrier you can put against prying eyes. if those eyes belong to your over-the-average-curious end user, that should throw them off.

Of course when possible, I'd ask password in inputbox,... but for servers who runs script unattended,... it is a bit more complicated !
Of course, exe, is the first barrier, but I always save my au3 files obviously.

Will see the Windows Credential Manager

[rudi]

For a task to backup the config of some 70+ switches I wrote an autoit script, that doesn't hold the password, but it's SHA256 hash.

When the script is triggered, it's asking for the password and comparing the calculated SHA256 of the given password against the value stored inside the script.

As SHA256 cannot be decoded, you can proof, that the right password was entered, without storing the password in the code itself.

 

#include <AutoItConstants.au3>
; *** End added by AutoIt3Wrapper ***
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Res_Description=Alle Cisco Switches die Config sichern auf H:
#AutoIt3Wrapper_Res_Fileversion=2.3.0.15
#AutoIt3Wrapper_Res_Fileversion_AutoIncrement=p
#AutoIt3Wrapper_Res_LegalCopyright=2016 - 2024 (c) by Rudolf Stang, IT-Beratung Rudolf Stang
#AutoIt3Wrapper_Res_SaveSource=y
#AutoIt3Wrapper_Res_Language=1031
#AutoIt3Wrapper_Add_Constants=n
#AutoIt3Wrapper_Run_Au3Stripper=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#include <date.au3>
#include <Debug.au3>
#include <array.au3>
#include "Crypt-mit-SHA256.au3" ; originale CRYPT.AU3, lediglich oben das Auskommentieren für SHA_256 entfernt. Muss * NEBEN * diesem Scirpt liegen("")

; [snip]

$PW_hash= "0x1D3965422171<snip>" ; SHA_256

Do
    $PWD = InputBox("Running-Config's sichern", "Switch Kennwort für Root?", "", "*")
Until $PWD <> ""
_Crypt_Startup()
$Hash_Input = _Crypt_HashData($PWD, $CALG_SHA_256)
If $Hash_Input <> $PW_hash Then
    ClipPut($Hash_Input)
    MsgBox(64, "Falsches Kennwort", "Sie haben sich vermutlich beim Kennwort vertippt, der SHA256 Hash passt nicht!", 10)
    Exit
EndIf
_Crypt_Shutdown()
#EndRegion Kennwort

pls use deepl yourself to translate the German phrases to you preferred language.

[cramaboule]

42 minutes ago, rudi said:

For a task to backup the config of some 70+ switches I wrote an autoit script, that doesn't hold the password, but it's SHA256 hash.

When the script is triggered, it's asking for the password and comparing the calculated SHA256 of the given password against the value stored inside the script.

As SHA256 cannot be decoded, you can proof, that the right password was entered, without storing the password in the code itself.

 

#include <AutoItConstants.au3>
; *** End added by AutoIt3Wrapper ***
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Res_Description=Alle Cisco Switches die Config sichern auf H:
#AutoIt3Wrapper_Res_Fileversion=2.3.0.15
#AutoIt3Wrapper_Res_Fileversion_AutoIncrement=p
#AutoIt3Wrapper_Res_LegalCopyright=2016 - 2024 (c) by Rudolf Stang, IT-Beratung Rudolf Stang
#AutoIt3Wrapper_Res_SaveSource=y
#AutoIt3Wrapper_Res_Language=1031
#AutoIt3Wrapper_Add_Constants=n
#AutoIt3Wrapper_Run_Au3Stripper=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#include <date.au3>
#include <Debug.au3>
#include <array.au3>
#include "Crypt-mit-SHA256.au3" ; originale CRYPT.AU3, lediglich oben das Auskommentieren für SHA_256 entfernt. Muss * NEBEN * diesem Scirpt liegen("")

; [snip]

$PW_hash= "0x1D3965422171<snip>" ; SHA_256

Do
    $PWD = InputBox("Running-Config's sichern", "Switch Kennwort für Root?", "", "*")
Until $PWD <> ""
_Crypt_Startup()
$Hash_Input = _Crypt_HashData($PWD, $CALG_SHA_256)
If $Hash_Input <> $PW_hash Then
    ClipPut($Hash_Input)
    MsgBox(64, "Falsches Kennwort", "Sie haben sich vermutlich beim Kennwort vertippt, der SHA256 Hash passt nicht!", 10)
    Exit
EndIf
_Crypt_Shutdown()
#EndRegion Kennwort

pls use deepl yourself to translate the German phrases to you preferred language.

thanks... it is good if you prompt with inputbox... but in my case it is silent running script... thus making somehow clear and encrypted

 

[RTFC]

https://www.autoitscript.com/forum/files/file/491-codescannercrypterbundle/

[Somerset]

Write an eula for the end user; that they have to cover their eyes when executing the binary?

[rudi]

You can use the windows credential manager as a tool to hide (not to protect) your password.

https://sites.utexas.edu/glenmark/2019/10/21/using-passwordvault-with-powershell/

basically either your password is valuable: Then it has to be entered each and every time, it is used, and there is no way around the fact, that it must not be in your code.

Or your password is not that important. Then you can put it into your code, but you have to be aware, that it's not safe any more.

[Werty]

6 hours ago, cramaboule said:

for servers who runs script unattended

Then why not use a hardware serial like baseboard serial so the program can only be run on that machine.

Edited yesterday at 05:25 PM by Werty

[BigDaddyO]

I have to use passwords in a lot of my scripts.

I have an SQL server where each script has it's own database where I store passwords as an encrypted string along with any other config/test/log data.  I also only allow specific users access to that database via AD.  The decryption keys are also unique to each script.

This lets me keep passwords secure and lets me control who can access my apps as if the database connection fails then the app closes with a message to contact me for access.

Edited 23 hours ago by BigDaddyO