PSD2: Autentificare puternică a clienților în UE

Aceasta este a doua dintr-o serie de trei părți de postări care detaliază PSD2: Strong Customer Authentication in the EU (SCA).

În prima ediție a acestei serii din trei părți, am introdus directiva Autorității Bancare Europene (sau EBA) a Uniunii Europene numită PSD2 (prescurtarea de la a doua directivă a serviciilor de plată) și am subliniat câteva dintre principiile directoare ale Autentificării puternice a clienților (sau SCA). .

Referindu-se la SCA, EBA notează: „Datorită PSD2, consumatorii vor fi mai bine protejați atunci când efectuează plăți sau tranzacții electronice (cum ar fi utilizarea serviciilor bancare online sau cumpărăturile online). După cum sa menționat în partea 1, standardul tehnic de reglementare (RTS) face ca autentificarea puternică a clienților (SCA) să fie baza pentru accesarea contului de plăți, precum și pentru efectuarea plăților online.”

În această postare, vom explora limitările SCA și autoritățile de reglementare pe care implementatorii trebuie să ia în considerare. Mai întâi, să ne uităm la codurile de autentificare care sunt generate. Amintiți-vă, aceasta este în esență autentificare cu doi factori sau 2FA.

RTS subliniază următoarele condiții pentru codurile de autentificare:

• Nicio informație cu privire la cunoașterea, posesia și moștenirea nu poate fi derivată din dezvăluirea codului de autentificare. Aceasta înseamnă că, dacă cunoașteți codul de autentificare, nu există nicio modalitate de a obține orice alt element de cunoștințe (de exemplu, un ID de utilizator), ceea ce utilizatorul are în posesia sa (să zicem un telefon mobil - adică nu puteți obține numărul de telefon mobil) sau moștenirea – aspecte despre utilizatorii înșiși, cum ar fi biometria.
• Nu este posibil să se genereze un nou cod de autentificare pe baza cunoașterii oricărui alt cod de autentificare generat anterior . Pentru această condiție, având în vedere orice cod de autentificare, nu există nicio modalitate de a genera un nou cod de autentificare prin referire la unul sau mai multe coduri de autentificare anterioare.
• Codul de autentificare nu poate fi falsificat . Implementatorul trebuie să creeze coduri de autentificare, astfel încât codurile falsificate sau false să nu poată fi validate cu succes.
• Nu trebuie încercate mai mult de 5 încercări eșuate de autentificare în timpul de viață al codului. Fiecare cod generat va avea un timp de expirare sau „timp de viață”. Acest cronometru începe imediat după generarea codului și include timpul de livrare. O regulă generală bună este ca codul să expire în 15 minute sau mai puțin. Unele organizații durează acest lucru până la 30 de minute sau 1 oră, dar poate fi prea lung. Dacă utilizatorul încearcă să se autentifice cu codul și nu reușește de 5 ori, atunci trebuie trimis un nou cod. Acest lucru previne orice tip de încercare de forță brută de a afla codul.
• Timpul maxim fără activitate de către plătitor sau utilizator după ce a fost autentificat pentru accesarea online a contului său de plată nu va depăși 5 minute . Acesta este un temporizator de inactivitate standard și, deși este separat de codul de autentificare, este un temporizator care pornește odată ce utilizatorul este autentificat cu succes și nu efectuează nicio activitate.

Toate acestea sunt condiții relativ standard pentru generarea/validarea codului de autentificare utilizat în situațiile 2FA.

Acum să aruncăm o privire la cerința RTS numită Conectarea dinamică a tranzacțiilor. Tranzacțiile electronice de la distanță (de exemplu, efectuate prin Internet, indiferent dacă dispozitivul era un desktop sau un dispozitiv mobil) ar trebui să includă elemente care „leagă în mod dinamic tranzacția de suma specifică (a plății) și de beneficiarul specific al plății.

Această cerință SCA indică faptul că suma de plată a tranzacției împreună cu cui se face plata trebuie să fie furnizată înapoi utilizatorului în momentul tranzacției 2FA.

De exemplu, un SMS primit de utilizator ar verifica suma achiziției și comerciantul, împreună cu codul de securitate (autentificare) și informațiile de expirare pentru acel cod. Un lucru de reținut este că suma achiziției și comerciantul nu sunt criptate.

O alternativă ar fi includerea unei adrese URL împreună cu codul de securitate în mesajul SMS. Adresa URL ar dori la informațiile legate de tranzacție criptate - accesibile prin ceva ce utilizatorul știe, precum și codul de securitate (primit pe ceva ce utilizatorul deține).

Codurile de autentificare generate de aplicațiile terțe compatibile TOTP, cum ar fi Google Authenticator și multe altele, sunt complet separate de informațiile de plată/comerciant. Abilitatea de a lega dinamic aceste coduri la tranzacție este oarecum supărătoare.

În plus, este posibil ca majoritatea acestor aplicații gratuite să nu conțină măsurile adecvate pentru a sprijini conectarea dinamică a datelor privind tranzacțiile și pentru a se asigura că aceste aplicații conțin contramăsuri pentru a întrerupe clonarea aplicației, precum și detectarea jailbreak-ului și a rădăcinilor. Acestea fiind spuse, există unele SDK-uri și API-uri specializate care pot oferi aceste contramăsuri aplicațiilor mobile conforme.

Aceasta înseamnă că un cod de autentificare generat de o aplicație terță parte compatibilă cu TOTP, cum ar fi Google Authenticator, este generat separat de informațiile de plată/comerciant și, prin urmare, nu poate fi conectat dinamic.

Cerința privind independența canalului prevede că „furnizorii de servicii de plată adoptă măsuri de securitate, în cazul în care oricare dintre elementele de autentificare puternică a clientului sau codul de autentificare în sine este utilizat printr-un dispozitiv multifuncțional, pentru a atenua riscul care ar rezulta din acel dispozitivul cu scop fiind compromis.”

Dispozitivul multifuncțional poate fi un dispozitiv mobil, tabletă sau laptop. De fapt, vor exista probabil scenarii în care aplicația bancară/plată și aplicația de autentificare se află pe același dispozitiv. În câteva cazuri, acestea ar putea face parte din aceeași aplicație. Alternativ, aplicația de plată se poate baza pe un canal de autentificare în afara bandă (cum ar fi SMS-urile).

Canalele se referă la mijloacele prin care să interacționeze cu utilizatorul. Canalul pentru plata online a utilizatorului (sau accesul la contul de plată) și canalul utilizat pentru autentificare nu trebuie să fie același. În ceea ce privește combinațiile de dispozitive disponibile, care sunt astăzi pe piață, independența canalului ridică o serie de probleme. Autentificarea out-of-band prin SMS este implementată pe scară largă, ușor de utilizat și destul de populară în rândul consumatorilor; cu toate acestea, are unele probleme de securitate percepute.

Pe lângă soluțiile out-of-band, cum ar fi SMS-urile, o altă soluție bună independentă de canal și funcțională ar fi folosirea unei mesaje push printr-o soluție separată de autentificare în cloud către o aplicație de autentificare mobilă sau chiar aplicația bancară/plată/comerciant cu informațiile de plată ca precum și un cod unic.

O aplicație de autentificare separată care încorporează contramăsurile adecvate, primirea de informații legate dinamic printr-un canal criptat, independent este o altă metodă posibilă pentru a satisface aceste cerințe.

În partea a treia a acestei serii de trei părți , vom prezenta câteva opțiuni de implementare SCA care ar trebui să satisfacă cerințele prezentate în RTS, precum și câteva locuri pentru a găsi mai multe informații.

Vă rugăm să luați în considerare să mă urmăriți pe Twitter: @wdudley2009

Aflați ce efecte ar putea avea actuala criză de sănătate asupra strategiei de afaceri, transformării digitale și viitorului comerțului electronic AICI.