PSAvoidUsingConvertToSecureStringWithPlainText shouldn't always be flagged by PSGallery.

I have a module that I just Published that was flagged by the PSGallery. The issue encountered is PSAvoidUsingConvertToSecureStringWithPlainText. While I understand why this rule is in place, and I have [SecureString] parameters in this module where it makes sense, but blanketing it over everything is problematic and can actually hurt security rather than improve it.

My module encrypts the user's AccessToken/ApiKey using PBDKF2 with a Password and Salt and stores it in an AppData folder. The AccessToken is a [string] supplied by the user. It is being encrypted in a file for later use, and then is loaded into a new session via a command to decrypt the key and do a few other things before the other commands in the module can be used. Below is the portion that got flagged.

        $SecureKeyString = ConvertTo-SecureString -String $AccessToken -AsPlainText -Force

        # Generate a random secure Salt
        $SaltBytes = New-Object byte[] 32
        $RNG = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
        $RNG.GetBytes($SaltBytes)

        $Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList 'user', $MasterPassword

        # Derive Key, IV and Salt from Key
        $Rfc2898Deriver = New-Object System.Security.Cryptography.Rfc2898DeriveBytes -ArgumentList $Credentials.GetNetworkCredential().Password, $SaltBytes, 10000
        $KeyBytes  = $Rfc2898Deriver.GetBytes(32)

        $EncryptedString = $SecureKeyString | ConvertFrom-SecureString -key $KeyBytes

        $ConfigName = 'api.key'
        $saltname   = 'salt.rnd'

        if (!(Test-Path -Path "$($ConfigPath)"))
        {
            New-Item -ItemType directory -Path "$($ConfigPath)" | Out-Null
        }

        Write-Verbose -Message "Saving the information to configuration file $("$($ConfigPath)\$ConfigName")"

        "$($EncryptedString)"  | Set-Content  "$($ConfigPath)\$ConfigName" -Force

        # Saving salt in to the file.
        Set-Content -Value $SaltBytes -Encoding Byte -Path "$($ConfigPath)\$saltname" -Force

In this circumstance, what added benefit does requiring a SecureString give when the value needs to be available as a string when used via the API this module is invoking. It being used via ConvertTo-SecureString as plain text doesn't really change anything since it already needs to be used as plaintext. What it is trying to protect is when the key is stored in a file.

I think this is an area you have to be careful. If you push too hard and flag things like this, people will just avoid attempting to secure something and just say stick it in plaintext somewhere.

You can see in the below example, where if I just avoided encryption altogether, I likely wouldn't have been flagged.

Publish-Module [-FormatVersion [<Version>]] [-IconUri [<Uri>]] [-LicenseUri [<Uri>]]
    [-NuGetApiKey [<String>]] [-ProjectUri [<Uri>]] [-ReleaseNotes [<String[]>]] [-Repository
    [<String>]] [-RequiredVersion [<Version>]] [-Tags [<String[]>]] -Name <String> [-Confirm]
    [-WhatIf] [<CommonParameters>]

I just wanted to point this out [-NuGetApiKey []]

I wanted to get a little clarification on this, and maybe see where I can get a list of Tests that are ran via PSGallery so I can run them during my Tests before I reach this point. This code came from Carlos Perez who said I could adapt it to my module. He has multiple modules with this exact usage in the PSGallery and never had issue or has had them flagged.

Commencez par localiser l’implémentation et les tests existants pour PSAvoidUsingConvertToSecureStringWithPlainText, puis comparez la manière dont PSGallery invoque l’analyseur. Définissez une distinction reproductible entre la conversion non sécurisée et la conversion intentionnelle de texte en clair, et ajoutez une couverture de tests ; le travail est terminé lorsque le cas signalé est pris en charge sans affaiblir les findings réellement non sécurisés.