I am just curious, do PCIDSS regulation requires us to mask the bank account number? i know that credit card numbers need to be masked, but how about bank account number?
Thanks for the answer in advance
No, even with the latest PCI-DDS 3.0 you don't have to mask bank account numbers to be PCI compliant.
All they care about is Cardholder Data, in particular - PAN (Card Number). PAN must be stored encrypted (strong encryption, like AES-128 + KEKs and Keys Management) and masked everywhere it's displayed.
Anything else - including cards expire dates, addresses, bank routing and account numbers - literally, everything besides PANs (excluding CVC code and magnetic strip data [which you can not store under any circumstances]) - you can store in open form, and even display it everywhere and still be PCI compliant.
On the other hand, there's common sense. For security you should encrypt and mask the bank account numbers as well. They can be compromised too, and it won't bring you any good times.
Related
We are currently tokenizing all MasterCard and Visa cards accepted on our site and not storing card data, but we do not do the same for private-label cards. The private-label cards aren't backed by MasterCard/Visa and can only be used in-store and on our client's website. Are we violating PCI compliance by not treating these cards the same way as Visa/MasterCard even though they are in-effect 'credit' cards.
PCI is more than just Visa and MasterCard. If any of those private label cards are Participating Organization of the Payment Card Industry Security Standards Council you are violating PCI. There are currently 798 participating members.
Private label cards are entirely under the purview of their issuer, if they aren't "cobranded" (by also having a credit card network's logo). The issuer may require PCI compliance, and if they're part of the PCI council (as John Conde's answer says) they are likely to choose to do so. But it isn't required of them.
It's good practice on your part to default to treating them as PCI even if not required, simply because someone may make a mistake and type a regular credit card into the private label card field. However, if the issuer asks you to do something that would be a PCI violation, such as storing the CVV or displaying the full card number to someone, you can safely comply. (If the merchant asks you to do so, without getting approval from the bank that's backing their cards, that could be a problem, but that's between the merchant and the bank.)
As I know, for EMV cards, before transaction taking place, the terminal perform Card Authentication (using Static Data Authentication or Dynamic Data Authentication) to make sure the card is not a fake card.
(In reverse, it seem that there is no way for POS Terminal Authentication)
In Google Play, there are many applications can read EMV card data.
With a NFC-enable smartphone, we can read the sensitive card information including card number and expiration date.
(And the same for contact EMV card by using a smartcard reader)
My question is:
For EMV cards, is there any standards which specifies 'mutual authentication' protocol between cards and terminals.
And the card only send card data to terminal after performing 'mutual authentication' step.
Thanks,
Nothing to my knowledge. I believe this is so because the business use case does not justify this requirement.
Case 1. As you said there are readers who can read card data. However if at all someone take all the data from the card and replay it on a terminal, since transactions are protected by a single use cryptogram, and unpredictable number is provided by terminal, it will fail.
Case 2. A fraudster after forging a card can get some goods/services and leave, but for the terminal, it has to be registered to an acquirer/bank. There cannot be zombie terminals. Hence it is terminal who want to check the genuineness of the card and not the other way around.
You can get the track/card from chip, but so does mag stripe.
There is nothing like Mutual Authentication in EMV Payment Transaction between Terminal & Card.
Since every transaction is based on some transaction specific unique data & cryptography then cloning is not possible (here I am not talking about SDA cards).
Even though any reader is able to read the data (which is actually allowed by EMV), Since these readers application is not authorized by EMV, so they can't use the VISA/MasterCard servers for transaction processing.
(Extending existing answers with another point of view)
During online transaction card validates that terminal is able to communicate with card issuer -- i.e. that the terminal is able to deliver card-generated ARQC to the issuer and is given a valid ARPC.
As Gaurav Shukla notes in his answer fake terminals are not able to communicate with respective payment association servers.
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
I'm having a data issue I'm not sure how to handle.
Scenario: A company has a shared credit card. Which means, it is one account, but two people have access to the account, each person with his own credit card with his name on it. Let's call these people Charles and David, and assume they have a Chase account.
When I add this Chase login to Yodlee, it pulls the account THREE times, as:
"Chase - Credit Card - CREDIT CARD"
"Chase - Credit Card - DAVID"
"Chase - Credit Card - CHARLES"
It does this even though they are the same account. (I guess when you login to Chase it shows up multiple times).
All three are coming in with different ID numbers. So there is no way for me to know they are all the same account. My code thinks they are three different accounts, because they have different names and ID numbers.
As a result the account gets stored in my app three times, and the transactions three times.
What do you recommend?
Here are some suggestions:
First thing is to look for a particular site i.e., if Yodlee supports the Business Card site for that particular institution or not. As sometimes some of these Bank websites have a different login URL which can be either accessed by a different credentials or might be by the same and that will show you only 1 actual credit card account instead of 3.
In case the Business site is either not available or not supported by Yodlee(though you can request Yodlee to support the site and it could be prioritized based on the business use case), else you could call deactivateItemAccount API. This will deactivate a particular itemAccount and you can call this for those duplicate accounts.
If I am setting up a site how would I go about ensuring that the person who gives me a credit card number (for instance) is the person who is authorized to use it? Maybe more generally how would I go about reducing the opportunity for fraud and stolen ID usage whether it be for a purchase or system access.
I don't work in this field (online purchases) but I would think that authentication of a user has to be a very hard/tricky endeavor.
I would say just stick with the industry standard methods.
Someone is assumed to have posession of the card if they can supply information which verifies with the card payment gateway. As part of that, for example is the Mastercard/VISA 3D auth scheme which adds a passphrase to online payments.
You could try and go further than this 2-factor authentication with fraud prevention, but the credit card companies have more of a vested interest in it so just follow their lead.
Another common method is the address verification system, used by lots of online vendors.