3

Basically, the Revolut app shows the PAN and CVV by default in-app and it has a "show PIN" option, how can this be compliant?

Here's a screenshot from the app, I have seen the real app and it really renders PAN, CVV and PIN.

Update 1

One of the additional problems is how the PAN, PIN and CVV get into the mobile app.

Assuming they are not cached (which would open its own sets of issues in an unsecure environment like an Android phone + opens up the issue of factory reinitialization) then it means that they are fetched on every application start,

meaning there is an API which somebody could theoretically use to pull all of the PAN/PIN/CVV information programmatically,

just let this sink in...

This would make the mobile app something completely different from a "moral equivalent of a physical card", and we're talking a 4-long application login pin code here that afaik doesn't lock out the account.

Somebody commented:

The normal DSS rules that apply to processors and merchants aren't applied to cardholders.

Does anybody have resources about things that DO apply?

Or is the issuing security enterprise a kind of a free for all at the moment coming from the assumption that the issuer is supposed to be concerned about his own exposure and no audit of these choices needs to be performed because the fraud financial impact is issuer's and theoretically issuer's alone?

I would assume that this kind of behavior would eventually lead to breaches and a fall of trust in the mobile ewallet market, I'd love if somebody could put a bounty on this one, I'd love to see an informed authoritative answer.

  • Considering it is a virtual credit card and they are most likely bearing their own risk in terms of fraud, it could be that they are actually. – Lucas Kauffman Dec 13 '16 at 11:54
  • @LucasKauffman are you saying that if an issuer wants to bear the risk of fraud then the issuer is free to forgo standard security considerations? Do you have a reference to the PCI DSS standard on this? – bbozo Dec 13 '16 at 11:55
  • 3
    The PCI SSC has clarified that companies that perform, facilitate or support payment card issuing services are allowed to store sensitive authentication data if there is a legitimate business need to store such data (PCI Data Security Standard, Requirement 3.2). – Lucas Kauffman Dec 13 '16 at 12:51
  • 5
    Bear in mind this "App" sits in the hands of the cardholder; it is the moral equivalent of a physical card, and all physical cards have their PAN and CVV printed on them (and, in some sharpie cases, the PIN too). The normal DSS rules that apply to processors and merchants aren't applied to cardholders. That said, it does seem like an edge case, and I'd love to see a good answer from someone who knows more. – gowenfawr Dec 13 '16 at 13:12
  • @gowenfawr Yeah, problem is, a card in your hand can't be hacked to send its data to russian hackers, unlike an android app. Also, what do they do when you reset your phone to factory settings, do you lose your card? Or is there an API with which CVV, PAN and PIN are downloaded making that information accessible for a hacking attempt? Also, how do you justify sending of PIN without DUKPT or session key scheme? – bbozo Dec 13 '16 at 13:41
5

Basically, they don't have to be.

While merchants and service providers are often contractually obligated to be PCI-DSS compliant, payment applications tend to be PA-DSS (Payment Application Data Security Standards) compliant and certified (if they want to be used by merchants who wish to maintain PCI-DSS compliance).

According to the PCI Security Council's document, Mobile Payment Acceptance Applications and PA-DSS Frequently Asked Questions:

Applications used for payment-initiation—for example, those downloaded by consumers onto their mobile phones and used for consumers’ personal shopping—are seen as similar to the payment card in a consumer’s wallet.

Since Revolut isn't taking payments (well, really they are, but that's a different function than the one you're referring to), but rather acting as your personal, digital wallet in this case, the PCI Security Council doesn't see it as any different than the wallet in your pocket.

  • Yeah, but that's kind of mixing apples and oranges, no? PA DSS just means "simpler PCI DSS certification of some of the technical aspects of what it means to secure an organization and its infrastructure under PCI DSS", doesn't mean a single thing just standing by its own. In short: PA DSS is an auxiliary tool to PCI DSS certification, not something that means anything on its own. – bbozo Dec 29 '16 at 16:16
  • Issue here isn't only the security of just the mobile app, it's the server infrastructure. Some functions of the app indicate that there is a programmable API which would theoretically allow a hacker to retrieve PINs from the Revolut host, which is exactly not just like a credit card in somebody's pocket. – bbozo Dec 29 '16 at 16:19
  • I don't want to downvote yet, I would really like to know first your take on these issues, especially on the strong indication that there's a server-side API that theoretically allows harvesting of PINs/PANs/CVVs by hostile actors on the internet. Can you elaborate your answer with this in mind? – bbozo Dec 29 '16 at 16:31
  • 1
    @bbozo My point for including the quote from the article about PA-DSS is that it includes the viewpoint of the PCI Security Standards group, in regards to mobile payment apps, and that this is similar to a mobile payment apps, inthatit stores your card details. Revolut should certainly be concerned about security, but I don't believe the PCI-DSS applies here. Perhaps it should, and maybe it will, in a future version of the standards. – David A Dec 30 '16 at 20:46
  • 1
    And I hate that I can't edit after a few minutes, when I see typos in my comment. Sorry, commenting from tablet. – David A Dec 30 '16 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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