Unable To Detect Hardcoded Password

[Vivek2406]

Hi Team,

I tried to run below command to get hardcoded password detected by tool. However tool could not detect it. Please Refer output file and input script file attached in zip file. Could you please advise why tool could not detect the password stored in the variable named 'password_test2' and how can we solve this problem?

Command: Invoke-ScriptAnalyzer -Path .\Sample_PowerShellScript_WithHardcodedDummyPassword.ps1 | Export-Csv -Path ".\ouput_for_sample_script.csv" -NoTypeInformation

Sample_PowerShellScript_WithHardcodedDummyPassword.zip Sample_PowerShellScript_WithHardcodedDummyPassword.zip

Thank and Regards,

Vivek Maurya

[liamjpeters]

Hey @Vivek2406 👋,

From your code:

Write-Host "Hello, World!"
$password_test2 = "dummyPassword"
# Prompt the user for input
$password = Read-Host "Enter your input:"

# Display the user's input
Write-Host "You entered: $password"

It looks like you're expecting PSSA to flag that a variable, the name of which contains the word password, is being assigned a string? Is that correct?

As far as I know, there is no rule which currently exists to detect this within PSSA.

The closest rule is AvoidUsingPlainTextForPassword which is focused on script/function parameters.

It relies on people using the enumerated list of words ("Password", "Passphrase", "Cred", "Credential") in their parameter names (so $Psswd would not be picked up for instance), and hoping that those words do not appear within parameter names which should not be flagged. You could never make the list exhaustive or complete.

For instance the below 2 parameters are both flagged:

function MyFunc {
    param (
        [string]
        $NotAPasswordIPromise,
        [string]
        $CreditAmount
    ) 
}

If you felt strongly about it, you could open this issue up for discussion with the wider community to gather other opinions - and then, if it's likely to be of benefit, put a PR together to get the rule in.

Personally, I think this would be susceptible to the same false-positive and false-negative issues as with the current AvoidUsingPlainTextForPassword rule - but on a larger scale.