Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
2  
Can you explain a bit more? Why would a user see a card number at all after a failed login? Masked, or otherwise? –  Xander Mar 15 '13 at 20:47
    
Your question is at the moment next to impossible to answer as it is riddled with assumptions. –  R4D4 Mar 15 '13 at 20:48
add comment

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
add comment

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.)

share|improve this answer
    
My guess is that they are using the CC# as the login username. –  AJ Henderson Mar 15 '13 at 21:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.