Abbiamo un sistema che memorizza le carte di credito in modo sicuro su file. Ci piacerebbe consentire agli utenti di registrarsi utilizzando Facebook Connect o Twitter.
Ovviamente questo non sarebbe sicuro se ci fidassimo di qualsiasi vecchio provider OAuth o OpenID, ma nel caso di Facebook e Twitter in particolare, è possibile implementare un processo di registrazione / accesso conforme allo standard PCI mantenendo comunque una carta di credito sul file?
PCI DSS v2 , Requisito 7: "Implementare misure di controllo dell'accesso strong" è la sezione pertinente. Questa sezione descrive in dettaglio il controllo dell'accesso principalmente per i non consumatori che accederanno ai dati dei titolari di carta a fini commerciali, sebbene vi siano alcuni requisiti che sembrano applicabili sia ai consumatori che ai non consumatori:
8.1 Assign all users a unique ID before allowing them to access system components or cardholder data
8.2 In addition to assigning a unique ID employ at least one of the following methods to authenticate all users: Something you know, such as a
password or passphrase Something you have, such as a
token device or smart card Something you are, such as a
biometric8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dialin service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.
8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography
Considerando quanto sopra, sembrerebbe che qualcuno potrebbe affermare che Facebook Connect / oAuth sarebbe considerato un servizio di terze parti che si connette al sistema del titolare della carta, e quindi sarebbe necessario autenticarsi tramite due fattori per il proprio sistema. (Dal requisito 8.3)
Anche se potrei vedere il caso che non si tratta di un servizio di terze parti che si connette al sistema, si tratta semplicemente di facilitare l'autenticazione dei consumatori al tuo sistema.
Il tuo QSA dovrebbe effettuare la chiamata su di esso.
Dopo aver condotto molti audit IT negli ultimi dieci anni circa, direi che la mia più grande preoccupazione sarebbe ottenere la certezza che questo meccanismo di autenticazione di terze parti funzioni come dovrebbe. Un auditor che mette il collo in linea e luci verdi si trova in una posizione molto appiccicosa se qualcosa accade alla fine di facebook / twitter (sono bersagli popolari, dato che la base di utenti è massiccia), quindi in genere vorrebbe verifica il meccanismo di autenticazione ...
che realisticamente non accadrà
Quindi, cosa accadrà, verrà sollevata un'eccezione e l'azienda dovrà firmarla. Comprenderanno appieno ciò che stanno firmando? Solo se spieghi quanto grande è questo per loro.
Come Josh ha sottolineato, nel PCI esiste una formulazione che potrebbe adattarsi a questo caso, ma alla fine della giornata spetterà ai revisori dei conti e ai proprietari delle imprese decidere se vogliono questo livello di rischio.
Una cosa da considerare se si sta considerando di affidarsi a Twitter / Facebook per l'autenticazione è che entrambi consentono comunque di trasmettere gli ID di sessione su una connessione non crittografata poiché, dopo l'autenticazione, sono accessibili tramite http e non https.
In quanto tali, è improbabile che vengano considerati in linea con i requisiti PCI.
La domanda originale chiede se gli schemi di autenticazione di Facebook, Twitter, ecc. siano conformi allo standard PCI.
La specifica DSS (Data Security Standards) di Payment Card Industry (PCI) cita due elementi distinti e distinti sull'autenticazione ed è il contesto di utilizzo che discrimina tra i requisiti:
La Sezione 8 afferma che un ID univoco deve essere assegnato a ogni persona con accesso al computer. Un nome utente "principal" (da qualunque servizio) soddisfa tale requisito (è univoco).
Questa sezione prosegue discutendo la verifica degli utenti autorizzati, che il componente della password rispetterebbe. Quindi questo copre l'autenticazione di base (è questo che pensiamo che sia) per la verifica del titolare della carta.
Tuttavia, dipende da quale accesso è concesso. Per uno strumento di pagamento archiviato, affinché il possessore della carta effettui un acquisto contro di esso, ciò sarebbe sufficiente (a condizione che lo stoccaggio della struttura dello strumento di pagamento soddisfi i requisiti PCI, ecc.)
Tuttavia, per "accesso remoto" al sistema di pagamento (generalmente) - è richiesta l'autenticazione del 2 ° fattore (fuori banda tramite password vocali / SMS ad esempio). In questo caso, Google sarebbe conforme, ad esempio, se l'opzione di callback del numero di telefono fosse implementata come mezzo di autenticazione a 2 fattori per l'accesso remoto al sistema di pagamento. Se il numero di telefono non fosse disponibile o Facebook non implementasse l'autenticazione a 2 fattori per l'accesso remoto al sistema di pagamento, NON sarebbe conforme.
Leggi altre domande sui tag authentication oauth openid pci-dss compliance