0

I work for a retail organization with a large ecommerce presence. We allow our customers to store CC information for easy check-out, like many retailers.

Currently we remove all stored CC information upon Password Resets for an individual. There is a request by one of our business partners to change this and retain CC information through the PW reset. To clarify, when the PW is reset, an email gets sent to the users primary email address with a link to reset the password.

The justification for retaining it was that it's an inconvenience today, and we are seeing lost sales due to consumers not re-entering their CC information; in particular, our co-branded and store cards.

If there WAS a malicious user who had access to credentials for our web site, that user would simply log in as the target instead of reset the password. If the user has access to the email address on file to complete the password reset functionality then we assume that it's indeed that person and not someone maliciously trying to reset the password, hence the request to retain CC information.

I am wondering if this has any sort of PCI implications that could land us in hot water?

I understand the reasoning but want to make sure we are doing the right thing.

Improve this question

1 Answer 1

Reset to default
1

I am wondering if this has any sort of PCI implications that could land us in hot water?

None that you're not already dealing with.

PCI cares deeply about how you store PAN (Primary Account Number) and related information. If you are storing credit cards, they need to be securely encrypted, and the machines they're stored on require certain security measures, and the network they're transmitted using requires certain security measures... when you store PAN, you're signing up to do a lot of security and auditing work.

That is true whether you're storing them for a day, a year, or any period. If you expunge a user's PAN data every 3 months when they change they're password, your obligations are no different than if you don't expunge it.

(Tokenization - probably offered by your Processor - can reduce the scope which you have to protect, because you aren't storing the PAN personally. However, it doesn't make any difference for your concern; a non-expunged token remains usable after the password reset just as a non-expunged PAN would)

Personally, I don't know that I've used a merchant who requires full PAN re-entry after a change, although re-entering the CVV I have seen. You may be able to find alternatives (re-enter the CVV; answer a Security question; ...) that are less intrusive ways of being extra careful following a password change.

(To be clear, the point of asking for the CVV is to use that during the credit card auth as an extra validation, not to compare it to a previously stored value - DSS doesn't permit you to store CVV between transactions.)

Improve this answer
3
  • Just to add confirmation to this answer. In general, unless you're truly enterprise level with an entire department for security and compliance, storing the PAN's is just not worth the hassle and liability. Look at tokenization, so you're not storing them yourself, and requiring some authentication (CVV re-entry) in case of a password change and/or shipping address change, any change that may allow someone to use such saved information outside of the original users intent.
    – Jarrod Christman
    Aug 10, 2018 at 13:38
  • It's a DSS violation to store CVV2/etc between transactions at all.
    – dave_thompson_085
    Aug 11, 2018 at 5:23
  • @dave_thompson_085 of course, I didn't mean cvv should be stored for comparison. I'll update to address, thanks for catching that ambiguity.
    – gowenfawr
    Aug 11, 2018 at 12:25

You must log in to answer this question.

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