0

From what I've read the ConvertTo-SecureString will store a password with AES-128 (which as I understand it is cracked)...is it possible to use more bits?

I've read in Get-Help the following, but I don't know how to proceed:

If an encryption key is specified by using the Key or SecureKey
parameters, the Advanced Encryption Standard (AES) encryption algorithm is
used. The specified key must have a length of 128, 192, or 256 bits
because those are the key lengths supported by the AES encryption
algorithm. If no key is specified, the Windows Data Protection API (DPAPI)
is used to encrypt the standard string representation.

Also, I'd like to run it with a Scheduled Task in Windows.

Improve this question
4
  • 2
    AES-128 is very much not cracked. I don't know where you read this, but it is not true at all.
    – Polynomial
    Commented Aug 17, 2016 at 20:00
  • @Polynomial theregister.co.uk/2015/08/06/…
    – leeand00
    Commented Aug 17, 2016 at 20:05
  • 2
    That is a side-channel attack against the processor; it says so quite clearly in the article. Nobody cracked AES, they identified weaknesses in the implementation of the algorithm in the SIM, allowing them to extract the key material by very carefully monitoring the power consumption of the device. As the article states, side-channel attacks go around the encryption, they don't crack it.
    – Polynomial
    Commented Aug 17, 2016 at 20:10
  • 1
    The article actually links to a Sec.SE answer which explains exactly how long it'd take to crack AES-128: forever, essentially.
    – Polynomial
    Commented Aug 17, 2016 at 20:12

1 Answer 1

Reset to default
2

Yes you can use up to AES 256 as mentioned here.

ConvertFrom-SecureString and ConvertTo-SecureString have two parameters that you can use to change the default behavior. These parameters are –SecureKey and –Key. The –SecureKey parameter takes a SecureString object and the –Key parameter, a byte array (Byte[])

You use –SecureKey with a SecureString memory object that encrypt and decrypt the other SecureString. This does not really help us in our goal of storing secure passwords and accessing them through automation. You would need a SecureString object built, either by unencrypting another string using another option, or by having someone type the SecureString interactively. The first does not solve the problem of it being secured, the second does not solve the automation problem.

The –Key parameter allows you to use a 128-bit (16-byte), 192-bit (24-byte), or 256-bit (32-byte) key and uses the Advanced Encryption System (AES) cipher, also known as the Rijndael cipher, to encrypt/decrypt the SecureString. It is symmetric encryption so you need to provide the same key for encryption as you do when you decrypt the encrypted string back to the SecureString. One way to do this is to embed the key in each script file. Not surprising, this not recommended and results in security not much more secure than just storing the password in plain text in the script. It also makes it difficult to change the key or password which should due frequently using this method. A better choice is to store the key in a separate file from the script and encrypted password.

Improve this answer
4
  • I hate to ask, but what are all those numbers in $Key?
    – leeand00
    Commented Aug 17, 2016 at 19:49
  • 1
    That's the key represented as an array of bytes (hence why none of those numbers exceeds 255). In this case there are 32 bytes -indicating a 256 bit encryption key.
    – HashHazard
    Commented Aug 17, 2016 at 19:56
  • Okay couldn't see that from the picture or the docs; thanks for letting me know!
    – leeand00
    Commented Aug 17, 2016 at 19:57
  • You should be able to copy and paste from this example, but it goes without saying you should come up with new numbers for each of the 32 bits, just don't exceed the number "255" for any given position.
    – HashHazard
    Commented Aug 17, 2016 at 19:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .