New answers tagged

1

To make anything PCI-DSS compliant you'll have to go further than just defining some tech specs and leave it at that. PCI-DSS wants you to OPERATE a secure environment, not just design it. So let's break it down. You want to regularly send e-mails containing one or more PANs to one or more authenticated parties. You've thought up a method of sending ...


2

Yes, SAQ A-EP requires your hosting provider be validated to all applicable PCI DSS requirements. To quote the SAQ A-EP itself (emphasis mine): SAQ A-EP merchants confirm that, for this payment channel: ... If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., ...


1

I guess part of the question is whether a user could intercept the response from the first call before the second call. The answer to that is absolutely, Yes. For this setup to be secure, you would have to have an encryption scheme. The Amount and Transaction Action (sale, refund, etc) either has to be encrypted or accompanied by a checksum of said ...


1

Never trust the client browser. There are four main attack vectors I can see based on this model. 1) Leaked credentials First, as @JuliePelletier commented, in order for this to work, all the information necessary to make a "charge this card" call to Authorize.Net has to be available to the customer's webbrowser. This includes whatever secure credentials ...


9

Printing full PAN and expiry date on the customer receipt is a violation of Visa's requirements listed in "Card Acceptance Guidelines for Visa Merchants". Therefore I suggest you to submit merchant violation complaint form directly to Visa. It is located here: https://usa.visa.com/Forms/merchant-violation-complaint-form.html


-3

First, report the private data stealing/improper handling to police and make sure to obtain a paper from them where the case/complain number and date is stated. It's a very important moment! And - keep the receipt to yourself! Attach a copy to your police invoice. After that contact your bank, supplying the incident details, a scan of a receipt and the ...


4

Start by contacting your bank / debit card company and have your account number changed and your card reissued. I don't know there's much to do beyond that. If you let the bank know what merchant this happened at in IR, they may follow-up, but I don't know what IR requires from a CC standpoint, or if they even care about being PCI compliant; outside of the ...


2

Your identity is somehow linked to your card and automatically registered the next time you pay, no extra actions required. Your name is on the card, electronically. When they swipe your card the computer reads your name off the mag strip and they know that you're John Doe: Credit/Debit cards follow the ISO/IEC 7813 standard for the data on the mag ...


3

IANAQSA, and this is outside my personal experience, but here goes: In this day of credit card fraud and theft, I'm dumbfounded that this is happening. Is this legal? Legal? Depends on where you are, but... probably, yes. Note that even in the TJX breach, where 45 Million cards were compromised, the legal charges against them were for PII, not for ...


0

Response to Q1 The network segments containing systems which handle cardholder data should be in their own VLANs - it appears you've done this. The systems which are connected to and security impacting are also in scope but don't need to be within the CDE as they don't handle cardholder data. Those systems can be individually in scope without bringing the ...


0

An answer to your question will be difficult based on these conditions: What if an already registered loyalty shopper replaces their credit card through its expiring system or a compromise? The system will not be able to identify them unless the operator painstakingly relink that new card to the same customer. A simple cash register machine does not have a ...


5

This is a surprisingly complex question, and the answer is buried under a confusing layer of protocols, laws, and profits. It's no surprise that most people don't understand how it works. PIN entry is required when the issuing bank has configured the card to request it, AND the terminal is capable of accepting a PIN, AND and the chip on the card decides ...


0

The PIN is requested only for cardholder-present transactions where the card is inserted into a point-of-sale terminal. It improves security for those transactions, as it prevents someone using a stolen card in store (because they won't know the PIN). It should never be used over the phone, or on web sites, and you should never give your PIN to anyone who ...


1

PCI-DSS rules generally require that any PAN stored be encrypted in such a way that it requires not one, but two authenticators to decrypt. In practice, this would normally mean that even if you intend that the end-user is the only one with an encrypted copy, this would be insufficient from a regulatory standpoint. "Who" has a copy is irrelevant, in this ...


7

Using that external storage effectively brings it within PCI scope, however you are correct: If you have strong encryption sufficient to protect the data, and can evidence that, storing it on an archive should be allowed. Don't try and word it as outside PCI scope though - account for it in the usual way when speaking with your QSA, and include the info ...


1

After looking at this website article (https://www.pcicomplianceguide.org/will-emv-make-you-pci-compliant/) it looks like that yes, the data, specifically the PAN needs to be encrypted in accordance with PCI.


0

They can use windows XP provided they use a browser that doesn't use the Windows SSL/TLS stack. Chrome and Firefox use their own SSL/TLS stacks so they will continue to work. Internet Explorer uses the operating systems TLS stack so it will not work. I have not investigated other browsers or non-browser client applications but I would expect at least some ...


2

Encryption at Card Swipe protects the iPad from being in scope. A lot of card swipe hardware these days is configured to encrypt the card details using the public key of the card processor. The iPad simply passes the encrypted blob along; the merchant and the iPad do not have the private key required to decrypt to blob. Therefore, the merchant is never ...


-1

i really don't see what confused you. this is another form of POS device that needs to be managed according to the requirements described at the PCI requirements. Why do you think it's different from any other cashier that customers swipes a card through ?


3

Well, the first thing you'd do is put the iPad in "Guided Access" (single app mode) so that the only app that can be used is whatever point of sale software you've got on there. Next, put it on an isolated network segment that doesn't have external access and is properly secured, and you can actually have a pretty secure setup. At least as secure as ...



Top 50 recent answers are included