Senario:SSL Enabled Online Banking Application. Question: Should card numbers be provided back to a user un-masked, when there is a failed login?

Question

For an online banking application with SSL enabled, should card numbers be provided back to the user unmasked, when there is a failed login.

Would this be a violation of PCI DSS 3.3 or not as the validity of the PAN is unknown?

PCI DSS 3.3 "Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)"

Just to fill in the blanks a little more, many Canadian banks use PAN's and a password for logging into online banking. In most cases the PAN are not masked during the initial login. Thinking more on this, I suppose there is no real added risk to returning the PAN on a failed login if its entered in the clear initially. However I can see now that this is probably not best practice either. In order to protect from shoulder surfing, which is the risk in this scenario, the PAN should be treated similar to a password and masked on entry, and not returned either on failed login.

Answer 1

PCI-DSS Section 3.3 Obtain and examine written policies and examine displays of PAN (for example, on screen, on paper receipts) to verify that primary account numbers (PANs) are masked when displaying cardholder data, except for those with a legitimate business need to see full PAN

If the argument can be made that the user has a business need to see the full PAN, then it would be perfectly fine to display it after a failed login if it was being used as the login credential, though there could be a strong argument that the credit card number shouldn't be the login credential. SSL will ensure that the end point is the same that made the request, so if they'd be able to see the CC# being provided back, they would have been able to see it going across the wire in the first place. Note that this assumes that the user entered the CC# and you want to show them what they entered when they enter it incorrectly.

My understanding of section 3.3 is simply that an employee should not be able to see the PAN unless they have a need to. The user whose PAN it is would have a legitimate business reason to see it as it is there number. The concern is making sure that the number is not shown to those who shouldn't have access to it.

That said, it sounds like a few things could be done better about the process you are describing even if SSL and PCI-DSS section 3.3 are not directly a problem with the situation described. You don't want to use a CC# as the username. This is why most there are account registrations in which the PAN is entered once and from then on, the username is used instead. This should make it so you never need to display back the CC# used. Also, if the field was masked going in, it should remain masked.

Answer 2

When you use an interface which asks for a login and a password, the password is masked. If the login fails, the password which you typed in is nevertheless not shown. Same reasoning applies here: no, don't display the number which was previously masked. It was masked for a reason which still applies. The reason is often called "shoulder surfers". Even if the number was mistyped, chances are that it still is "almost correct", and, as such, should remain hidden.

(One exception is usual password-entry fields for WiFi passwords; they are normally masked but have a button to allow unmasking on user demand. I don't know whether PCI would be OK with that, but it would be cautious to refrain from it.)