Encryption of access token and refresh token uses half the expected key and iv size

[jeffhube]

Summary

The access token and refresh token for orgs connected to sfdx are encrypted using AES-256-GCM ( see https://github.com/forcedotcom/sfdx-core/blob/453b8860c16991796252f05a3c933dee1e9d7e3b/src/crypto/crypto.ts#L24 ), which uses a 256 bit key, and a 96 bit iv.

However, if you look at the encryption key in ~/.sfdx/key.json, you will see that it is 32 hex characters. Each hex character is 4 bits, so they key is 32 * 4 = 128 bits. Additionally, sfdx generates 6 random bytes for the iv ( see https://github.com/forcedotcom/sfdx-core/blob/453b8860c16991796252f05a3c933dee1e9d7e3b/src/crypto/crypto.ts#L23 ), which is 6 * 8 = 48 bits.

The key and iv are actually being passed to the Node cryptographic APIs as hex strings, and since those hex strings use 2 bytes of hex to represent 1 actual byte, we get a 256 bit key containing only 128 bits of randomness, and a 96 bit iv containing only 48 bits of randomness.

Steps To Reproduce:

Open ~/.sfdx/key.json and see that the key is only 32 hex characters (128 bits).

Expected result

The access token and refresh token are encrypted with a key containing 256 bits of randomness and an iv containing 96 bits of randomness.

Actual result

The access token and refresh token are encrypted with a key containing 128 bits of randomness and an iv containing 48 bits of randomness.

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)

powershell 7

• If you are using sfdx
  • Run sfdx version --verbose --json
• If you are using sf
  • Run sf version --verbose --json

sfdx-cli/7.180.0 win32-x64 node-v18.12.1

[github-actions[bot]]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[git2gus[bot]]

This issue has been linked to a new work item: W-12422652