Biometrik & Kesadaran Pembayar dalam Penautan Dinamis

Pendekatan Corbado memadukan passkeys yang tahan phishing (SCA) dengan tampilan yang dikontrol bank dan penautan dinamis sisi server untuk memenuhi PSD2 RTS Pasal 5 (“apa‑yang‑Anda‑lihat‑adalah‑apa‑yang‑Anda‑tanda tangani”).

• Implementasi inti (saat ini): Kami menampilkan jumlah dan penerima pembayaran transaksi dalam UI yang dikontrol oleh Bison-Bank segera sebelum dan selama autentikasi passkey. Backend kami menghasilkan tantangan satu kali yang terikat pada snapshot transaksi kanonis (jumlah, penerima pembayaran, txnId). Respons hanya diterima jika cocok dengan snapshot tersebut; setiap perubahan akan membatalkannya.

• Posisi regulator: Penautan dinamis tetap diwajibkan untuk pembayaran jarak jauh bahkan dengan passkeys (PSD2 Pasal 97(2); RTS Pasal 5). RTS tidak mewajibkan “kode autentikasi” penautan dinamis dihitung di perangkat; pembuatan/validasi sisi server dapat diterima ketika integritas tampilan, spesifisitas, dan pembatalan saat ada perubahan ditegakkan (lihat juga EBA Q&A 2020_5366 tentang di mana kode dapat dihitung).

• Keamanan & kemampuan audit: Mengikat tanda tangan passkey yang berbasis perangkat keras dan tahan phishing ke data transaksi tertentu akan mencegah perusakan dan penyampaian ulang, serta menghasilkan bukti persetujuan pembayar yang kuat dan tidak dapat disangkal. Jika didukung, kami dapat secara opsional mengadopsi Secure Payment Confirmation (SPC) untuk menambahkan bukti kriptografis dari detail yang ditampilkan tanpa mengubah model backend.

• SCA: Dua elemen independen dari kategori yang berbeda (pengetahuan/kepemilikan/inherensi), dilindungi dari pengungkapan/replikasi dengan mitigasi yang sesuai (RTS Pasal 6–8). Independensi diperlukan (Pasal 9), termasuk pemisahan saat dieksekusi pada perangkat serbaguna (misalnya, perlindungan tingkat OS, perangkat keras aman).
• Penautan dinamis (RTS Pasal 5):
  • (i) pembayar dibuat sadar akan jumlah dan penerima pembayaran selama autentikasi
  • (ii) kode autentikasi bersifat unik untuk jumlah/penerima pembayaran tersebut
  • (iii) setiap perubahan akan membatalkan kode tersebut
  • (iv) kerahasiaan/integritas jumlah, penerima pembayaran, dan kode dilindungi secara menyeluruh. Hal ini mewujudkan niat regulator “apa-yang-Anda-lihat-adalah-apa-yang-Anda-tanda-tangani”.
• Implikasi: Autentikasi pengguna yang kuat saja tidak cukup untuk pembayaran. Persetujuan harus terikat pada data transaksi tertentu dengan bukti yang dapat diaudit tentang pengikatan dan tampilan kepada pembayar (RTS Pasal 5(1)(a–d)).

Klarifikasi — phishing vs. otorisasi: Passkeys terikat pada asal, sehingga domain palsu tidak dapat menghasilkan tanda tangan yang valid. Namun, PSD2 masih mewajibkan penautan dinamis untuk pembayaran jarak jauh untuk mengikat otorisasi ke jumlah dan penerima pembayaran yang tepat untuk membatalkan setiap perubahan dan untuk melindungi integritas dari apa yang ditampilkan kepada pembayar (RTS Pasal 5(1)(a–d)). Penautan dinamis mengatasi integritas otorisasi (termasuk substitusi MITM/MITB/TPP), bukan hanya phishing.

Opini EBA 2019 (EBA‑Op‑2019‑06) memperkuat bahwa penautan dinamis mengikat autentikasi ke jumlah dan penerima pembayaran, memerlukan independensi faktor, dan menerima kunci kriptografis yang terikat perangkat sebagai kepemilikan di mana ada pengikatan perangkat yang unik. Opini ini juga menekankan integritas dari apa yang ditampilkan kepada pembayar selama autentikasi. Opini EBA 2019

Sebelum PSD2, banyak bank mengandalkan OTP SMS atau daftar TAN tercetak yang sering kali tidak menampilkan jumlah atau penerima pembayaran di samping langkah persetujuan. Celah tersebut memudahkan penipu untuk mengelabui pelanggan agar mengotorisasi transfer yang tidak diinginkan setelah kredensial dicuri. Penautan dinamis diperkenalkan untuk menutup celah itu dengan memastikan pembayar mengetahui jumlah dan penerima pembayaran yang tepat pada saat autentikasi dan dengan membuat kode autentikasi spesifik untuk detail tersebut sehingga setiap perubahan akan membatalkannya (RTS Pasal 5(1)(a–d)). Di mana SMS menjadi bagian dari alur, issuer juga harus memastikan kerahasiaan, keaslian, dan integritas jumlah/penerima pembayaran dan kode di semua fase autentikasi (Q&A 2018_4414; RTS Pasal 5(2)). Persetujuan dalam aplikasi saat ini (misalnya, “Apakah Anda ingin mengotorisasi 100 USD ke John Smith melalui Face ID?”) mengimplementasikan prinsip “apa yang Anda lihat adalah apa yang Anda tanda tangani” ini dengan cara yang ramah pelanggan.

Saat ini, di perangkat seluler, dua pola mendominasi. Pertama, notifikasi push dapat mengarahkan pelanggan (deep-link) ke dalam aplikasi untuk meninjau detail transaksi dan menyetujuinya. Pengawas telah mengklarifikasi bahwa push dapat berfungsi sebagai bukti elemen kepemilikan jika kontrol Pasal 7 diterapkan untuk mengurangi penggunaan yang tidak sah dan mencegah replikasi, dan keseluruhan perjalanan mematuhi RTS; meskipun demikian, risiko rekayasa sosial tetap ada dan harus diatasi dalam UX (Q&A 2019_4984; RTS Pasal 7).

Kedua, persetujuan menggunakan biometrik asli perangkat (dengan fallback PIN) melakukan verifikasi pengguna secara lokal untuk membuka operasi kunci privat. Kunci privat berada di lingkungan perangkat keras yang aman (Secure Enclave/TEE/TPM) dan menandatangani sebuah tantangan. Ini sesuai dengan SCA: inherensi (biometrik) ditambah kepemilikan yang dibuktikan dengan pengikatan perangkat dan kunci kriptografis yang terikat perangkat (EBA‑Op‑2019‑06, para. 25, 35–37). Untuk pembayaran jarak jauh, kode harus ditautkan secara dinamis ke jumlah dan penerima pembayaran dan detail tersebut harus ditampilkan kepada pembayar sebelum verifikasi pengguna (RTS Pasal 5). Jika kedua faktor ada di satu perangkat, terapkan lingkungan eksekusi aman yang terpisah dan pemeriksaan integritas sehingga kompromi pada satu faktor tidak membahayakan yang lain (RTS Pasal 9(2)–(3)).

Di balik layar, biometrik lokal tidak “mengautentikasi ke bank” secara langsung. Sebaliknya, biometrik (atau fallback PIN) melakukan verifikasi pengguna di perangkat dan mengontrol akses ke kunci privat yang tidak dapat diekspor yang disimpan di modul keamanan berbasis perangkat keras. Ketika pembayar menyetujui, perangkat menggunakan kunci privat tersebut untuk menghasilkan tanda tangan digital atas tantangan yang disediakan bank. Jika bank menurunkan atau mengaitkan tantangan itu dengan snapshot kanonis dari transaksi (jumlah, penerima pembayaran, pengidentifikasi), maka tanda tangan yang dihasilkan berfungsi sebagai kode autentikasi yang spesifik untuk detail tersebut. Setiap perubahan akan membatalkan kode karena snapshot yang tersimpan tidak lagi cocok, atau, dalam desain yang disempurnakan, karena derivasi tantangan berubah. Bagian kesadaran pembayar tetap menjadi persyaratan UX: tampilkan jumlah dan penerima pembayaran dalam tampilan yang dikontrol bank segera sebelum verifikasi pengguna. Bersama-sama, ini memenuhi persyaratan RTS Pasal 5 tentang kesadaran, spesifisitas/keunikan, dan pembatalan saat ada perubahan, sementara kontrol Pasal 7 dan bukti pengikatan perangkat membuktikan elemen kepemilikan.

• Kepemilikan (kunci terikat-perangkat & tersinkronisasi): Kunci privat passkey disimpan di perangkat keras yang aman (TEE/Secure Enclave/TPM). Passkeys yang terikat-perangkat tidak dapat diekspor, sejalan dengan ekspektasi EBA untuk pengikatan perangkat yang unik (EBA‑Op‑2019‑06, para. 25, 35–37). Passkeys yang tersinkronisasi juga dapat membuktikan kepemilikan pada setiap autentikasi, asalkan pengikatan perangkat dan kontrol anti-replikasi efektif; regulator telah menekankan perlunya tautan yang andal antara elemen dan perangkat (EBA‑Op‑2019‑06; RTS Pasal 7).
• Inherensi/pengetahuan (Verifikasi Pengguna): Verifikasi Pengguna melalui biometrik (inherensi) atau PIN perangkat (pengetahuan) mengaktifkan kunci secara lokal. Dikombinasikan dengan kepemilikan, ini adalah 2FA sejati dengan independensi faktor. Pelanggaran pada satu faktor tidak membahayakan yang lain.

Penautan dinamis adalah tentang mengikat autentikasi ke transaksi. Pertanyaan bagi bank adalah: jika kami membiarkan pengguna menyetujui pembayaran melalui passkey (bukan, katakanlah, OTP atau perangkat penandatangan), dapatkah kami menjamin bahwa persetujuan ini spesifik untuk jumlah dan penerima pembayaran yang dimaksud, dan tidak dapat digunakan kembali atau dimanipulasi?

Ada 2 opsi untuk mengimplementasikan penautan dinamis dengan passkeys:

• Penautan sisi server (standar): Hasilkan tantangan WebAuthn satu kali yang dikaitkan oleh backend dengan jumlah dan penerima pembayaran yang tepat. Pengguna melihat “€X ke Y” dalam tampilan yang dikontrol bank dan menyetujui dengan passkey. Respons hanya diterima untuk transaksi tersebut. Setiap perubahan akan membatalkannya.
• Inklusi kriptografis (ditingkatkan): Sematkan hash dari jumlah/penerima pembayaran ke dalam tantangan sehingga tanda tangan berkomitmen pada data transaksi. Ini tidak diwajibkan oleh RTS tetapi menambah jaminan bahwa bahkan pertukaran backend akan gagal verifikasi.

Catatan kepatuhan eksplisit: RTS tidak mewajibkan “kode autentikasi” penautan dinamis dihitung di perangkat pembayar. Sebuah PSP dapat menghasilkan dan memvalidasinya di server selama jumlah/penerima pembayaran dilindungi dan setiap perubahan membatalkan kode (lihat EBA Q&A 2020_5366 tentang lokasi/waktu kode). Itulah pendekatan penautan dinamis sisi server (standar) kami.

Keduanya menghasilkan “kode autentikasi” yang unik dan tidak dapat digunakan kembali yang spesifik untuk transaksi tersebut. Peringatan utamanya adalah kesadaran pembayar: WebAuthn sendiri tidak membuktikan apa yang ditampilkan. Integritas tampilan harus berasal dari UI yang dikontrol bank.

Pasal 5 RTS mengharuskan pembayar untuk melihat jumlah dan penerima pembayaran selama autentikasi. WebAuthn tidak membuktikan apa yang ditampilkan. Secara teori, jika aplikasi atau OS disusupi, pengguna dapat disesatkan sementara autentikator tetap menandatangani. Kita akan menganalisis di bawah ini secara detail bagaimana risiko ini terjadi dalam kenyataan dan mengapa ini bukan risiko keamanan nyata dan lebih merupakan masalah interpretasi regulasi.

Kontrol integritas tampilan yang kami terapkan:

• Tampilan yang dikontrol bank merender jumlah + penerima pembayaran: kami memblokir pemanggilan passkey jika tampilan terhalang atau tidak fokus
• Deteksi overlay/perusakan di aplikasi/web: tidak ada prompt passkey dari iframes tersembunyi
• Pembatasan integritas/atestasi perangkat: tolak atau tingkatkan keamanan pada sinyal perangkat yang di-root/jailbreak/disusupi
• Persetujuan atomik terhadap snapshot jumlah/penerima pembayaran yang dipegang server: tantangan baru diperlukan pada setiap perubahan parameter

Tentang inklusi kriptografis: Ekstensi “tampilan transaksi” WebAuthn (SPC) tidak didukung secara luas saat ini. Garis dasar portabel kami adalah pengikatan sisi server, diperkuat dengan menurunkan tantangan dari snapshot transaksi (misalnya, H(jumlah ‖ penerima pembayaran ‖ txnId ‖ nonce)) sehingga tanda tangan berkomitmen pada nilai-nilai tersebut.

Kedua pola menggunakan kriptografi kunci publik dengan kunci perangkat yang tidak dapat diekspor, dan keduanya mengandalkan verifikasi pengguna lokal untuk membuka operasi penandatanganan. Dalam keduanya, bank memastikan kesadaran pembayar dengan menunjukkan jumlah dan penerima pembayaran dalam tampilan yang dikontrol bank segera sebelum verifikasi pengguna, dan memastikan spesifisitas dengan mengikat kode autentikasi ke detail tersebut — membatalkannya pada setiap perubahan (RTS Pasal 5(1)(a–d)). RTS bersifat netral teknologi dan tidak mengharuskan jumlah/penerima pembayaran dirender di dalam modal biometrik OS; ia memerlukan tampilan kepada pembayar dan pengikatan kode (RTS Pasal 5). Ketika kedua elemen SCA dieksekusi pada satu perangkat, persyaratan integritas dan pemisahan Pasal 9 berlaku sama (RTS Pasal 9(2)–(3)). Terakhir, lokasi komputasi penautan dinamis bersifat fleksibel: dapat dilakukan di sisi server jika integritas dipertahankan dan setiap perubahan membatalkan kode (Q&A 2020_5366). Ini adalah kondisi yang sama di mana regulator sudah menerima biometrik lokal dengan PKI — oleh karena itu, passkeys, yang diimplementasikan dengan kesadaran pembayar dan kontrol pengikatan yang sama, harus diterima atas dasar yang setara.

Jadi, apakah passkeys biasa menurut standar WebAuthn memenuhi tujuan penautan dinamis? Sebagian:

• Serangan MITM/jaringan: Ya. Pengikatan asal dan tanda tangan per-tantangan mencegah perusakan dan pemutaran ulang.
• Integritas transaksi: Ya. Asosiasi server atau hashing-tantangan memastikan hanya jumlah/penerima pembayaran asli yang akan terverifikasi.
• Persetujuan pembayar: Lebih sulit. Passkeys tidak memiliki tampilan tingkat autentikator. Penipuan UI pada perangkat yang disusupi bisa saja terjadi. Harus ada sesuatu yang dibangun di atasnya untuk menjamin persetujuan pembayar.

Mengapa penautan dinamis masih diperlukan dengan passkeys

• Hukum: PSD2 Pasal 97(2) dan RTS Pasal 5 mengamanatkan penautan dinamis untuk semua inisiasi pembayaran jarak jauh. Tidak ada pengecualian untuk metode tahan-phishing.
• Keamanan: Passkeys menghilangkan phishing lintas-asal, tetapi tidak dengan sendirinya membuktikan apa yang ditampilkan kepada pembayar. Penautan dinamis + kontrol integritas tampilan memastikan bahwa jumlah/penerima pembayaran spesifik yang dilihat pengguna adalah apa yang dieksekusi bank, dan bahwa setiap perubahan membatalkan persetujuan.

Singkatnya, passkeys dapat memenuhi penautan dinamis ketika terikat secara ketat pada data transaksi dan dipasangkan dengan mekanisme tampilan yang dapat dipercaya. Tantangan yang tersisa adalah membuktikan apa yang sebenarnya dilihat oleh pengguna.

Corbado menawarkan solusi yang sesuai dengan penautan dinamis yang secara eksplisit membahas pertimbangan persetujuan pembayar di atas.

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

Alur proses:

• Tampilan yang dikontrol bank menunjukkan kepada pembayar jumlah dan penerima pembayaran yang tepat. Tidak ada prompt passkey yang ditampilkan kecuali tampilan ini terlihat.
• Autentikasi: klien memanggil WebAuthn dengan tantangan satu kali yang terikat untuk transaksi yang dikanonisasi. Autentikator melakukan verifikasi pengguna (biometrik atau PIN perangkat) dan menandatangani tantangan dan asal.
• Verifikasi server: backend memverifikasi hash ID RP dan asal, mencocokkan tantangan dengan transaksi yang disimpan, memeriksa UV/flag, memberlakukan penggunaan satu kali dan kedaluwarsa, dan membandingkan snapshot jumlah/penerima pembayaran yang disimpan.
• Persetujuan dan audit: hanya setelah itu transaksi disetujui secara atomik. Setiap ketidakcocokan/perubahan ditolak dan memerlukan autentikasi baru. Catatan audit yang tidak dapat diubah disimpan (ID kredensial, authenticatorData, clientDataJSON, tanda tangan, tantangan, dan jumlah/penerima pembayaran yang dikanonisasi), secara opsional di-hash-chain untuk bukti perusakan.
• Gerbang integritas perangkat: Evaluasi integritas perangkat dan sinyal atestasi: tolak atau tingkatkan keamanan jika perangkat di-root/jailbreak/disusupi.
• Kanonisasi penerima pembayaran: Tampilkan label yang ramah (misalnya, “ACME GmbH”), tetapi ikat dan verifikasi terhadap pengidentifikasi penerima pembayaran kanonis (misalnya, IBAN/BIC atau skema unik lainnya).

Detail teknis:

• Backend: buat objek transaksi dengan data yang dikanonisasi (misalnya, mata uang/desimal yang dinormalisasi; IBAN/penerima manfaat yang dikanonisasi). Hasilkan tantangan berumur pendek yang berkomitmen pada nilai-nilai ini (misalnya, H(jumlah||penerima pembayaran||txnId||nonce)); simpan dalam status tertunda; hanya ekspos ID buram ke klien.
• Klien/autentikator: render detail pembayar dalam tampilan yang dikontrol bank; panggil WebAuthn (ID RP = domain Bison) hanya ketika terlihat; memerlukan verifikasi pengguna; autentikator menandatangani tantangan + asal per WebAuthn.
• Verifikasi/finalisasi: validasi tanda tangan, hash ID RP, asal/tipe, flag UV; anti-replay/kedaluwarsa; bandingkan snapshot jumlah/penerima pembayaran yang tidak dapat diubah; setujui secara atomik; simpan catatan audit.
• Turunkan tantangan dari snapshot:: challenge = H(jumlah ‖ penerimaPembayaranKanonis ‖ txnId ‖ nonce)

Kebijakan UX:

• Penekanan yang jelas pada jumlah/penerima pembayaran; kontrol konfirmasi/batal yang dapat diakses; batas waktu singkat; percobaan ulang yang baik selalu menggunakan tantangan baru; tanda terima segera (misalnya, “Anda menyetujui €X ke Y”). Blokir prompt passkey jika tampilan terhalang dan peringatkan jika parameter berubah sebelum penandatanganan.
• Deteksi overlay/konten yang terhalang: jangan pernah menunjukkan prompt passkey jika tampilan transaksi tidak terlihat. Tolak jika parameter berubah di tengah alur dan mulai ulang dengan tantangan baru.

Catatan kepatuhan: Desain menyeluruh ini memenuhi RTS Pasal 5: kesadaran pembayar (tampilan yang dikontrol bank), spesifisitas dan keunikan (kode satu kali yang terikat pada jumlah/penerima pembayaran), pembatalan saat ada perubahan (pemeriksaan server yang ketat), dan kerahasiaan/integritas jumlah/penerima pembayaran dan kode di semua fase (RTS Pasal 5(1)(a–d), 5(2); lihat juga Q&A 2018_4414 untuk integritas SMS). Independensi faktor (Pasal 7–9) dipertahankan melalui kepemilikan yang terikat perangkat dan UV lokal (biometrik atau PIN) pada perangkat serbaguna dengan perlindungan yang sesuai (RTS Pasal 9(2)–(3)).

Catatan:

• untuk alur web, Corbado secara opsional akan mengadopsi [Secure Payment Confirmation](https://www.w3.org/TR/payment-request-secure-payment-confirmation/) jika/ketika Apple memberikan dukungan luas, menambahkan tampilan yang dimediasi oleh browser tepercaya yang secara kriptografis membuktikan jumlah dan penerima pembayaran.

Kekhawatiran: Serangan phishing Respons: Passkeys tahan phishing secara desain: mereka terikat pada asal yang sah dan tidak melibatkan rahasia bersama, sehingga kredensial tidak dapat dipanen di situs palsu, tidak seperti OTP. Penyerang yang mem-proxy lalu lintas ke domain yang mirip tidak dapat memperoleh tanda tangan yang valid untuk asal bank. Penautan dinamis berkontribusi lebih sedikit dalam vektor ini, tetapi tetap wajib untuk memastikan setiap persetujuan unik untuk jumlah dan penerima pembayaran yang dimaksud. Tindakan pelengkap (edukasi phishing, pemisahan yang jelas antara persetujuan login vs pembayaran, penilaian anomali/risiko untuk konteks pembayaran yang tidak biasa) semakin mengurangi paparan.

Kekhawatiran: Rekayasa sosial / Penipuan Authorized Push Payment (APP) Respons: Tidak ada autentikator yang dapat sepenuhnya mencegah pengguna mengotorisasi pembayaran dengan dalih palsu (misalnya, penipuan “rekening aman”). Penautan dinamis memastikan pengguna secara eksplisit melihat penerima pembayaran dan jumlah serta memberikan bukti persetujuan yang kuat, tetapi tidak dapat mengesampingkan pembayar yang yakin. Kompensasinya mencakup peringatan kontekstual (penerima pembayaran baru, transfer besar pertama), periode penenangan atau eksekusi yang ditunda untuk penerima pembayaran berisiko tinggi, verifikasi penerima pembayaran yang lebih kuat, dan pemeriksaan peningkatan (konfirmasi tambahan) pada sinyal risiko. Notifikasi pasca-pembayaran dan saluran sengketa yang cepat membantu mendeteksi dan menahan kerugian. Kami menambahkan peringatan kontekstual waktu nyata (misalnya, penerima pembayaran baru, transfer besar pertama), periode penenangan untuk penerima pembayaran berisiko tinggi, verifikasi penerima pembayaran yang lebih kuat, dan notifikasi pasca-pembayaran (“Anda menyetujui €X ke Y”) untuk mempercepat deteksi dan respons.

Kekhawatiran: Malware atau kompromi perangkat Respons: Kunci privat tidak dapat diekspor dan memerlukan verifikasi pengguna lokal untuk setiap tanda tangan, sehingga malware tidak bisa begitu saja mengekstrak kredensial. Risiko realistis adalah penipuan UI pada OS yang sepenuhnya disusupi. Mitigasi dengan UI yang aman/terverifikasi (misalnya, konfirmasi yang dilindungi), pemeriksaan integritas perangkat/atestasi dan pemblokiran perangkat berisiko tinggi, dan konfirmasi tepercaya seperti SPC atau ekstensi konfirmasi bila tersedia. Jika indikator kompromi muncul (deteksi overlay, root/jailbreak), gunakan verifikasi ulang di luar jalur atau tolak eksekusi. Tidak ada metode konsumen yang sempurna pada perangkat yang sepenuhnya dikuasai, tetapi kontrol ini mempersempit jendela secara dramatis.

Kekhawatiran: Man‑in‑the‑browser / pembajakan sesi Respons: Ekstensi berbahaya atau skrip yang disuntikkan dapat memulai tindakan pada asal yang sah. Passkeys yang terikat asal menghentikan phishing lintas situs. Penautan dinamis memastikan editan di balik layar pada jumlah/penerima pembayaran gagal. Kami memperkuat saluran melalui kontrol CSP/anti-perusakan dan dengan memerlukan tantangan baru satu kali untuk setiap konfirmasi.

Kekhawatiran: Ancaman orang dalam atau perusakan sisi server Respons: Respons autentikasi terikat secara unik pada jumlah/penerima pembayaran asli, sehingga setiap substitusi sisi server gagal validasi. Pertahankan catatan tautan yang bukti perusakannya terlihat dan tidak dapat diubah (tantangan, kredensial, tanda tangan, dan jumlah/penerima pembayaran yang dikanonisasi) untuk audit/anti-penyangkalan. Terapkan pemisahan tugas dan kontrol empat mata pada jalur pemrosesan pembayaran kritis untuk mengurangi risiko orang dalam.

Kekhawatiran: Perangkat dicuri / pencurian kredensial Respons: Kepemilikan perangkat saja tidak cukup: verifikasi pengguna (biometrik/PIN) diperlukan untuk setiap tanda tangan, dengan batas laju dan penguncian tingkat OS. Setiap pembayaran memerlukan tantangan baru yang spesifik transaksi; token sesi generik tidak dapat mengotorisasi pembayaran sewenang-wenang. Tambahan seperti pencabutan perangkat jarak jauh, peningkatan keamanan pada penggunaan perangkat baru, pemeriksaan geovelocity, dan notifikasi (“Anda mengotorisasi €X ke Y”) semakin membatasi penyalahgunaan.

Secara keseluruhan: passkeys secara material mengurangi risiko phishing dan replay; penautan dinamis tetap penting untuk menjamin integritas transaksi, mengikat persetujuan ke jumlah/penerima pembayaran, dan memberikan bukti kuat persetujuan yang terinformasi di seluruh skenario ancaman yang tersisa.

Pertanyaan 1: Bagaimana kita dapat membuktikan bahwa pengguna benar-benar melihat dan menyetujui jumlah serta penerima pembayaran saat menggunakan passkey? Respons: Kami memberlakukan tampilan pembayar dalam tampilan yang dikontrol bank dan mengikat persetujuan ke snapshot sisi server dari jumlah/penerima pembayaran. Asersi passkey (authenticatorData, clientDataJSON, tanda tangan) diterima hanya untuk tantangan yang diturunkan dari snapshot itu; setiap perubahan memerlukan tantangan baru. Audit tahan-rusak kami menautkan asersi ke “€X ke ID-Penerima Y” dan mencatat bahwa sistem kami tidak akan melanjutkan jika detailnya berbeda. Jika didukung, SPC menambahkan bukti kriptografis bahwa pengguna mengonfirmasi detail yang ditampilkan.

Pertanyaan 1: Bagaimana kita dapat membuktikan bahwa pengguna benar-benar melihat dan menyetujui jumlah serta penerima pembayaran saat menggunakan passkey? Respons: Ini pada dasarnya adalah pertanyaan non-repudiation (anti-penyangkalan). Di bawah PSD2, penautan dinamis dimaksudkan untuk memastikan pengguna sadar akan apa yang mereka setujui. Dengan passkey, bukti yang kami simpan adalah tanda tangan kriptografis (kode autentikasi) dan data terkait (jumlah/penerima pembayaran mana yang terikat di server kami). Berdasarkan kebijakan, kami menampilkan detail transaksi kepada pengguna di aplikasi atau halaman web sebelum mereka melakukan autentikasi. Kami mencatat layar/tampilan tersebut dan autentikasi passkey yang berhasil berikutnya untuk transaksi spesifik tersebut. Jika terjadi sengketa, kami dapat menunjukkan bahwa perangkat pengguna menghasilkan tanda tangan yang valid untuk tantangan yang dikaitkan dengan (misalnya) “€100 ke ACME Corp.” dan bahwa sistem kami tidak akan melanjutkan jika ada detail yang berbeda. Kepatuhan kami bergantung pada logging yang aman: kami memastikan sistem kami tahan-rusak dalam menautkan respons passkey ke data transaksi.

Pertanyaan 2: Bagaimana jika perangkat atau OS disusupi? Dapatkah malware memanipulasi transaksi atau proses passkey? Respons: Kompromi perangkat adalah ancaman kritis dalam skenario perbankan digital apa pun. Jika sistem operasi berbahaya, ia dapat mencoba menyesatkan pengguna atau membajak proses. Namun, bahkan dalam kasus terburuk ini, passkeys mempertahankan beberapa perlindungan utama. Kunci privat tidak dapat diekstraksi oleh malware. Malware juga tidak dapat meniru pengguna ke bank, karena tidak dapat menghasilkan tanda tangan passkey tanpa biometrik/PIN pengguna. Yang paling bisa dilakukannya adalah mendorong pengguna untuk mengautentikasi sesuatu dengan dalih palsu. Penautan dinamis membantu di sini dengan memerlukan pemeriksaan integritas: malware tidak dapat secara diam-diam mengubah detail transaksi setelahnya – jika melakukannya, tanda tangan tidak akan terverifikasi. Titik terlemahnya adalah tampilan/UI: Trojan yang canggih mungkin mengubah apa yang dilihat pengguna (misalnya, menampilkan “ACME Corp” sementara transaksi yang mendasarinya sebenarnya ditujukan ke penerima pembayaran lain). Ini tidak sepele, terutama jika aplikasi bank menggunakan kerangka kerja UI yang aman, tetapi bisa dibayangkan. Meskipun begitu, jika kami mendeteksi tanda-tanda kompromi perangkat (perilaku tidak biasa, tanda tangan malware yang diketahui, dll.), kami akan kembali ke verifikasi di luar jalur atau menolak transaksi. Singkatnya: Tidak ada solusi yang 100% jika perangkat pengguna sepenuhnya dikuasai oleh penyerang. Passkeys + penautan dinamis secara dramatis mengurangi permukaan serangan (penyerang tidak bisa begitu saja mem-proxy kredensial atau mengubah data jaringan; mereka harus melakukan penipuan pada pengguna secara waktu nyata). Jika OS disusupi, penautan dinamis setidaknya memastikan setiap ketidakcocokan antara apa yang seharusnya dan apa yang disetujui akan terdeteksi oleh backend kami.

Pertanyaan 3: Jika biometrik digunakan untuk membuka passkey, apakah itu dianggap satu faktor atau dua? Apakah kita mematuhi aturan 2 faktor? Respons: Biometrik saja tidak cukup untuk SCA – itu hanya satu faktor inherensi. Namun, dalam implementasi passkey, biometrik tidak sendirian: kepemilikan perangkat adalah faktor lainnya. Biometrik pengguna membuka kunci privat yang tersimpan di perangkat. Kepemilikan dan inherensi adalah dua kategori yang berbeda. Ini analog dengan bagaimana banyak aplikasi perbankan sudah memenuhi SCA: Anda memiliki telepon (kepemilikan) dan Anda menggunakan sidik jari atau wajah Anda untuk membuka aplikasi (inherensi). EBA secara eksplisit telah mengakui kombinasi pengikatan-perangkat plus biometrik sebagai SCA yang patuh. Skenario passkey adalah kombinasi yang persis seperti itu. Jika pengguna memilih untuk menggunakan PIN alih-alih biometrik untuk membuka passkey, maka itu adalah kepemilikan + pengetahuan, juga patuh. Kami memberlakukan verifikasi pengguna pada semua operasi passkey (artinya pengguna harus memberikan biometrik/PIN setiap kali), jadi tidak ada situasi di mana hanya memiliki perangkat sudah cukup. Dengan demikian, setiap otorisasi pembayaran melalui passkey adalah peristiwa dua faktor di bawah definisi PSD2.

Pertanyaan 4: Bisakah penyerang menggunakan kembali autentikasi passkey atau entah bagaimana melewati penautan dinamis dengan memanipulasi data saat transit? Respons: Tidak. Di sinilah passkeys dan penautan dinamis bekerja sama dengan kuat. Setiap autentikasi WebAuthn menghasilkan tanda tangan unik yang terikat pada tantangan (yang kami hasilkan per transaksi) dan dibatasi untuk domain kami. Penyerang tidak dapat memutar ulang tanda tangan itu untuk transaksi yang berbeda. Tanda tangan itu sendiri menggabungkan nonce tantangan dan hanya valid untuk apa yang awalnya dikeluarkan. Jika penyerang mencegat komunikasi jaringan, mereka tidak dapat mengubah jumlah atau penerima pembayaran tanpa membatalkan tanda tangan (karena tantangan atau konteks transaksi tidak akan lagi cocok). Ini secara efektif adalah perlindungan MITM yang kita diskusikan. Juga, tanda tangan passkey menyertakan data asal – mereka tidak akan terverifikasi jika tidak dikirim ke asal situs web/aplikasi kami yang tepat, sehingga phishing atau pengalihan tidak akan berfungsi. Singkatnya, setiap upaya manipulasi membatalkan kode autentikasi, sesuai aturan penautan dinamis. Ini sebenarnya lebih aman daripada beberapa alur berbasis OTP saat ini, di mana pengguna terkadang menyetujui kode generik dan ada risiko permintaan telah dirusak. Dengan passkeys, kami secara kriptografis mengikat autentikasi pengguna ke sesi/transaksi tertentu.

Pertanyaan 5: Apakah ada opini regulator yang diketahui tentang WebAuthn/passkeys untuk SCA? Apakah kita yakin regulator akan menerima passkeys sebagai patuh? Respons: Hingga saat ini, EBA belum secara eksplisit menerbitkan opini tentang WebAuthn atau istilah “passkeys” dalam T&J atau panduan mereka. Namun, berdasarkan prinsip-prinsip yang telah mereka tetapkan, passkeys jelas cocok dengan metode yang dapat diterima. Opini EBA 2019 pada dasarnya mengantisipasi pendekatan seperti FIDO2: untuk kepemilikan, mereka secara eksplisit menyebutkan “pertukaran kunci publik/privat” dengan pengikatan perangkat yang tepat sebagai bukti kepemilikan. Passkey WebAuthn persis seperti itu – sepasang kunci publik/privat, dengan bagian privat terikat dengan aman ke perangkat. Mereka juga memberikan persetujuan pada “tanda tangan yang dihasilkan oleh perangkat” sebagai bukti kepemilikan yang valid. Jadi, meskipun mereka tidak menggunakan istilah passkey, metodenya dicakup oleh contoh-contoh mereka. Kami juga telah mengamati bahwa pemain pembayaran utama di Eropa bergerak maju dengan implementasi passkey (misalnya PayPal) yang menunjukkan tingkat kepercayaan bahwa ini sesuai dengan PSD2. Contoh ini menunjukkan bahwa passkeys diterima sebagai bagian dari alur SCA yang patuh, asalkan penautan dinamis dan persyaratan keseluruhan dipenuhi.

Pertanyaan 6: Apakah kita masih memerlukan penautan dinamis jika passkeys tahan-phishing? Respons: Ya. Passkeys menghilangkan phishing lintas-asal, tetapi PSD2 masih mengamanatkan penautan dinamis untuk inisiasi pembayaran jarak jauh. Penautan dinamis mengikat jumlah dan penerima pembayaran spesifik ke hasil SCA dan membatalkan setiap perubahan, mengatasi integritas otorisasi di luar phishing (misalnya, substitusi MITM/MITB/TPP).

Solusi Corbado sesuai dengan Penautan Dinamis dan PSD2. Tampilan pembayar pra-autentikasi, tantangan satu kali yang terikat pada jumlah dan penerima pembayaran, verifikasi server yang ketat, dan audit yang tidak dapat diubah secara bersama-sama memenuhi persyaratan RTS Pasal 5 tentang kesadaran pembayar, keunikan/spesifisitas, pembatalan saat ada perubahan, dan integritas/kerahasiaan. Independensi faktor dipertahankan melalui kepemilikan yang terikat perangkat dan UV (biometrik atau PIN), sejalan dengan panduan EBA.

Dibandingkan dengan metode OTP/SMS saat ini, Corbado memberikan keamanan dan hasil pengguna yang jauh lebih baik: ketahanan terhadap phishing dan replay, pencegahan perusakan parameter secara diam-diam, bukti non-repudiation yang lebih kuat, dan pengurangan gesekan melalui UV di perangkat. Risiko sisa (misalnya, rekayasa sosial, perangkat yang disusupi) dimitigasi dengan kontrol konkret dan lebih sempit daripada dengan metode lama. Untuk web, Corbado dapat mengadopsi SPC ketika dukungan platform (terutama Apple) sudah luas, menambahkan bukti kriptografis tampilan tanpa mengubah postur kepatuhan inti.

Singkatnya, otorisasi transaksi berbasis passkey dari Corbado memenuhi aturan dan semangat penautan dinamis PSD2 dan meningkatkan ketahanan terhadap penipuan dan kemampuan audit dibandingkan dengan pendekatan lama, sambil mempertahankan jalur yang jelas untuk peningkatan di masa depan (SPC) seiring dengan matangnya ekosistem.

Dalam praktiknya, passkeys memenuhi penautan dinamis ketika kita melakukan tiga hal: kita menampilkan jumlah dan penerima pembayaran kepada pembayar sebelum verifikasi pengguna; kita menghasilkan kode autentikasi yang spesifik untuk detail-detail tersebut; dan kita membatalkan kode pada setiap perubahan (RTS Pasal 5(1)(a–d)). Ini mencerminkan prinsip-prinsip yang sudah diterima regulator untuk biometrik lokal, dengan kemudahan tambahan bahwa passkeys bersifat asli OS dan berfungsi di seluruh saluran web dan aplikasi tanpa aplikasi tambahan. Dikombinasikan dengan pengikatan asal, mereka tidak menampilkan permintaan palsu — hanya prompt sah dari situs atau aplikasi asli yang muncul kepada pengguna.