Vraag:
Is het verzenden van creditcardgegevens via e-mail in strijd met PCI DSS?
Salvador Dali
2014-12-19 07:17:29 UTC
view on stackexchange narkive permalink

Omdat ik in de VS ben, heb ik gemerkt dat steeds meer bedrijven vragen om gevoelige creditcardgegevens (alle informatie die nodig is om een ​​transactie uit te voeren) via een gewone e-mail. Ik denk dat dit een beveiligingsrisico is of op zijn minst een slechte gewoonte.

Mijn vraag is of het een van de standaarden schendt (zoals PCI DSS) en hoe moet men hiermee omgaan. verzoeken?

Ik woon in de VS en ik heb NOOIT een bedrijf om creditcardgegevens gevraagd via e-mail - en ik winkel regelmatig online. Verhuis nu naar een ander bedrijf en weet u zeker dat het zelfs een legitiem bedrijf is?
@ekaj Van hoeveel online winkels heb je iets gekocht (5-10 verschillende winkels? In welk geval maakt het niet zoveel uit hoe vaak je winkelt). Ik winkel ook vaak, en in de meeste tijd zijn er helemaal geen problemen, maar soms vragen huurappartementen, auto's, verhuisdiensten om dergelijke informatie. In mijn geval is dit de vierde keer in een periode van 1 jaar dat ik dit ben tegengekomen, en het bedrijf is behoorlijk legitiem.
Het beroemde Resorts World Sentosa in Singapore vereist dat u uw naam, creditcardnummer en vervaldatum per e-mail verstuurt.Dit, in 2017. Verbazingwekkend.
Twee antwoorden:
John Downey
2014-12-19 09:23:23 UTC
view on stackexchange narkive permalink

Ja, PCI DSS-vereiste 4.2:

Verzend nooit onbeschermde PAN's door berichttechnologieën van eindgebruikers (bijvoorbeeld e-mail, instant messaging, chat, enz.).

Tenzij de e-mail op een of andere manier versleuteld is, mag u deze niet gebruiken om kaarthoudergegevens te verzenden.

Eigenlijk is zelfs gecodeerde e-mail verboden. Kaartinformatie mag nooit worden verzonden door berichttechnologieën van de eindgebruiker, al dan niet versleuteld. Dat is de reden waarom de meeste banken en e-shops weigeren om klantenservice zaken te doen via bijvoorbeeld Facebook Chat, zelfs als die volledig versleuteld is. De reden hierachter is dat zelfs als de gebruiker bijvoorbeeld een gevalideerd S / MIME-certificaat heeft, je er niet zeker van kunt zijn dat alleen de gebruiker de sleutel beheert. Alle beveiligde communicatie moet worden gedaan met sleutels die worden beheerd door de handelaar of door een andere aanbieder, het vertrouwen van de handelaar, wat geldt voor SSL / TLS op de site van de handelaar / provider.
@sebastiannielsen wilt u misschien teruggaan en de DSS opnieuw lezen. Hoewel ik het met uw argument eens ben, staat er specifiek in de begeleidingskolom voor vereiste 4.2: E-mail, instant messaging en chat kunnen gemakkelijk worden onderschept door pakket-sniffing tijdens bezorging via interne en openbare netwerken. Gebruik deze berichtentools niet om PAN ** te verzenden, tenzij ze zijn geconfigureerd om sterke codering te bieden. **
gowenfawr
2014-12-19 08:07:26 UTC
view on stackexchange narkive permalink

In de praktijk schendt het de DSS. In theorie zou dat mogelijk niet kunnen, maar dat is eerder pedanterie dan realiteit.

DSS-vereisten 3.4 ([Versleutelen] PAN-gegevens in opslag) en 4.1 (Versleutel PAN-gegevens via openbare netwerken ) worden doorgaans geschonden door SMTP-mail. Elke mailhop is een store-and-forward gateway die mail naar schijf schrijft, ook al is het maar tijdelijk; tenzij het is gecodeerd, is dat een overtreding van 3.4. Elke e-mailverbinding die is gecodeerd met TLS is in orde door 4.1 ... maar een handelaar kan niet garanderen dat jouw systeem of de systemen tussen jou en hen TLS zullen gebruiken, dus dat zou nooit een audit doorstaan.

Hoewel het theoretisch mogelijk is om een ​​volledig gecodeerd pad te hebben (elke mailserver met gecodeerde schijf en alle netwerkverbindingen beveiligd met TLS), is het onwaarschijnlijk en niet afdwingbaar voor op internet gebaseerde e-mail. Dus nee, het verzenden van kaartgegevens via e-mail is in strijd met de PCI DSS, en u zou niet moeten dat een handelaar u hierom vraagt, en u zou het niet moeten doen als zij u daarom vragen.

(Het is nog steeds gebeurt . En PCI is niet gestructureerd om het voor kaarthouders gemakkelijk te maken om te klagen over de praktijken van handelaars waarmee ze te maken hebben. Weigeren en doorgaan naar een andere handelaar is waarschijnlijk de beste keuze.)

Een volledig gecodeerd e-mailpad is bekend en praktisch, maar u gebruikt geen onafhankelijke codering / decodering bij elke overdracht om dit te bereiken.In plaats daarvan end-to-end-codering zoals S / MIME, waarbij de gevoelige informatie die in de body is opgeslagen, gecodeerd blijft en de servers alleen toegang hebben tot niet-gecodeerde header-informatie die niet gevoelig is (of in ieder geval niet PAN).Het probleem is dat het alleen werkt nadat de afzender en de ontvanger openbare sleutels hebben uitgewisseld.
@BenVoigt, goed punt, maar ik las het OP ("steeds meer bedrijven vragen om gevoelige creditcardgegevens te verzenden") als een beschrijving van het soort een-op-veel-relatie waarvoor het uitwisselen van openbare sleutels onpraktisch is.


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...