Senario: SSL abilitato all'applicazione bancaria online. Domanda: i numeri delle carte devono essere restituiti a un utente non mascherato, in caso di accesso non riuscito?

0

Per un'applicazione di banking online con SSL abilitato, se i numeri delle carte vengono restituiti all'utente non mascherati, quando c'è un login fallito.

Questa sarebbe una violazione di PCI DSS 3.3 o no in quanto la validità del PAN è sconosciuta?

PCI DSS 3.3 "Maschera PAN visualizzata (le prime sei e le ultime quattro cifre rappresentano il numero massimo di cifre da visualizzare)"

Solo per riempire gli spazi vuoti un po 'di più, molte banche canadesi usano il PAN e una password per l'accesso al servizio bancario online. Nella maggior parte dei casi, il PAN non viene mascherato durante il login iniziale. Pensando più a questo, suppongo che non ci sia un reale rischio aggiunto di restituire il PAN su un login fallito se inizialmente è stato inserito in chiaro. Tuttavia, ora vedo che probabilmente non è la pratica migliore. Al fine di proteggere dalla navigazione a spalla, che è il rischio in questo scenario, il PAN dovrebbe essere trattato come una password e mascherato in entrata, e non restituito in caso di accesso fallito.

    
posta Logan 15.03.2013 - 21:40
fonte

2 risposte

1

PCI-DSS Section 3.3 Obtain and examine written policies and examine displays of PAN (for example, on screen, on paper receipts) to verify that primary account numbers (PANs) are masked when displaying cardholder data, except for those with a legitimate business need to see full PAN

Se si può dimostrare che l'utente ha bisogno di un business per vedere il PAN completo, sarebbe perfetto visualizzarlo dopo un login fallito se fosse usato come credenziale di accesso, anche se potrebbe esserci un argomento strong che il numero di carta di credito non dovrebbe essere la credenziale di accesso. SSL assicurerà che il punto finale sia lo stesso che ha fatto la richiesta, quindi se fossero in grado di vedere il CC # restituito, sarebbero stati in grado di vederlo passare attraverso il filo in primo luogo. Nota che questo presuppone che l'utente abbia inserito CC # e desideri mostrare loro ciò che hanno inserito quando lo inseriscono in modo errato.

La mia comprensione della sezione 3.3 è semplicemente che un dipendente non dovrebbe essere in grado di vedere il PAN a meno che non ne abbia la necessità. L'utente di cui PAN ha un motivo commerciale legittimo per vederlo come è lì il numero. La preoccupazione è fare in modo che il numero non venga mostrato a coloro che non dovrebbero accedervi.

Detto questo, sembra che alcune cose potrebbero essere fatte meglio sul processo che stai descrivendo, anche se SSL e PCI-DSS sezione 3.3 non sono direttamente un problema con la situazione descritta. Non si desidera utilizzare CC # come nome utente. Questo è il motivo per cui la maggior parte ci sono registrazioni di account in cui il PAN viene inserito una volta e da quel momento in poi, viene usato il nome utente. Questo dovrebbe renderlo così non hai mai bisogno di visualizzare indietro il # CC usato. Inoltre, se il campo è stato mascherato, dovrebbe rimanere nascosto.

    
risposta data 15.03.2013 - 21:58
fonte
0

Quando si utilizza un'interfaccia che richiede un login e una password, la password viene mascherata. Se l'accesso fallisce, la password che hai digitato non viene comunque mostrata. Lo stesso ragionamento si applica qui: no, non visualizzare il numero precedentemente mascherato. È stato mascherato per un motivo che si applica ancora . Il motivo viene spesso chiamato " spalla surf ". Anche se il numero è stato digitato in modo errato, è probabile che sia ancora "quasi corretto" e, come tale, dovrebbe rimanere nascosto.

(Un'eccezione sono i soliti campi di immissione delle password per le password WiFi, sono normalmente mascherati ma hanno un pulsante per consentire lo smascheramento sulla richiesta dell'utente. Non so se PCI sarebbe OK con quello, ma sarebbe prudente astenersi da esso.)

    
risposta data 15.03.2013 - 22:00
fonte

Leggi altre domande sui tag