Storing Password in Plaintext

[Nam N_]

The customer is running into some friction with their Cybersecurity folks over passwords. They have an onboarding flow and use a password generator action (which they have added a plain text output to) for grabbing the password out of. They pass the password string into their action for creating the AD account.

They also use that password string for things like their overseas password reset requests (so they can email end-users the new temporary password).

Cyber takes exception that those temporary password strings appear unencrypted in the flow context logs. The customer knows they could perform a decrypt in a prescript step for the action to create the AD account but I don’t think they can avoid it being logged as a string if they are using ServiceNow to email out the password for resets.

Any suggestions on how they might handle this concern to meet their requirements for not storing passwords in plaintext in any logs?

My thought is SN is creating the temp password and then sending that to the AD creation. If there's no reason for ServiceNow to know the password long-term, they could, maybe, have an IAM solution do the actual provisioning of AD. If ServiceNow then sends the user their welcome packet that contains the password, we're back to SN needing to know that information at some point.

[luffy3478]

dont log. if logging is the only problem

[Kai Tingey]

There's no real getting around having the password in plain text *somewhere* if ServiceNow is generating it and notifying someone.

On our account creations we encrypt the password string and use that to generate the AD account, but it has to be decrypted and sent to the user - so it's going to be in the email anyway.

You could try and use some mechanism to look up the offending records (e.g. email with password in it) and then delete that record from servicenow, or at least purge the body text field or something.