PSD2: Otentikasi Pelanggan yang Kuat di UE

Ini adalah postingan kedua dari tiga bagian yang merinci PSD2: Otentikasi Pelanggan yang Kuat di UE (SCA).

Dalam angsuran pertama dari seri tiga bagian ini, kami memperkenalkan arahan Otoritas Perbankan Eropa (atau EBA) Uni Eropa yang disebut PSD2 (kependekan dari The Second Payment Services Directive) dan menguraikan beberapa prinsip panduan dari Strong Customer Authentication (atau SCA) .

Merujuk pada SCA, EBA mencatat: “Berkat PSD2 konsumen akan lebih terlindungi ketika mereka melakukan pembayaran atau transaksi elektronik (seperti menggunakan perbankan online atau membeli secara online). Seperti disebutkan di Bagian 1, Standar Teknis Regulasi (RTS) menjadikan otentikasi pelanggan (SCA) yang kuat sebagai dasar untuk mengakses akun pembayaran seseorang, serta untuk melakukan pembayaran secara online.”

Dalam posting ini, kami akan mengeksplorasi batasan dan regulator SCA yang harus dipertimbangkan oleh pelaksana. Pertama, mari kita lihat kode otentikasi yang dihasilkan. Ingat, ini pada dasarnya adalah Otentikasi Dua Faktor atau 2FA.

RTS menguraikan kondisi berikut untuk kode otentikasi:

• Tidak ada informasi mengenai pengetahuan, kepemilikan, dan warisan yang dapat diperoleh dari pengungkapan kode otentikasi. Ini berarti bahwa jika Anda mengetahui kode otentikasi, tidak ada cara untuk mendapatkan item pengetahuan lainnya (misalnya ID pengguna), apa yang dimiliki pengguna (misalnya ponsel – artinya Anda tidak dapat memperoleh nomor ponsel) atau pewarisan – aspek tentang pengguna itu sendiri, seperti biometrik.
• Tidak mungkin membuat kode otentikasi baru berdasarkan pengetahuan tentang kode otentikasi lain yang dibuat sebelumnya . Untuk kondisi ini, mengingat kode otentikasi apa pun, tidak ada cara untuk menghasilkan kode otentikasi baru dengan merujuk satu atau banyak kode otentikasi sebelumnya.
• Kode otentikasi tidak dapat dipalsukan . Pelaksana harus membuat kode otentikasi sehingga kode palsu atau palsu tidak dapat berhasil divalidasi.
• Tidak lebih dari 5 upaya otentikasi yang gagal harus dicoba dalam waktu untuk menjalankan kode. Setiap kode yang dihasilkan akan memiliki waktu kedaluwarsa atau "waktu untuk hidup". Timer ini dimulai segera setelah kode dibuat dan termasuk waktu pengiriman. Aturan praktis yang baik adalah bahwa kode akan kedaluwarsa dalam 15 menit atau kurang. Beberapa organisasi membutuhkan waktu hingga 30 menit atau 1 jam, tetapi ini mungkin terlalu lama. Jika pengguna mencoba untuk mengautentikasi dengan kode dan gagal 5 kali, maka kode baru harus dikirim. Ini mencegah segala jenis upaya paksa untuk mengetahui kode.
• Waktu maksimum tanpa aktivitas oleh pembayar atau pengguna setelah diautentikasi untuk mengakses akun pembayarannya secara online tidak boleh lebih dari 5 menit . Ini adalah pengatur waktu tidak aktif standar dan meskipun terpisah dari kode otentikasi, ini adalah pengatur waktu yang dimulai setelah pengguna berhasil diautentikasi dan tidak melakukan aktivitas apa pun.

Ini semua adalah kondisi yang relatif standar untuk pembuatan/validasi kode otentikasi yang digunakan dalam situasi 2FA.

Sekarang mari kita lihat persyaratan RTS yang disebut Dynamic Linking of the Transactions. Transaksi jarak jauh elektronik (misalnya dilakukan melalui Internet, terlepas dari apakah perangkat itu desktop atau perangkat seluler) harus mencakup elemen yang “secara dinamis menghubungkan transaksi dengan jumlah tertentu (pembayaran) dan penerima pembayaran tertentu.

Persyaratan SCA ini menunjukkan bahwa jumlah pembayaran transaksi bersama dengan siapa pembayaran dilakukan harus diberikan kembali kepada pengguna pada saat transaksi 2FA.

Misalnya, SMS yang diterima oleh pengguna akan memverifikasi jumlah pembelian dan pedagang, bersama dengan kode keamanan (otentikasi) dan informasi kedaluwarsa untuk kode tersebut. Satu hal yang perlu diperhatikan adalah jumlah pembelian dan merchant tidak dienkripsi.

Alternatifnya adalah memasukkan URL bersama dengan kode keamanan dalam pesan SMS. URL ingin informasi transaksi terenkripsi dan tertaut – dapat diakses melalui sesuatu yang diketahui pengguna, serta kode keamanan (diterima pada sesuatu yang dimiliki pengguna).

Kode autentikasi yang dihasilkan oleh aplikasi yang memenuhi syarat TOTP pihak ketiga seperti Google Authenticator dan banyak lainnya benar-benar terpisah dari informasi pembayaran/pedagang. Kemampuan untuk menautkan kode-kode ini secara dinamis ke transaksi agak merepotkan.

Selain itu, sebagian besar aplikasi gratis ini mungkin tidak berisi langkah-langkah yang tepat untuk mendukung penautan dinamis data transaksi dan untuk memastikan bahwa aplikasi ini berisi tindakan pencegahan untuk mengganggu kloning aplikasi serta jailbreak dan deteksi root. Meskipun demikian, ada beberapa SDK dan API khusus yang dapat memberikan tindakan pencegahan ini ke aplikasi seluler yang sesuai.

Ini berarti bahwa kode autentikasi yang dihasilkan oleh aplikasi yang sesuai dengan TOTP pihak ketiga seperti Google Authenticator dibuat terpisah dari informasi pembayaran/pedagang dan oleh karena itu tidak dapat ditautkan secara dinamis.

Persyaratan Channel Independence menyatakan bahwa “penyedia layanan pembayaran harus mengadopsi langkah-langkah keamanan, di mana salah satu elemen otentikasi pelanggan yang kuat atau kode otentikasi itu sendiri digunakan melalui perangkat multiguna, untuk mengurangi risiko yang akan dihasilkan dari multi-tujuan itu. perangkat tujuan dikompromikan.”

Perangkat multiguna dapat berupa perangkat seluler, tablet, atau laptop. Bahkan, kemungkinan akan ada skenario di mana aplikasi perbankan/pembayaran dan aplikasi otentikasi berada di perangkat yang sama. Dalam beberapa kasus, mereka bisa menjadi bagian dari aplikasi yang sama. Atau, aplikasi pembayaran dapat mengandalkan saluran otentikasi out-of-band (seperti SMS).

Saluran mengacu pada sarana untuk berinteraksi dengan pengguna. Saluran untuk pembayaran online pengguna (atau akses akun pembayaran) dan saluran yang digunakan untuk otentikasi tidak boleh sama. Dalam hal kombinasi perangkat yang tersedia di pasar saat ini, independensi saluran memunculkan sejumlah masalah. Otentikasi out-of-band melalui SMS digunakan secara luas, mudah digunakan, dan cukup populer di kalangan konsumen; Namun, itu memang memiliki beberapa masalah keamanan yang dirasakan.

Selain solusi out-of-band seperti SMS, solusi independen dan dapat diterapkan saluran lain yang baik adalah dengan menggunakan pesan push melalui solusi otentikasi cloud terpisah ke aplikasi otentikasi seluler atau bahkan aplikasi perbankan/pembayaran/pedagang dengan informasi pembayaran sebagai serta kode unik.

Aplikasi autentikasi terpisah yang menggabungkan tindakan pencegahan yang sesuai, menerima informasi yang terhubung secara dinamis melalui saluran terenkripsi dan independen adalah metode lain yang memungkinkan untuk memenuhi persyaratan ini.

Di bagian tiga dari seri tiga bagian ini , kami akan menguraikan beberapa opsi penerapan SCA yang harus memenuhi persyaratan yang diuraikan dalam RTS, serta beberapa tempat untuk menemukan informasi lebih lanjut.

Silakan pertimbangkan untuk mengikuti saya di Twitter: @wdudley2009

Pelajari apa dampak krisis kesehatan saat ini terhadap strategi bisnis, transformasi digital, dan masa depan e-commerce DI SINI.