În mod separat, ar trebui să vorbim despre securitatea obiectivului. Deoarece este un element al sistemului de plăți, cu siguranță, trebuie să i se impună cerințe. În mod ideal, în cazul în care banca ar putea verifica punerea lor în aplicare, dar în practică este extrem de dificil, prin urmare, fără nici o greșeală:
- banca ar trebui să ofere recomandări pentru utilizatorii serviciului "Shopping Online"
- este de dorit disponibilitatea oricăror servicii de la bănci, unde puteți verifica această conformitate (nu neapărat online marketing)
- responsabilitatea clientului în acest serviciu trebuie să fie clar definită: clientul ar trebui să fie responsabil doar pentru respectarea deplină a cerințelor, dar nu pentru întregul serviciu.
Da, scriu o bancă aici. „Banca“. Faptul este că 3DS este doar un cadru, o implementare specifică a schemei de autentificare se află în spatele băncii, prin urmare, cât de bun (sigur, sigur) schema depinde în întregime de bancă. Da, există "proști", datorită cărora apar toate aceste articole științifice și "studii", dar sunt și ele destul de demne.
Sunt sigur că pentru a restabili ordinea în acest 3DS, Visa ar trebui să emită o serie de cerințe pentru implementarea acestui 3DS, așa cum se procedează, de exemplu, în PCI DSS.
În P 2.3 "Consimțământul informat și alegerea parolei" se afirmă că: Utilizatorul care sa concentrat asupra achiziționării produsului (scenariul în timpul activării în timpul cumpărăturilor (ADS)) va alege o parolă slabă. Controlul este evident: banca nu trebuie să accepte parole simple și, în general, să implementeze politici: complexitatea, lungimea, schimbarea periodică, blocarea automată cu intrări incorecte.
P 2.4 "Schimbarea răspunderii" este dedicată faptului că Banca "în liniște" își asumă toată responsabilitatea pentru compromiterea clientului. Acest lucru trebuie, de asemenea, să fie împărțit de Wiese (așa cum am menționat mai sus): utilizatorul poate (și ar trebui!) Să respecte doar cerințele clar specificate, nu poate fi responsabil pentru totul din punct de vedere tehnic (și nu ar trebui!). Nu este corect să eliminăm complet responsabilitatea de la utilizator, deoarece punctul său final este o componentă a sistemului comun, iar compromisul său duce la compromiterea sistemului.
În p. 2.5, există o anumită întărire a mecanismului de autentificare a băncii pentru client, cred că certificatul este suficient (vezi mai sus). Dacă doriți să implementați mai multe și acest lucru - nu va fi de prisos.
P 2.6 este dedicată diverselor excentricități ale băncii cu privire la modul în care autentifică clienții atunci când utilizează schema și când schimbă datele de autentificare. Ceea ce în familie, așa cum se spune, nu este fără un ciudat. Cerințele de vize pentru implementările de autentificare în 3DS ar trebui să rezolve problema.
P 2.7 - despre confidențialitate. Despre acest echilibru etern între Securitate și confidențialitate:
1. Despre outsourcing. Dacă există motive obiective pentru transferul datelor mele către un externalizator și un externalizator se angajează să-mi protejeze datele nu mai rău decât o bancă, care este riscul pentru mine? M-am dus recent la poliția rutieră pentru un certificat de accident acolo la intrarea în datele mele de pașaport înregistrate în revista. Sunt mai îngrijorat de această revistă, care o citește, cum este reciclată etc. Și o astfel de revistă este aproape peste tot. Și ne rupem capul despre ce să spunem lui Roskomnadzor și FSB, când FZ-152 - nu funcționează nicăieri.
2. În cele din urmă, eu, ca subiect, pot fi autentificate numai prin datele mele personale. Nu mai am nimic.
Reziduu uscat:
1. Asteptam cerintele Visa pentru implementarea protocoalelor de autentificare.
2. De la bănci, așteptăm ca obiectivul cerințelor de securitate (am văzut-o aici și acolo, dar Visa trebuie să oblige astfel de cerințe să gătească).
3. Faptul că mecanismele de autentificare sunt alocate băncilor este corectă, doar cu cerințele Visa și cu împărțirea responsabilității.