JumpCloud RADIUS - Use of Hardcoded Plaintext Password in User Cert Import Process Via PowerShell Command

[sonny-mei]

Description It has been observed that the current implementation of the PowerShell command for importing user certificates uses a hardcoded plaintext password. The command snippet in question is as follows:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -Window Normal $password = ConvertTo-SecureString -String ... -AsPlainText -Force Import-PfxCertificate -Password $password

Security Concerns The use of a plaintext password in scripts raises some security concerns:

• Exposure in Logs: The plaintext password can appear in command lines, which might be logged or inadvertently exposed.
• Hardcoded Passwords: Using a hardcoded password across all user certificates could result in a security risk if the password is ever compromised.
• Potential for Inadvertent Disclosure: Including plaintext passwords in scripts can lead to unintended exposure to unauthorized users.

Question Is there a recommended or more secure method for handling passwords in this scenario to avoid these security risks? Any guidance on how to securely handle the password for importing certificates would be greatly appreciated.

[jworkmanjc]

Hello @sonny-mei, thanks for the note and for digging through the code here. Yes, there is a risk here associated with the deployment of a radius certificate here.

You are correct in your assessment, the password used for user certificate generation, if exposed, could allow someone to import these user certs on unauthorized devices. Certs installed on devices should not be exportable. (once installed) however. Someone would need to have access to the cert file (which exists on a device for only a short period of time when the command is run on a device) and they would also have to scrape the password from the powershell logs in order to install the user cert on some unauthorized device. It's possible that this could happen yes. Ideally we'll see some improvements in JumpCloud commands that would help us prevent this in the future, at this time that's not possible.

One way to better protect these certificates would be to create a unique randomized password for each user certificate. This password would have to be stored in some manner on the server that distributes the certificate.

There is another branch of the radius tool, version 2.0.0 that is currently in development. If it's of interest to you I'm interested to talk about this over a call.