Capitolo finale: Strong Customer Authentication (SCA) per PSD2
Pubblicato: 2018-09-05Questo è il terzo di una serie di post in tre parti che descrivono in dettaglio la PSD2 Strong Customer Authentication (SCA) dell'UE
Siamo giunti alla terza e ultima puntata di questa serie. Nella prima puntata, abbiamo introdotto la direttiva dell'Autorità bancaria europea (o EBA) dell'Unione Europea denominata PSD2 (abbreviazione di The Second Payment Services Directive) e delineato alcuni dei principi guida della Strong Customer Authentication (o SCA). La seconda puntata ha esplorato le limitazioni e le normative SCA che gli implementatori devono considerare, inclusi i codici di autenticazione, il collegamento dinamico delle transazioni e l'indipendenza del canale.
Per questo post, illustreremo le opzioni di implementazione SCA che dovrebbero soddisfare i requisiti delineati nella PSD2 RTS (Normativa tecnica di regolamentazione), nonché alcuni buoni posti per cercare ulteriori informazioni.
Prima di esaminare alcune opzioni di implementazione per SCA, dobbiamo anche sottolineare che ci sono alcune eccezioni dall'autenticazione forte e dal collegamento dinamico .
Nelle domande frequenti sul comunicato stampa PSD2, osservano: “[le esenzioni sono] per evitare di interrompere il modo in cui i consumatori, i commercianti e i fornitori di servizi di pagamento operano oggi. È anche perché potrebbero esserci meccanismi di autenticazione alternativi ugualmente sicuri e protetti. Tuttavia, "i fornitori di servizi di pagamento che desiderano essere esentati da SCA devono prima applicare meccanismi di monitoraggio delle transazioni per valutare se il rischio di frode è basso". Le specifiche esenzioni sono descritte nel Capitolo III della PSD2 RTS.
Due aree in cui è richiesta la Strong Customer Authentication in PSD2
- Accesso all'account : si tratta dell'accesso agli account di pagamento tramite qualsiasi dispositivo: desktop, laptop, tablet o telefono cellulare.
- Pagamenti : si tratta dell'effettiva autenticazione di un pagamento, incluso il collegamento dinamico delle informazioni di pagamento con il metodo di autenticazione.
Nel mondo multi-dispositivo e multicanale di oggi, ci sono una varietà di metodi di applicazioni bancarie/di pagamento per realizzare l'autenticazione, dal semplice 2FA basato su SMS al più sofisticato (e sicuro) Universal 2nd Factor ( U2F ) di Fido Alleanza insieme a tutto il resto.
In genere abbiamo quattro configurazioni principali oggi:
- Due dispositivi : uno che esegue l'applicazione bancaria/commerciante; un altro che fornisce l'autenticazione. Ciò includerebbe token hardware e dispositivi U2F come dispositivi di autenticazione, ma includerebbe anche un dispositivo mobile e un laptop con il laptop che esegue l'applicazione bancaria/esercente e il dispositivo mobile che fornisce l'autenticazione (anche l'autenticazione fuori banda)
- Due app, un dispositivo : su un unico dispositivo, in genere un telefono cellulare, avremmo l'app bancaria/commerciante e un'app di autenticazione. L'app di autenticazione potrebbe includere una soluzione soft-token come Google Authenticator o un'app di autenticazione speciale che si integrerebbe con la banca/commerciante per trasferire, ad esempio, le informazioni di acquisto collegate dinamicamente all'app di autenticazione.
- Un'app, un dispositivo : un esempio potrebbe essere un'app di mobile banking che fornisse anche la capacità di autenticazione all'interno di tale app.
- Autenticazione fuori banda - o OOB - include gli SMS inviati al numero di cellulare, protetti da una scheda SIM. In questo caso il dispositivo mobile, raggiunto attraverso un canale fuori banda come SMS (o anche RCS, quando supportato) sarà il 2° fattore (possesso).
Date tutte queste opzioni, quali sarebbero le migliori opzioni e metodi per supportare PSD2 SCA ed essere conformi?
L'opzione Out-of-Band (OOB) è il metodo più semplice e noto ai consumatori. È pienamente conforme alle regole per l'accesso all'account e dovrebbe essere un'opzione per i pagamenti purché le informazioni di pagamento siano incluse nell'SMS. Soddisfa inoltre il requisito dell'indipendenza del canale.
Naturalmente, in questi giorni, ci sono alcuni problemi di sicurezza con gli SMS; tuttavia, molti di questi sono un po' esagerati dalla stampa (ad es. scambio di SIM, intercettazioni di SMS). Detto questo, ci sono metodi migliori e più sicuri. Se utilizzi SMS come canale OOB per 2FA, considera l'aggiunta di un fattore di conoscenza aggiuntivo per proteggere ulteriormente l'account o il pagamento. Ciò fornirà ulteriore sicurezza contro determinati scenari di scambio di SIM o di intercettazione di SMS, qualora si verificassero.
Uno dei problemi con l'opzione di autenticazione multi-dispositivo (2-dispositivo) che utilizza vari dispositivi hardware per l'autenticazione per i pagamenti è che è difficile incorporare il collegamento dinamico delle informazioni di pagamento/commerciante a quel dispositivo di autenticazione. Sebbene molti di questi siano abbastanza sicuri come i dispositivi U2F, è difficile incorporare il collegamento dinamico delle informazioni di acquisto/pagamento.
Un metodo utile sarebbe utilizzare una soluzione di autenticazione che crea comunque un codice PIN standardizzato nel cloud, ma utilizza informazioni crittografate inviate a un'app di autenticazione specializzata. L'app bancaria/commerciante potrebbe anche includere le informazioni di pagamento insieme al codice che verrebbe inviato all'app di autenticazione.
L'app di autenticazione presenterebbe le informazioni all'utente e quindi risponderebbe con un "Accetta" o "Nega". L'app di autenticazione potrebbe far parte di una strategia a due dispositivi e di una strategia a due app (un dispositivo). L'app non dipenderebbe dai numeri di telefono (ad es. OOB) e quindi sarebbe resistente allo scambio di SIM o al dirottamento del dispositivo. Inoltre, il dispositivo dovrebbe essere fisicamente in possesso del titolare del conto insieme alle informazioni basate sulla conoscenza del titolare del conto.
Fortunatamente, ci sono molte opzioni disponibili per i fornitori di servizi di pagamento dell'UE, che dovranno implementare la PSD2 SCA nei prossimi mesi. Ciascuno avrà casi d'uso specifici che dovrebbero essere esaminati da vicino per determinare se le risorse SCA devono essere applicate. Ecco alcuni suggerimenti:
- Esamina ogni caso d'uso
- Comprendere se possono essere applicate esenzioni SCA
- Determina è il caso d'uso relativo all'accesso all'account o ai pagamenti
- Per i pagamenti, determina come presentare le informazioni di pagamento e il commerciante all'utente (collegamento dinamico)
- Per l'accesso all'account, suggeriamo di applicare sempre l'autenticazione a due fattori agli accessi: è solo più sicuro
Per la maggior parte dei mercati dell'UE, prevediamo che il metodo più diffuso per gli acquisti e i pagamenti online sarebbe tramite un dispositivo mobile. Pertanto, ciò implica che il dispositivo verrà utilizzato sia come dispositivo principale per acquisti/pagamenti che per l'autenticazione. Non aspettarti sempre che gli utenti utilizzino desktop o laptop. L'utilizzo dei dispositivi mobili (compresi i tablet) aumenterà solo come dispositivi primari.
PSD2 SCA è un insieme complesso di normative, ma con un po' di buon senso e comprensione delle sfide e delle opzioni di autenticazione odierne, può essere implementato per soddisfare queste normative e proteggere tutte le parti coinvolte. Negli ultimi mesi ci sono state alcune critiche ad alcuni requisiti di SCA e ad alcune limitazioni che impongono. In effetti, potrebbero esserci regolamenti di follow-up (PSD3?) nei prossimi mesi e anni.
Non aver paura di andare avanti e implementare SCA se sei coinvolto in pagamenti online. Non aspettare fino all'ultimo minuto. Prenditi il tempo necessario per leggere i requisiti, studiarli e poi prendere decisioni. Ci sono molte opzioni disponibili e speriamo che questa serie in 3 parti sia stata utile per guidarti attraverso le varie opzioni ed elementi di PSD2 SCA.