https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/security/SecureStringHelper.cs#L449

Seems to be CoreCLR that is lacking.

Talked @KrishnaV-MSFT This is not needed for Azure demo. Moving it out of Alpha.10

Came across the same error on MacOS 10.12 Beta (16A270f)

Was just messing around got this:

PS> $User="Jared"
PS> $PWord = ConvertTo-SecureString –String "TestString" –AsPlainText -Force   
PS> $Cred = New-Object -TypeName "System.Management.Automation.PSCredential" –ArgumentList $User, $PWord
PS> ConvertFrom-SecureString -SecureString ($Cred.Password)

Result:

ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:1
+ ConvertFrom-SecureString -SecureString ($Cred.Password)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringComman

Hi,

same library error when trying to use mapped cert: psdrive:

Get-ChildItem Cert:/LocalMachine/

Error:

get-childitem : Unable to load DLL 'crypt32.dll': The specified module could not be found.
(Exception from HRESULT: 0x8007007E)
At line:1 char:1

• get-childitem Cert:/LocalMachine/

• - CategoryInfo          : NotSpecified: (:) [Get-ChildItem], DllNotFoundException
  - FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.GetChildItemCommand
  

@35359595 good finding! The error definitely should be friendlier. On Linux and macOS Cert:/ provider needs some re-thinking. The way these two systems approach storing certificates are completely different from each other and windows.

Fyi, 16.04.1 with PowerShell v6 alpha 14 still has this same issue

This is holding me back from bringing my modules over to Linux. I'd like to be able to store Web API keys securely on all OSes, not just Windows.

This is something we'll only be able to enable with the .NET Standard 2.0 APIs that bring back SecureString:

• CoreFX Issue: dotnet/corefx#13062
• CoreFX 2.0 PR: dotnet/corefx#13362

ConvertFrom-SecureString and ConvertTo-SecureString depend on System.Security.Cryptography.ProtectedData, which is still not available in netstandard2.0.
So these 2 cmdlets need to be re-worked on Unix platforms.

Until this gets fixed, here's code to securely pass a credential to a background job:

$credentialKey = New-Object 'byte[]' (256/8)
$rng = New-Object 'Security.Cryptography.RNGCryptoServiceProvider'
$rng.GetBytes($credentialKey)

$serializableCredential = [pscustomobject]@{ 
                                                UserName = $credential.UserName;
                                                Password = ConvertFrom-SecureString -SecureString $credential.Password -Key $credentialKey
                                            }

$job = Start-Job {
    param(
        [Parameter(Mandatory)]
        [byte[]]
        $Key
    )
    $serializedCredential = $using:serializableCredential

    $password = ConvertTo-SecureString -String $serializedCredential.Password -Key $Key
    $credential = New-Object 'PSCredential' ($serializedCredential.UserName,$password)
    [Array]::Clear($Key,0,$Key.Length)
} -ArgumentList (,$credentialKey) | Wait-Job | Receive-Job

[Array]::Clear($credentialKey,0,$credentialKey.Length)
   

Password = ConvertFrom-SecureString -SecureString $credential.Password -Key $credentialKey

how is this supposed to work if this has an issue itself?

anyways, tried your script though but got error:

ConvertFrom-SecureString : Cannot bind argument to parameter 'SecureString' because it is null.
At /home/myusername/powershell.ps1:7 char:99
+ ... = ConvertFrom-SecureString -SecureString $credential.Password -Key $c ...
+                                              ~~~~~~~~~~~~~~~~~~~~

so i tried to define username and password in a variable but:

ConvertFrom-SecureString : Cannot bind parameter 'SecureString'. Cannot convert the "testpassword" value of type "System.String" to type "System.Security.SecureString".

Why there is no separate issue for passing secure string over psremote? All opened issues closed as duplicates of this. In my opinion problem is different.
PSRemote hangs during key exchange due to lack of CryptoAPI implementation on Linux.
Who interested it hangs here

Some good news there is crossplatform workaround.
Workaround for PSRemoting
Use python fresh implementation of PSRP pypsrp it supports securestrings!

@KKomarov Please open new issue with repo steps and your suggestion.

@KKomarov the hang has been fixed in PSCore6.2-RC as part of #8723 already. The ability to actually send secure strings over for non-Windows should be a separate issue.

DE0001: SecureString shouldn't be used
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001-securestring-shouldnt-be-used

@iSazonov

DE0001: SecureString shouldn't be used
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001-securestring-shouldnt-be-used

While that's nice in a perfect ivory tower world, in Powershell we are constantly gluing things together and that requires authenticating in whatever format that application requires, be it rest API, legacy application that only supports Basic authenticaiton, etc. We can't just simply "use windows credentials or certificates" for everything as this recommendation states, that's a nice recommendation for developing a new app, but not what we use powershell for.

It's not like PSCredential is going anywhere which is an implementation of SecureString, so until we have something in .net core that can use a TPM to encrypt keys or something, we need a "good enough" option.

Something like using AES256 and having the encryption key be a 600 permission-ed file on the non-windows file system is a possible start, not much worse than using the Crypto API in Windows

I added the link for information only.

Essentially:

1. It is impossible to port SecureString because System.Security.Cryptography.ProtectedData is Windows-only. There is no plans to port the API. Core team deprecate the API.
2. We can keep backward compatibility for SecureString on Windows (including remoting)
3. PowerShell Core must remain flexible and allow to work with legacy applications.
4. It is acceptable to use basic authentication in protected environment
5. Main problem how to detect protected environment vs public environment and what to do (prevent basic authentication, only warn, ...).

Early on, the @PowerShell/powershell-committee discussed introducing a SensitiveString to replace the functional need of SecureString even though both are not secure (the SecureString type would still be needed for backwards compat). A type (whether "Sensitive" or "Secure" is needed to indicate to PowerShell to prompt without echoing the input so it's used more than just for remoting. As for the original issue of this bug, this has been fixed (you don't get an error anymore), just keep in mind the SecureString is internally in plain text.

thanks for the update, looks promising!
may we ask for an approximately timeframe when to expect to be able to utilize this (e.g. in microsoft-debian-stretch-prod debian repository)?

As for the original issue of this bug, this has been fixed (you don't get an error anymore), just keep in mind the SecureString is internally in plain text.

Does anyone have a link to the fix or know what release version it will be available in? I'm still getting crypt32.dll errors in powershell_6.1.3-1.ubuntu.16.04_amd64.deb (same deal with the 6.2.0-rc.1 preview package).

I'm also curious how this fix affects Import/Export-CliXml when the data to be serialized contains SecureString or PSCredential objects.

@rmbolger Could you please check with latest build (6.2.0-RC)?

I'm seeing the same as @rmbolger

/home/hillr
03-20 23:44:55 31ms 11> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.2.0-rc.1
PSEdition                      Core
GitCommitId                    6.2.0-rc.1
OS                             Linux 4.4.0-17763-Microsoft #379-Microsoft Wed Mar 06 19:16:00 PST 2019
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

/home/hillr
03-21 00:47:45 35ms 12> ConvertFrom-SecureString -SecureString $ss
ConvertFrom-SecureString : Unable to load shared library 'CRYPT32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libCRYPT32.dll: cannot open shared object file: No such file or directory
At line:1 char:1
+ ConvertFrom-SecureString -SecureString $ss
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand

The cmdlets load directly the CRYPT32.dll