[GH-ISSUE #1956] Custom Field 'Password' Type #3165

New issue

Open

opened 2026-03-14 06:45:19 +03:00 by kerem · 2 comments

kerem commented

2026-03-14 06:45:19 +03:00

Owner

Originally created by @adamjrberry on GitHub (Aug 3, 2024).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1956

Is your feature request related to a problem? Please describe.
It would be great if there's an option to have a 'password' type custom field to hide passwords.
Example Use Case: A DIY LAPS solution that outputs a local admin password to a custom field and rotates regularly, or a Bitlocker Recovery Key.

Describe the solution you'd like
Have a 'password' type option when adding custom fields.
For example:

Encrypted (requiring the RMM user to re-enter their password to unencrypt) to view the password
Unencrypted but just hidden by default (especially useful if sharing screen with someone but you don't want the passwords to be visible) - just having an eye icon that you can click to reveal the password. I know this could be kind-of achieved by hiding the custom field from the summary section, but it would be neater to retain it on the summary page but with the password masked.

Ideally the password would be encrypted in the database, but viewable by staff users. Could even create a specific custom field for passwords with a custom password to access it (i.e. 'use this break glass password in our documentation to access that specific custom field value'). It would be ideal if these custom field values can still be referenced and used in scripts though.

Before

After

Describe alternatives you've considered

Hiding the custom field from the summary tab
Leaving as-is
More frequent password rotation
Have it output a encoded string that can be decoded locally

Additional context
Example screenshots above.
Also sample dialog box that prompts for admin's password to reveal field value:

Originally created by @adamjrberry on GitHub (Aug 3, 2024). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1956 **Is your feature request related to a problem? Please describe.** It would be great if there's an option to have a 'password' type custom field to hide passwords. **Example Use Case**: A DIY LAPS solution that outputs a local admin password to a custom field and rotates regularly, or a Bitlocker Recovery Key. **Describe the solution you'd like** Have a 'password' type option when adding custom fields. For example: - Encrypted (requiring the RMM user to re-enter their password to unencrypt) to view the password - Unencrypted but just hidden by default (especially useful if sharing screen with someone but you don't want the passwords to be visible) - just having an eye icon that you can click to reveal the password. I know this could be kind-of achieved by hiding the custom field from the summary section, but it would be neater to retain it on the summary page but with the password masked. Ideally the password would be encrypted in the database, but viewable by staff users. Could even create a specific custom field for passwords with a custom password to access it (i.e. 'use this break glass password in our documentation to access that specific custom field value'). It would be ideal if these custom field values can still be referenced and used in scripts though. **Before** ![image](https://github.com/user-attachments/assets/c97aec7f-a27a-43cb-b5c9-557acd475b3d) **After** ![image](https://github.com/user-attachments/assets/f5d35a8a-5cb1-4017-860f-782921bd7582) **Describe alternatives you've considered** - Hiding the custom field from the summary tab - Leaving as-is - More frequent password rotation - Have it output a encoded string that can be decoded locally **Additional context** Example screenshots above. Also sample dialog box that prompts for admin's password to reveal field value: ![image](https://github.com/user-attachments/assets/e27ca47c-bdad-4745-8324-ce0eb578e33e)

kerem commented

2026-03-14 06:45:25 +03:00

Author

Owner

@P6g9YHK6 commented on GitHub (Aug 3, 2024):

for me these values should be encrypted with a password external to trmm a bit like what privatebin does with a public and private key for security so even if the rmm is compromised (db, account or privilege escalation) they would still have to have the decryption key.

and we need also something for the global key store

@P6g9YHK6 commented on GitHub (Aug 3, 2024): for me these values should be encrypted with a password external to trmm a bit like what privatebin does with a public and private key for security so even if the rmm is compromised (db, account or privilege escalation) they would still have to have the decryption key. and we need also something for the global key store

kerem commented

2026-03-14 06:45:30 +03:00

Author

Owner

@adamjrberry commented on GitHub (Aug 3, 2024):

I agree, depending on the use case I guess.
For simple LAPS passwords with low risk as each client has a different password, and there is regular rotation, a simple 'click to reveal text' option would be fine (at least I consider this an acceptable risk).
For more sensitive secrets, then yes additional encryption would be suitable. However, in my case, I don't store any super secret values in these fields - those go in a dedicated password manager, but I do still like the idea of not displaying passwords (no matter how low risk) in plain view. For example sharing screen with a client to show them something, they could simply screenshot on Teams when they see a LAPS password and use it before the next rotation - a 'click to reveal' option would resolve this problem (I know this is more of a HR-ish issue than IT, but of course there are many scenarios where this could be useful). Perhaps two options like below (please excuse the shoddy editing/graphics - I'm literally just adding boxes on Powerpoint lol).

@adamjrberry commented on GitHub (Aug 3, 2024): I agree, depending on the use case I guess. For simple LAPS passwords with low risk as each client has a different password, and there is regular rotation, a simple 'click to reveal text' option would be fine (at least I consider this an acceptable risk). For more sensitive secrets, then yes additional encryption would be suitable. However, in my case, I don't store any _super_ secret values in these fields - those go in a dedicated password manager, but I do still like the idea of not displaying passwords (no matter how low risk) in plain view. For example sharing screen with a client to show them something, they could simply screenshot on Teams when they see a LAPS password and use it before the next rotation - a 'click to reveal' option would resolve this problem (I know this is more of a HR-ish issue than IT, but of course there are many scenarios where this could be useful). Perhaps two options like below (please excuse the shoddy editing/graphics - I'm literally just adding boxes on Powerpoint lol). ![image](https://github.com/user-attachments/assets/62c833df-c312-4e68-ba41-eb95e1372d11)