How secure is PowerShell's ConvertFrom-SecureS

Question

I have a module that includes some strings with some private data that should be hard to attain, but changes frequently. I need to put this script on a variety of machines where it might be accessed and the code read by someone who should not have the information used to derive the output.

I'm really concerned about strings that change from time to time so I'm considering creating a script which prompts for those values as secure strings and encrypts them using a key and dumps them into an xml file. The XML file then is used to provide the strings. Anyone running a command from this module that needs that data would have to provide the key so the strings could be decrypted.

Here is basically what I expect to do, but I'll be dealing with objects

$secure = Read-Host -AsSecureString
$encrypted =  ConvertFrom-SecureString -securestring $secure -key somekey
$encrypted | Export-Clixml testing.xml
$imported = Import-Clixml testing.xml
$value = ConvertTo-SecureString -string $imported -key somekey

I understand that the string will be encrypted using the Rijndael encryption algorithm, which is also known as AES I believe.

How much effort is needed to break that encrypted key where it rests in the xml file, given access to the script?

Answer 1

If the sysem that runs the script is not reliable one, no effort is required. As SecureString handling requires a key, the script runner must know it - and if it is unreliable, your system is already compromised.

The question has been discussed quite a few times.

SecureString uses Windows' Data protection API. It is likely to be strong enough to be unbreakable in practical situations - save rubber hose cryptanalysis.

There might be ways to protect data, if you explain in more a detail what you are trying to achieve.

One way to protect sensitive data is to keep it in secure system. Give the clients some tokens, say, GUIDs, that are pre-generated. Each time a client needs the data, it will send one token to a secure remote system. The token is checked against IP/date/whatever and all processing is done on the remote system. Result data is returned to the client. This obviously doesn't work if the result data is the confidental part, but why would you send such info to unreliable system anyway?

Answer 2

Then encrpted secret string on its own is safe, but it is presumably unusable in that form. ConvertTo-SecureString will convert it from an encrypted standard string into a SecureString, but in order to do that, you need the key. If you users or script have the key, then they can do anything.

And can you even pass the SecureString to whatever application you are working with, or will you need to convert it back to regular string? If the secret data is at any time in plaintext form, then your users can see it.

Even if your application supports SecureString, you are still hosed because SecureString is trivially crackable:

[System.Runtime.InteropServices.Marshal]::PtrToStringAuto(
  [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($securestring)
 )

The approach of encrypting the secret data with some key, but allowing low-priv users to have the key, is broken. It's equivalent to "I don't want my friend to have the keys to my house, so I'll lock the keys in a box and give him the keys to the box instead."