PSD2: forte autenticazione del cliente nell'UE

Questo è il secondo di una serie di post in tre parti che descrivono in dettaglio PSD2: Strong Customer Authentication in the EU (SCA).

Nella prima puntata di questa serie in tre parti, abbiamo introdotto la direttiva dell'Autorità bancaria europea (o EBA) dell'Unione Europea denominata PSD2 (abbreviazione di The Second Payment Services Directive) e abbiamo delineato alcuni dei principi guida della Strong Customer Authentication (o SCA) .

Riferendosi a SCA, l'EBA osserva: “Grazie alla PSD2 i consumatori saranno meglio protetti quando effettuano pagamenti o transazioni elettroniche (come l'utilizzo del proprio banking online o l'acquisto online). Come indicato nella Parte 1, il Regulatory Technical Standard (RTS) rende l'autenticazione forte del cliente (SCA) la base per accedere al proprio conto di pagamento, nonché per effettuare pagamenti online".

In questo post, esploreremo le limitazioni SCA e le autorità di regolamentazione che gli implementatori devono considerare. Per prima cosa, diamo un'occhiata ai codici di autenticazione che vengono generati. Ricorda, questa è essenzialmente l'autenticazione a due fattori o 2FA.

L'RTS delinea le seguenti condizioni per i codici di autenticazione:

• Nessuna informazione riguardante la conoscenza, il possesso e l'eredità può essere derivata dalla divulgazione del codice di autenticazione. Ciò significa che se si conosce il codice di autenticazione, non c'è modo di ricavare nessun altro elemento di conoscenza (ad esempio un ID utente), ciò che l'utente ha in suo possesso (ad esempio un telefono cellulare, il che significa che non è possibile ricavare il numero di cellulare) o ereditarietà – aspetti sugli utenti stessi, come la biometria.
• Non è possibile generare un nuovo codice di autenticazione in base alla conoscenza di qualsiasi altro codice di autenticazione precedentemente generato . Per questa condizione, dato qualsiasi codice di autenticazione, non è possibile generare un nuovo codice di autenticazione facendo riferimento a uno o più codici di autenticazione precedenti.
• Il codice di autenticazione non può essere falsificato . L'implementatore deve creare codici di autenticazione in modo che i codici contraffatti o falsi non possano essere convalidati correttamente.
• Non devono essere tentati più di 5 tentativi di autenticazione falliti entro il tempo di permanenza del codice. Ogni codice generato avrà una scadenza o "time to live". Questo timer inizia immediatamente dopo la generazione del codice e include i tempi di consegna. Una buona regola pratica è che il codice dovrebbe scadere in 15 minuti o meno. Alcune organizzazioni impiegano 30 minuti o 1 ora, ma potrebbe essere troppo lungo. Se l'utente tenta di autenticarsi con il codice e fallisce 5 volte, è necessario inviare un nuovo codice. Ciò impedisce qualsiasi tipo di tentativo di forza bruta di capire il codice.
• Il tempo massimo di inattività del pagatore o dell'utente dopo l'autenticazione per l'accesso al proprio conto di pagamento online non deve superare i 5 minuti . Questo è un timer di inattività standard e, sebbene separato dal codice di autenticazione, è un timer che si avvia una volta che l'utente è stato autenticato correttamente e non esegue alcuna attività.

Queste sono tutte condizioni relativamente standard per la generazione/convalida del codice di autenticazione utilizzato nelle situazioni 2FA.

Ora diamo un'occhiata al requisito RTS chiamato Collegamento dinamico delle transazioni. Le transazioni elettroniche remote (ad es. effettuate su Internet, indipendentemente dal fatto che il dispositivo sia un desktop o un dispositivo mobile) dovrebbero includere elementi che “colleghino dinamicamente la transazione all'importo specifico (del pagamento) e allo specifico beneficiario.

Questo requisito SCA indica che l'importo del pagamento della transazione insieme al destinatario del pagamento deve essere restituito all'utente al momento della transazione 2FA.

Ad esempio, un SMS ricevuto dall'utente verificherebbe l'importo dell'acquisto e il commerciante, insieme al codice di sicurezza (autenticazione) e alle informazioni sulla scadenza per quel codice. Una cosa da notare è che l'importo dell'acquisto e il commerciante non sono crittografati.

Un'alternativa sarebbe includere un URL insieme al codice di sicurezza nel messaggio SMS. L'URL vorrebbe le informazioni sulla transazione crittografate collegate, accessibili tramite qualcosa che l'utente conosce, così come il codice di sicurezza (ricevuto su qualcosa che l'utente possiede).

I codici di autenticazione generati da app compatibili con TOTP di terze parti come Google Authenticator e molti altri sono completamente separati dalle informazioni sul pagamento/commerciante. La possibilità di collegare dinamicamente questi codici alla transazione è alquanto problematica.

Inoltre, la maggior parte di queste app gratuite potrebbe non contenere le misure appropriate per supportare il collegamento dinamico dei dati delle transazioni e per garantire che queste app contengano contromisure per interrompere la clonazione delle app, nonché il jailbreak e il rilevamento della radice. Detto questo, ci sono alcuni SDK e API speciali che possono fornire queste contromisure alle app mobili conformi.

Ciò significa che un codice di autenticazione generato da un'app conforme a TOTP di terze parti come Google Authenticator viene generato separatamente dalle informazioni sul pagamento/commerciante e pertanto non può essere collegato dinamicamente.

Il requisito dell'indipendenza del canale afferma che "i prestatori di servizi di pagamento devono adottare misure di sicurezza, laddove uno qualsiasi degli elementi di autenticazione forte del cliente o il codice di autenticazione stesso sia utilizzato attraverso un dispositivo multiuso, per mitigare il rischio che risulterebbe da tale multi- dispositivo di scopo è stato compromesso.”

Il dispositivo multiuso può essere un dispositivo mobile, tablet o laptop. In effetti, ci saranno probabilmente scenari in cui l'app bancaria/di pagamento e l'app di autenticazione si trovano sullo stesso dispositivo. In alcuni casi, potrebbero far parte della stessa app. In alternativa, l'app di pagamento potrebbe fare affidamento su un canale di autenticazione fuori banda (come gli SMS).

I canali si riferiscono ai mezzi con cui interagire con l'utente. Il canale per il pagamento online dell'utente (o l'accesso al conto di pagamento) e il canale utilizzato per l'autenticazione non devono essere gli stessi. In termini di combinazioni di dispositivi disponibili oggi sul mercato, l'indipendenza dal canale solleva una serie di problemi. L'autenticazione fuori banda tramite SMS è ampiamente utilizzata, facile da usare e abbastanza popolare tra i consumatori; tuttavia, ha alcuni problemi di sicurezza percepiti.

Oltre alle soluzioni fuori banda come gli SMS, un'altra buona soluzione indipendente dal canale e praticabile sarebbe quella di utilizzare una messaggistica push tramite una soluzione di autenticazione cloud separata su un'app di autenticazione mobile o persino l'app bancaria/di pagamento/commerciante con le informazioni di pagamento come oltre a un codice univoco.

Un altro metodo possibile per soddisfare questi requisiti è un'app di autenticazione separata che incorpora le contromisure appropriate, ricevendo informazioni collegate dinamicamente attraverso un canale crittografato e indipendente.

Nella terza parte di questa serie in tre parti , illustreremo alcune opzioni di implementazione SCA che dovrebbero soddisfare i requisiti delineati nell'RTS, nonché alcuni luoghi in cui trovare ulteriori informazioni.

Per favore, considera di seguirmi su Twitter: @wdudley2009

Scopri quali effetti potrebbe avere l'attuale crisi sanitaria sulla strategia aziendale, sulla trasformazione digitale e sul futuro dell'e-commerce QUI.