I work in a PCI DSS certified environment, which (as many secure environments) require 'Strong Cryptography' when storing user passwords, as per requirement 8.2.1. We simply hash them using BCrpyt.

However, we have a new use case. When a new user is defined to the system, a password is generated automatically and emailed to the user. We want to separate creation of the user/password and emailing processes. When a user is created, we would like to persist the email body to a database, and in a scheduled task, we would like to send emails.

As you could see, this requires storing the email body (including the password in plain text) in the database. So here are my questions:

1. I suspect keeping this data in the database without encryption would not violate PCI DSS requirements, as it is not a password field but an email_body field. There's no one-to-one relation. However, it might as well.

2. I could encrypt the email_body field before persisting it to the database. I could keep the key on the server and the data on the database server (which would comply with PCI DSS requirement 3.5.2). Would this satisfy requirement 8.2.1?

3. Or simply I have to send the password as I create it, and forget all about.

  • Is there any PAN data or cardholder data in the area that the password grants access to? Or is it a truly blank area with no data?
    – schroeder
    Oct 24, 2019 at 11:12
  • Depends on the role of the user being created. There 'usually' is both. Oct 24, 2019 at 11:13
  • FWIW, we create the users as credentials expired, so the first thing they need to do is to change their password. Oct 24, 2019 at 11:14
  • #1 is not a question, btw - do you have a question there?
    – schroeder
    Oct 24, 2019 at 11:35
  • 2
    Or send a password reset link instead of the actual password.
    – Bobson
    Oct 24, 2019 at 13:42

2 Answers 2


That's a really interesting question, and initially because you said that there was a forced password change on first login, I had thought you’d be able to make a convincing argument that the account wasn't fully enabled until the initial user had logged in - but that, of course, is not true.

Let's look at this from the perspective of an attacker with access to the database that stores the password-containing-emails. If the attacker reads the initial password from the stored email and logs in BEFORE the legitimate user, the attacker will then be able to change the initial password to one of their own choosing and will then have the rights associated with the user (and I'm guessing access to the CDE).

So yes, to comply with 8.2.1 the password saved as part of the email should be strongly encrypted (which won't be simple) or, as other posters and you yourself have suggested, don't save the email containing the password to the database. The latter option is preferred because as well as taking any complex compliance questions away, you have a smaller attack surface and one less thing to worry about.


If the user account contains protected data, then storing access to that protected data in the clear in a database would appear to go against the standard.

You might get away with it if the accounts were blank, but I can't see how you would pass a review if the account had data that was regulated by the standard.

Obviously, the best option is to send the email straight away to transfer the risk to the user.

Encryption might work, but you would have to run that past your QSA to be sure.


You must log in to answer this question.

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