Kode QR & Bluetooth Passkey WebAuthn: Transportasi Hibrida

Passkey semakin banyak menggantikan kata sandi sebagai standar de-facto dalam autentikasi pengguna. Berbeda dengan kata sandi tradisional, passkey terikat pada suatu ekosistem (misalnya, iCloud Keychain, Google Password Manager, Windows Hello atau pengelola kata sandi seperti 1Password atau Dashlane); passkey tidak dirancang untuk dihafal tetapi dibuat untuk berintegrasi secara mulus dengan perangkat Anda, menawarkan pengalaman pengguna yang luar biasa sejak awal.

Bayangkan Anda jauh dari komputer pribadi Anda, mungkin di terminal publik atau laptop teman, dan Anda perlu masuk ke akun yang dilindungi passkey. Skenario ini cukup umum dan memerlukan metode autentikasi yang aman namun nyaman, tetapi dengan passkey banyak orang tidak tahu apa yang harus dilakukan, karena passkey mereka tidak langsung tersedia dalam situasi ini. Salah satu fitur passkey untuk membantu Anda dalam situasi seperti itu adalah kemampuan untuk menggunakan passkey Anda di beberapa perangkat melalui fasilitasi kode QR dan teknologi Bluetooth. Proses ini secara formal dikenal sebagai transportasi hibrida dalam spesifikasi WebAuthn (dalam versi spesifikasi sebelumnya disebut sebagai cloud-assisted Bluetooth Low Energy caBLE).

Prosesnya sederhana: Anda memerlukan perangkat yang menyimpan passkey Anda dan mampu mengambil gambar, jadi kemungkinan besar adalah ponsel cerdas atau tablet. Perangkat ini dapat membuka terowongan ke perangkat baru hanya untuk satu instans autentikasi tersebut. Ini tidak hanya menjaga integritas passkey Anda tetapi juga memastikan bahwa akses ke akun Anda di perangkat baru dapat diberikan, di mana pun Anda berada atau perangkat siapa pun yang ingin Anda gunakan untuk masuk.

Namun, fitur autentikasi lintas platform passkey ini dikelilingi oleh kesalahpahaman dan kebingungan baik dalam kegunaannya maupun implementasi teknisnya. Ini adalah sesuatu yang saya perhatikan lagi baru-baru ini, ketika saya mengunjungi pertemuan keamanan TI lokal. Melalui artikel ini, kami bertujuan untuk mengurai kerumitan dan memberikan rekomendasi untuk mengimplementasikan alur autentikasi passkey lintas platform (transportasi hibrida) ini, memastikan Anda dapat memberikan pengalaman masuk terbaik bagi pengguna Anda.

Passkey adalah bentuk autentikasi pengguna yang menggantikan kata sandi tradisional dengan pasangan kunci publik-privat kriptografis yang lebih aman dan nyaman. Pasangan kunci ini unik untuk setiap pengguna dan digunakan untuk memverifikasi identitas tanpa perlu repot mengingat kata sandi yang rumit.

Keuntungan passkey sangat banyak jika dibandingkan dengan pendahulunya, kata sandi. Passkey secara signifikan mengurangi risiko phishing, karena tidak dapat ditipu untuk dibagikan dengan situs web palsu. Selain itu, passkey kebal terhadap serangan brute force dan kamus, yang merupakan metode umum yang digunakan untuk membobol kata sandi. Passkey juga lebih ramah pengguna, menghilangkan kebutuhan untuk mengingat atau mengelola daftar kata sandi yang panjang.

Passkey disinkronkan di akun cloud, seperti yang dikelola oleh Google Password Manager atau Apple iCloud Keychain (Microsoft dengan Windows Hello akan segera menyusul), atau yang disimpan di pengelola kata sandi modern yang siap-passkey, seperti 1Password atau Dashlane. Namun, penting untuk diketahui bahwa secara default passkey terikat pada ekosistem dan sinkronisasi akun cloud masing-masing. Sistem operasi tidak menyediakan antarmuka untuk mengekspor kunci privat dan di sebagian besar perangkat, ada komponen perangkat keras yang menyediakan langkah-langkah keamanan tambahan untuk menghindari akses apa pun ke kunci privat, misalnya secure enclave pada perangkat iOS atau trusted platform module (TPM) pada perangkat Windows. Hanya penyedia sistem operasi yang dapat menyinkronkan passkey ke perangkat lain secara terenkripsi (pada akhirnya dilindungi oleh biometrik, kode sandi, atau PIN pengguna). Kunci privat hanya dapat dipulihkan dan didekripsi menggunakan kode sandi / PIN dan akan dihancurkan jika ada terlalu banyak upaya masuk yang gagal ke akun cloud (misalnya, Apple memperkenalkan batas laju untuk mencegah serangan brute-force bahkan dari posisi istimewa di backend cloud; Google melakukan hal yang sama).

Desain inheren ini berarti bahwa jika passkey tidak disinkronkan seperti yang dijelaskan, mengakses passkey Anda di perangkat baru dapat menjadi tantangan. Inilah sebabnya mengapa metode transportasi hibrida untuk autentikasi lintas platform passkey (transportasi hibrida) dengan kode QR dan pemeriksaan kedekatan Bluetooth ada. Ini menyediakan jembatan yang aman untuk passkey Anda antar perangkat tanpa perlu menyinkronkannya melalui akun cloud / pengelola kata sandi, sehingga mempertahankan prinsip bahwa passkey dapat tetap berada hanya pada pengguna.

Menggunakan autentikasi passkey lintas platform (transportasi hibrida) dengan transportasi hibrida membantu mengatasi masalah lintas perangkat, ketika sebuah akun diakses murni melalui passkey. Karena tidak semua passkey disinkronkan di akun cloud atau pengelola kata sandi, kebutuhan akan metode yang andal untuk mengakses passkey di berbagai perangkat menjadi sangat penting, terutama saat beralih ke perangkat baru atau memerlukan akses di perangkat bersama.

Untuk memfasilitasi autentikasi lintas platform passkey (transportasi hibrida), ada persyaratan perangkat keras berikut:

• Dukungan WebAuthn: Perangkat harus mendukung WebAuthn. Ini sudah ada di 99% perangkat, menurut analisis data passkey terbaru kami.
• Kamera untuk Pemindaian Kode QR: Perangkat akan memerlukan kamera yang mampu memindai kode QR. Sebagian besar ponsel cerdas modern dilengkapi dengan kamera yang memiliki fungsionalitas ini. Selain itu, kamera memerlukan kemampuan pemindaian QR bawaan (yang dimiliki sebagian besar perangkat sejak awal). Jika kamera Anda tidak mendukung, maka pemindai QR online juga merupakan pilihan yang baik. Jika tidak, menginstal aplikasi kode QR juga tidak masalah.
• Kemampuan Bluetooth: Cloud-assisted Bluetooth Low Energy (caBLE) digunakan untuk membangun koneksi aman berbasis kedekatan antar perangkat. Versi yang harus dicari adalah Bluetooth 4.0 atau lebih tinggi, yang memungkinkan ekstensi caBLE untuk WebAuthn.
• Koneksi Internet: Koneksi internet yang stabil di kedua perangkat harus ada, karena pertukaran melibatkan pembukaan terowongan untuk melakukan langkah-langkah verifikasi yang memerlukan transfer data waktu nyata.

Dari sudut pandang perangkat lunak, persyaratan berikut ada:

• Konfigurasi Server WebAuthn: Jelas, Anda perlu memiliki server WebAuthn yang mengelola kunci publik. Ini juga melibatkan pengaktifan akun pengguna untuk ditautkan dengan beberapa autentikator dan menyiapkan server untuk memulai seremoni autentikasi.
• Web Bluetooth API: Untuk pemeriksaan kedekatan Bluetooth, Anda perlu mengakses Web Bluetooth API yang memicu kemampuan Bluetooth perangkat dari browser.
• Persyaratan Sistem Operasi: Silakan lihat tabel berikut tentang dukungan Autentikasi Lintas Perangkat untuk sistem operasi yang berbeda per Maret 2025. Autentikator berarti perangkat dapat berfungsi sebagai perangkat yang menyimpan passkey (dalam skenario kami, ponsel cerdas). Klien berarti perangkat yang membuat kode QR dan tempat pengguna mencoba masuk (dalam skenario kami, desktop):

Sumber: passkeys.dev

Proses untuk menggunakan autentikasi lintas platform passkey (transportasi hibrida) melalui kode QR terlihat sebagai berikut:

Kode QR untuk autentikasi lintas platform passkey (transportasi hibrida) dihasilkan ketika pengguna mencoba mengakses layanan di perangkat di mana passkey yang terdaftar tidak ada, tetapi layanan tahu bahwa pengguna seharusnya memiliki passkey. Biasanya, tombol Pindai kode QR atau ajakan bertindak serupa disediakan dalam antarmuka autentikasi.

Atas permintaan pengguna, perangkat memulai pembuatan kode QR. Kode QR ini mengkodekan pengidentifikasi sesi yang unik dan sensitif terhadap waktu. Pengidentifikasi ini terikat pada sesi yang sementara dipertahankan oleh server autentikasi, menunggu penyelesaian proses autentikasi.

Pengguna memindai kode QR ini dengan perangkat di mana passkey mereka tersedia. Langkah-langkah keamanan meliputi:

• Penggunaan sekali pakai: Pengidentifikasi sesi dalam kode QR berlaku untuk sekali pakai, mencegah serangan replay.
• Enkripsi: Semua data dalam kode QR dienkripsi, memastikan bahwa setiap komunikasi yang disadap tidak dapat diuraikan oleh pihak yang tidak berwenang.

Kode QR yang dipindai menyimpan URI tertentu dengan skema FIDO, misalnya: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

Memindai kode QR memicu perangkat kedua pengguna (misalnya, ponsel cerdas atau tablet) untuk menafsirkan URI FIDO dan berkomunikasi dengan server autentikasi, mengirimkan sinyal bahwa pengguna mencoba untuk mengautentikasi melalui perangkat baru (misalnya, laptop teman). Tindakan ini mendorong server untuk menghasilkan tantangan kriptografis, yang unik untuk upaya autentikasi ini.

Tantangan dikirim kembali ke perangkat kedua pengguna (misalnya, ponsel cerdas atau tablet), tempat passkey mereka disimpan. Perangkat kemudian membuat tanda tangan digital menggunakan kunci privat yang terkait dengan passkey, tanpa kunci privat pernah meninggalkan perangkat (misalnya, ponsel cerdas atau tablet). Tantangan yang ditandatangani (tanda tangan) kemudian dikirim kembali ke server melalui terowongan terenkripsi yang aman melalui internet, memverifikasi integritas dan asal upaya autentikasi.

Server memvalidasi tanda tangan menggunakan kunci publik yang sesuai yang sudah terkait dengan akun pengguna. Setelah validasi berhasil, server mengonfirmasi autentikasi, memungkinkan pengguna untuk mengakses layanan di perangkat baru.

Beberapa aspek privasi dan keamanan penting lainnya yang perlu dipertimbangkan:

• Tidak Ada Pertukaran Data Bluetooth, Murni Internet: Penting untuk dicatat bahwa dalam autentikasi lintas platform passkey berbasis kode QR ini (transportasi hibrida), Bluetooth tidak terlibat dalam pertukaran data. Proses ini sepenuhnya bergantung pada koneksi Internet untuk transmisi data terenkripsi antara perangkat dan server. Namun, Bluetooth digunakan untuk pemeriksaan kedekatan kedua perangkat.
• Kunci Privat Tidak Meninggalkan Perangkat: Selama proses ini, kunci privat pengguna tetap aman di perangkat mereka.
• Tidak Ada Paparan Data Sensitif: Tidak ada informasi passkey sensitif atau kunci privat yang ditransfer atau diekspos selama proses autentikasi.
• Kriptografi Asimetris: Mekanisme tantangan-respons memastikan bahwa yang dikirim hanyalah versi tantangan yang ditandatangani dan tidak dapat digunakan kembali yang tidak dapat dieksploitasi untuk akses yang tidak sah.

Dengan mematuhi protokol teknis dan keamanan ini, metode kode QR untuk autentikasi lintas platform passkey (transportasi hibrida) menjunjung tinggi standar keamanan yang tinggi sambil menyediakan cara yang nyaman bagi pengguna untuk mengautentikasi identitas mereka di perangkat baru.

Selain proses pemindaian kode QR, ada juga pemeriksaan kedekatan melalui Bluetooth (caBLE). Memastikan bahwa klien dan autentikator secara fisik berdekatan adalah salah satu manfaat utama dari protokol WebAuthn. Wawasan lebih lanjut tentang cara kerja proses ini dijelaskan sebagai berikut:

Bluetooth Low Energy (BLE) adalah teknologi komunikasi nirkabel yang dirancang untuk pertukaran data jarak pendek. Ini memainkan peran penting dalam mengonfirmasi kedekatan fisik perangkat selama proses autentikasi.

caBLE adalah protokol yang memfasilitasi transfer informasi autentikasi yang aman antar perangkat menggunakan BLE. Saat menggunakan caBLE untuk autentikasi lintas platform passkey (transportasi hibrida), perangkat yang menyimpan passkey mengonfirmasi kedekatan perangkat yang meminta melalui sinyal BLE. Setelah kedekatan diverifikasi, proses autentikasi berlanjut, memanfaatkan BLE untuk komunikasi lokal yang aman.

Pengalaman pengguna ditingkatkan karena metode ini biasanya memerlukan lebih sedikit interaksi pengguna langsung; perangkat yang berdekatan secara fisik akan saling mendeteksi secara otomatis. Untuk keamanan, caBLE menawarkan keuntungan yang signifikan - ini memastikan bahwa proses autentikasi hanya dilakukan ketika kedua perangkat berdekatan, mencegah penyerang jarak jauh memulai proses autentikasi.

Bayangkan menerima kode QR yang mengarahkan ke situs berbahaya. Jika autentikasi dilakukan melalui kode QR ini, ada risiko bahwa sesi atau cookie mungkin dibajak. BLE menghindari masalah ini dengan tidak mengandalkan pemindaian visual, melainkan pada kehadiran fisik perangkat. Pemeriksaan kedekatan ini meminimalkan risiko serangan man-in-the-middle, karena pemeriksaan kedekatan tidak terjadi melalui internet atau media visual.

Tidak seperti metode lain, caBLE sebenarnya tidak menukar data autentikasi seperti passkey. Sebaliknya, ia menggunakan BLE sebagai saluran konfirmasi untuk menetapkan bahwa perangkat secara fisik berdekatan. Pemeriksaan ini dirancang untuk menjadi bagian dari proses autentikasi multi-faktor di mana kedekatan BLE adalah salah satu faktornya, memastikan bahwa bahkan jika faktor lain dikompromikan, tanpa kedekatan fisik, akses tidak diberikan.

Dengan mengintegrasikan protokol caBLE, pengembang dapat menawarkan metode yang aman dan ramah pengguna untuk autentikasi lintas platform passkey (transportasi hibrida) yang meningkatkan keamanan keseluruhan proses autentikasi. Pemeriksaan kedekatan menambahkan lapisan perlindungan tambahan yang sederhana bagi pengguna namun secara efektif melindungi dari jenis serangan siber canggih tertentu.

Manfaat berikut dari metode autentikasi lintas platform passkey (transportasi hibrida) ini ada:

Autentikasi passkey lintas platform melalui kode QR dan Bluetooth (transportasi hibrida) adalah cara untuk meningkatkan UX dalam skenario lintas platform dibandingkan dengan tidak menawarkan kemungkinan sama sekali. Namun, alur pengguna benar-benar baru bagi sebagian besar pengguna dan kami tidak berharap banyak pengguna non-teknis untuk memahami apa yang terjadi ketika mereka pertama kali menemukan alur ini. Satu-satunya kemiripan pengenalan alur kode QR dapat ditemukan pada alur masuk untuk misalnya WhatsApp Web atau Discord di mana kode QR digunakan (di sini fungsionalitasnya berbeda). Jadi, proses autentikasi passkey lintas platform yang dianalisis melalui kode QR / Bluetooth (transportasi hibrida) meminimalkan upaya pengguna dalam skenario lintas platform, karena tidak perlu memasukkan kredensial secara manual, tetapi alur keseluruhan masih tidak diketahui oleh sebagian besar pengguna.

Keamanan autentikasi lintas platform passkey (transportasi hibrida) diperkuat oleh teknik kriptografi canggih. Ketika kode QR dipindai atau koneksi Bluetooth dibuat untuk autentikasi, tantangan dan respons kriptografis memastikan bahwa hanya perangkat yang dituju yang dapat berhasil menyelesaikan proses autentikasi.

Pemeriksaan kedekatan melalui Bluetooth menambahkan lapisan keamanan tambahan, mengonfirmasi bahwa upaya autentikasi dilakukan oleh seseorang dengan akses fisik ke perangkat sekunder.

Selama proses autentikasi lintas platform (transportasi hibrida), passkey tidak pernah disimpan sementara di perangkat atau server perantara, yang mencegah risiko passkey disadap atau bocor selama proses transfer. Autentikasi terjadi secara waktu nyata, dan passkey tetap terikat pada perangkat utama pengguna, menjaga integritasnya.

Metode autentikasi kode QR dan Bluetooth secara inheren memberikan perlindungan terhadap phishing. Pengguna cenderung tidak tertipu untuk memberikan passkey ke situs berbahaya karena proses autentikasi memerlukan tindakan fisik yang spesifik untuk perangkat tepercaya pengguna.

Proses memindai kode QR atau menghubungkan melalui Bluetooth biasanya terjadi di lingkungan tepercaya, mengurangi kemungkinan pengguna secara tidak sengaja membahayakan kredensial mereka.

Kekurangan berikut dari metode autentikasi lintas platform passkey (transportasi hibrida) ini ada:

Memperkenalkan teknologi baru apa pun dapat menyebabkan kebingungan pengguna, terutama jika pengguna tidak melek teknologi. Autentikasi lintas platform passkey melalui kode QR dan Bluetooth (transportasi hibrida) adalah pergeseran signifikan dari metode autentikasi tradisional, dan beberapa pengguna mungkin merasa proses baru ini sulit untuk dipahami, yang berpotensi menyebabkan tingkat adopsi yang lebih lambat. Namun, kami berharap pengguna pada akhirnya akan terbiasa, sehingga perubahannya mungkin lebih sulit pada awalnya dan akan lebih lancar dan lebih diterima seiring waktu.

Keberhasilan autentikasi lintas platform passkey (transportasi hibrida) sangat bergantung pada perangkat pengguna yang memiliki kemampuan yang diperlukan, seperti kamera yang dapat memindai kode QR dan fungsionalitas Bluetooth. Pengguna dengan perangkat lama yang tidak memiliki fitur ini tidak akan dapat memanfaatkan autentikasi lintas platform passkey (transportasi hibrida), menciptakan kesenjangan digital berdasarkan keterbatasan perangkat keras.

Perilaku pengguna bisa tidak dapat diprediksi, dan ketergantungan pada pengguna untuk melakukan tindakan spesifik seperti memindai kode QR atau mengaktifkan Bluetooth dapat menimbulkan kesalahan pengguna. Misalnya, Bluetooth terkadang dapat dilihat sebagai tantangan UX karena masalah pemasangan, masalah penemuan, dan ketidakpercayaan umum pengguna terhadap teknologi nirkabel untuk transaksi yang aman.

Pengembang menghadapi tugas untuk terus memperbarui dan memelihara sistem untuk mendukung metode autentikasi terbaru. Mengintegrasikan autentikasi lintas platform passkey (transportasi hibrida) ke dalam sistem yang ada mengharuskan pengembang untuk tetap mengikuti standar baru, mengadopsi API baru, dan memastikan kompatibilitas mundur, yang dapat memakan banyak sumber daya dan waktu.

Untuk setiap perangkat baru atau permintaan masuk berikutnya, passkey baru perlu dibuat jika tidak menggunakan akun cloud yang disinkronkan seperti iCloud Keychain atau pengelola kata sandi. Ini dapat menambah kerumitan pada pengalaman pengguna dan dapat menimbulkan frustrasi jika pengguna tidak terbiasa dengan prosesnya atau jika tidak dibuat intuitif.

Ada kebutuhan inheren untuk pendidikan pengguna saat menerapkan metode keamanan baru seperti autentikasi lintas platform passkey (transportasi hibrida). Memastikan bahwa pengguna memahami cara menggunakan kode QR dan Bluetooth dengan aman memerlukan komunikasi yang jelas dan mungkin dukungan pelanggan yang ekstensif.

Meskipun autentikasi lintas platform passkey melalui kode QR dan Bluetooth (transportasi hibrida) menghadirkan kemajuan signifikan dalam teknologi autentikasi, potensi kekurangan ini menyoroti perlunya desain yang ramah pengguna, sistem pendukung yang kuat, dan transisi bertahap yang dikomunikasikan dengan baik dari metode tradisional ke metode inovatif. Seperti halnya pergeseran teknologi apa pun, menyeimbangkan manfaat inovasi dengan tantangannya akan menjadi kunci keberhasilan implementasi dan penerimaan pengguna yang luas.

Sebagai penafian: kami mengabaikan kunci keamanan perangkat keras (misalnya, YubiKeys) dalam pengujian berikut dan hanya menggunakan autentikator platform yang terpasang di perangkat (misalnya, Face ID, Touch ID, Windows Hello). Dalam kasus kunci keamanan perangkat keras (misalnya, YubiKey), nilai untuk transports akan menjadi usb atau nfc misalnya.

Kami menggunakan kombinasi perangkat / browser berikut dan Passkeys Debugger untuk menguji perilaku. Android tidak dipertimbangkan karena Android tidak dapat berfungsi sebagai klien autentikasi lintas platform (transportasi hibrida) (lihat tabel di atas):

Untuk menguji perilaku, kami membuat untuk setiap kombinasi passkey baru dengan properti berikut:

• userName: alex muller (tidak ada pengaruh dalam tes ini)
• authenticatorAttachment: platform (karena kami ingin mengecualikan kunci keamanan perangkat keras seperti YubiKeys)
• residentKey: preferred (tidak ada pengaruh dalam tes ini)
• userVerification: preferred (tidak ada pengaruh dalam tes ini)
• attestation: none (tidak ada pengaruh dalam tes ini)
• hints: empty (lihat penjelasan di bawah)
• usePRF: no (tidak ada pengaruh dalam tes ini)

Setelah pembuatan passkey berhasil, kami kemudian memodifikasi input properti server WebAuthn allowCredentials dan memulai permintaan masuk. Kami ingin meniru passkey yang dihapus pada perangkat tempat kami membuat passkey, sehingga perangkat / browser mencari perangkat lain yang dapat menyediakan passkey melalui kode QR / Bluetooth. Oleh karena itu, kami mengubah ID kredensial dan menetapkan nilai CHANGED-ID, sehingga pencocokan gagal. Selain itu, kami mengubah properti transports dari kredensial WebAuthn di allowCredentials dan menetapkan untuk setiap kombinasi perangkat / browser nilai-nilai berikut:

1. transports: [internal, hybrid]: Passkey dapat digunakan dari autentikator platform (misalnya, Face ID, Touch ID, Windows Hello) atau melalui autentikasi lintas platform
2. transports: [internal]: Passkey dapat digunakan dari autentikator platform (misalnya, Face ID, Touch ID, Windows Hello)
3. Tidak ada properti transports yang diatur: perilaku default yang tidak memberikan batasan

Di situs pengujian WebAuthn, ada juga fitur baru WebAuthn Level 3 untuk petunjuk agen pengguna yang disediakan. Fitur ini dapat meningkatkan pengalaman pengguna jika pihak yang mengandalkan memiliki asumsi tertentu tentang bagaimana permintaan masuk dapat diselesaikan dengan cara yang paling ramah pengguna. Dalam tes ini, kami mengabaikan fitur ini karena belum diluncurkan. Silakan lihat spesifikasi untuk detail lebih lanjut.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

Cukup membingungkan, kode QR juga ditampilkan di sini, meskipun kami hanya mengizinkan kredensial internal. Kami tidak dapat menemukan alasan yang valid untuk perilaku ini.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

Untuk beberapa alasan, bagian dari modal muncul dalam bahasa Jerman, yang merupakan salah satu bahasa yang diinstal.

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, melalui perangkat yang dikenal, dan melalui kunci keamanan perangkat keras.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

Cukup membingungkan, kode QR juga ditampilkan di sini, meskipun kami hanya mengizinkan kredensial internal. Kami tidak dapat menemukan alasan yang valid untuk perilaku ini.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

Untuk beberapa alasan, bagian dari modal muncul dalam bahasa Jerman, yang merupakan salah satu bahasa yang diinstal.

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, melalui perangkat yang dikenal, dan melalui kunci keamanan perangkat keras.

Saat membuat passkey, kami menerima kesalahan berikut (namun passkey tetap dibuat):

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

Cukup membingungkan, kode QR juga ditampilkan di sini, meskipun kami hanya mengizinkan kredensial internal. Kami tidak dapat menemukan alasan yang valid untuk perilaku ini.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

Untuk beberapa alasan, bagian dari modal muncul dalam bahasa Jerman, yang merupakan salah satu bahasa yang diinstal.

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, melalui perangkat yang dikenal, dan melalui kunci keamanan perangkat keras.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini). Selain itu, Anda dapat langsung memilih salah satu perangkat yang dikenal untuk menggunakan passkey dari sana.

Modalnya sangat berbeda dengan yang ada di Windows di Chrome 119.

Ini adalah perilaku yang diharapkan, karena kami hanya mengizinkan penggunaan passkey internal tetapi tidak dapat menemukan kredensial internal di perangkat (kami tidak diizinkan menggunakan passkey hibrida). Autentikasi passkey gagal pada langkah ini dan dalam implementasi kehidupan nyata, Anda perlu menyediakan metode autentikasi cadangan.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator platform lintas / autentikator roaming. Selain itu, Anda dapat langsung memilih salah satu perangkat yang dikenal untuk menggunakan passkey dari sana.

Modalnya sangat berbeda dengan yang ada di Windows di Chrome 119.

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Touch ID, melalui kode QR, melalui perangkat yang dikenal, dan melalui kunci keamanan perangkat keras.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

Cukup membingungkan, kode QR juga ditampilkan di sini, meskipun kami hanya mengizinkan kredensial internal. Kami tidak dapat menemukan alasan yang valid untuk perilaku ini.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

Seperti yang diharapkan, sebagian besar bentuk autentikasi passkey diizinkan: melalui Touch ID, melalui kode QR, dan melalui kunci keamanan perangkat keras. Untuk beberapa alasan, perangkat yang dikenal tidak ditampilkan.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

Cukup membingungkan, kode QR juga ditampilkan di sini, meskipun kami hanya mengizinkan kredensial internal. Kami tidak dapat menemukan alasan yang valid untuk perilaku ini.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

Seperti yang diharapkan, sebagian besar bentuk autentikasi passkey diizinkan: melalui Face ID, melalui kode QR, dan melalui kunci keamanan perangkat keras. Untuk beberapa alasan, perangkat yang dikenal tidak ditampilkan.

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

Cukup membingungkan, kode QR juga ditampilkan di sini, meskipun kami hanya mengizinkan kredensial internal. Kami tidak dapat menemukan alasan yang valid untuk perilaku ini.

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

Seperti yang diharapkan, sebagian besar bentuk autentikasi passkey diizinkan: melalui Face ID, melalui kode QR, dan melalui kunci keamanan perangkat keras. Untuk beberapa alasan, perangkat yang dikenal tidak ditampilkan.

Berikutnya, untuk perangkat Windows 10, kami memutuskan untuk melangkah lebih jauh dan menganalisis bagaimana perilakunya jika Bluetooth dinonaktifkan atau tidak tersedia sama sekali di mesin Windows 10. Terutama untuk perangkat desktop yang lebih tua, ini masih merupakan skenario yang sangat umum karena perangkat ini sering tidak memiliki modul Bluetooth, sehingga membuat autentikasi lintas platform melalui kode QR dan Bluetooth menjadi tidak mungkin.

8.8.1.1 transports: [internal, hybrid]

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini - tangkapan layar pertama) atau memilih untuk memindai kode QR (tangkapan layar kedua).

8.8.1.2 transports: [internal]

Cukup membingungkan, Anda diminta untuk memasukkan kode PIN Windows Hello Anda (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.8.1.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.8.1.4 allowCredentials kosong

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, melalui perangkat yang dikenal, dan melalui kunci keamanan perangkat keras.

8.8.2.1 transports: [internal, hybrid]

Ini adalah pesan yang sangat membingungkan bagi pengguna, karena tidak dinyatakan secara eksplisit apa yang harus mereka lakukan dan bagaimana mereka dapat mengautentikasi. Satu-satunya pilihan yang mereka miliki adalah mengklik "Batal", membuat skenario ini menjadi jalan buntu.

8.8.2.2 transports: [internal]

Perilaku ini sama dengan kasus di mana Bluetooth diaktifkan. Sangat membingungkan bahwa pengguna diminta untuk memasukkan kode PIN Windows Hello (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.8.2.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi satu-satunya pilihan yang Anda miliki adalah menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.8.2.4 allowCredentials kosong

Autentikasi passkey hanya dimungkinkan melalui Windows Hello dan kunci keamanan perangkat keras.

8.9.1.1 transports: [internal, hybrid]

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

8.9.1.2 transports: [internal]

Cukup membingungkan, Anda diminta untuk memasukkan kode PIN Windows Hello Anda (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.9.1.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.9.1.4 allowCredentials kosong

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, dan melalui kunci keamanan perangkat keras. Untuk beberapa alasan, perangkat yang dikenal tidak ditampilkan.

8.9.2.1 transports: [internal, hybrid]

Ini adalah pesan yang sangat membingungkan bagi pengguna, karena tidak dinyatakan secara eksplisit apa yang harus mereka lakukan dan bagaimana mereka dapat mengautentikasi. Satu-satunya pilihan yang mereka miliki adalah mengklik "Batal", membuat skenario ini menjadi jalan buntu.

8.9.2.2 transports: [internal]

Perilaku ini sama dengan kasus di mana Bluetooth diaktifkan. Sangat membingungkan bahwa pengguna diminta untuk memasukkan kode PIN Windows Hello (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.9.2.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi satu-satunya pilihan yang Anda miliki adalah menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.9.2.4 allowCredentials kosong

Autentikasi passkey hanya dimungkinkan melalui Windows Hello dan kunci keamanan perangkat keras.

8.10.1.1 transports: [internal, hybrid]

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

8.10.1.2 transports: [internal]

Cukup membingungkan, Anda diminta untuk memasukkan kode PIN Windows Hello Anda (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.10.1.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.10.1.4 allowCredentials kosong

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, dan melalui kunci keamanan perangkat keras. Untuk beberapa alasan, perangkat yang dikenal tidak ditampilkan.

8.10.2.1 transports: [internal, hybrid]

Ini adalah pesan yang sangat membingungkan bagi pengguna, karena tidak dinyatakan secara eksplisit apa yang harus mereka lakukan dan bagaimana mereka dapat mengautentikasi. Satu-satunya pilihan yang mereka miliki adalah mengklik "Batal", membuat skenario ini menjadi jalan buntu. Untuk beberapa alasan, bagian dari modal Keamanan Windows juga ditampilkan dalam bahasa Jerman (bahasa kedua yang diinstal di perangkat ini).

8.10.2.2 transports: [internal]

Perilaku ini sama dengan kasus di mana Bluetooth diaktifkan. Sangat membingungkan bahwa pengguna diminta untuk memasukkan kode PIN Windows Hello (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.10.2.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi satu-satunya pilihan yang Anda miliki adalah menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.10.2.4 allowCredentials kosong

Autentikasi passkey hanya dimungkinkan melalui Windows Hello dan kunci keamanan perangkat keras.

8.11.1.1 transports: [internal, hybrid]

Seperti yang diharapkan, tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR dan menggunakan passkey di perangkat lain (karena sistem tahu bahwa ada passkey untuk pengguna ini).

8.11.1.2 transports: [internal]

Cukup membingungkan, Anda diminta untuk memasukkan kode PIN Windows Hello Anda (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.11.1.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi disarankan untuk memindai kode QR atau menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.11.1.4 allowCredentials kosong

Seperti yang diharapkan, semua bentuk autentikasi passkey diizinkan: melalui Windows Hello, melalui kode QR, dan melalui kunci keamanan perangkat keras. Untuk beberapa alasan, perangkat yang dikenal tidak ditampilkan.

8.11.2.1 transports: [internal, hybrid]

Ini adalah pesan yang sangat membingungkan bagi pengguna, karena tidak dinyatakan secara eksplisit apa yang harus mereka lakukan dan bagaimana mereka dapat mengautentikasi. Satu-satunya pilihan yang mereka miliki adalah mengklik "Batal", membuat skenario ini menjadi jalan buntu.

8.11.2.2 transports: [internal]

Perilaku ini sama dengan kasus di mana Bluetooth diaktifkan. Sangat membingungkan bahwa pengguna diminta untuk memasukkan kode PIN Windows Hello (atau pemindaian sidik jari / wajah jika diatur di perangkat), meskipun kami mengubah ID kredensial (sehingga seharusnya tidak menemukan kredensial karena tidak ditentukan dalam properti allowCredentials). Namun, setelah mengirimkan kode PIN Windows Hello, sebuah kesalahan dilemparkan: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Dari perspektif pengguna, ini adalah perilaku yang agak membingungkan tetapi masuk akal karena dapat memberikan informasi tentang passkey pengguna tanpa persetujuan pengguna.

8.11.2.3 Tidak ada properti transports yang diatur

Tidak ada passkey lokal yang cocok, jadi satu-satunya pilihan yang Anda miliki adalah menggunakan kunci keamanan perangkat keras (misalnya, YubiKey) / autentikator lintas platform / autentikator roaming.

8.11.2.4 allowCredentials kosong

Autentikasi passkey hanya dimungkinkan melalui Windows Hello dan kunci keamanan perangkat keras.

• Gunakan pustaka dan kerangka kerja yang mengabstraksi beberapa kerumitan dari API WebAuthn murni.
• Pertimbangkan skenario autentikasi lintas platform sejak awal untuk memastikan basis pengguna yang luas dapat memperoleh manfaat dari implementasi passkey Anda. Tergantung pada pilihan desain Anda, Anda juga dapat menawarkan metode masuk alternatif dalam skenario ini.
• Kembangkan mekanisme fallback untuk skenario di mana autentikasi lintas platform passkey (transportasi hibrida) mungkin tidak dimungkinkan karena keterbatasan perangkat.
• Keputusan desain terbesar adalah memutuskan apakah Anda ingin mempromosikan autentikasi passkey lintas platform melalui kode QR / Bluetooth (transportasi hibrida) dan menjadikannya metode yang menonjol untuk autentikasi passkey atau menggunakan petunjuk untuk tidak mempromosikannya secara aktif. Dalam kasus terakhir, selalu dicoba untuk segera menggunakan passkey yang disimpan secara internal dan hanya jika tidak ada passkey internal yang ditemukan, kode QR untuk autentikasi lintas platform (transportasi hibrida) ditampilkan. Ini perlu didefinisikan dalam opsi server WebAuthn Anda di properti excludeCredentials dan allowCredentials. Di properti excludeCredentials dari server WebAuthn Anda, Anda dapat melihat informasi transport tentang kredensial yang sudah dibuat. Di properti allowCredentials, Anda dapat menentukan perilaku dalam proses masuk (lihat tes di atas).
• Selain itu, Anda tidak dapat mencegah autentikasi passkey lintas platform (transportasi hibrida) sepenuhnya (lihat tes di atas dengan transports: [internal]), jadi Anda perlu bersiap bahwa pengguna Anda akan menemukan metode ini dan akan memiliki pertanyaan. Terjadinya autentikasi lintas platform (transportasi hibrida) ini akan terjadi terutama jika pengguna mulai menghapus passkey secara lokal.

• Buat panduan dan tutorial komprehensif yang memandu pengguna melalui proses autentikasi lintas platform passkey (transportasi hibrida).
• Gunakan tooltip dalam aplikasi dan bagian bantuan kontekstual untuk memandu pengguna selama pengalaman autentikasi lintas platform passkey (transportasi hibrida) pertama mereka.
• Sediakan bagian FAQ dan pemecahan masalah di situs web Anda atau di dalam aplikasi.

• Terapkan sesi berbatas waktu untuk masuk passkey melalui kode QR atau Bluetooth untuk memastikan bahwa akses hanya bersifat sementara dan aman.
• Pastikan bahwa autentikasi lintas platform passkey (transportasi hibrida) tidak merusak protokol keamanan yang ada, menjaga integritas data pengguna.
• Pertimbangkan implikasi privasi dan pastikan bahwa setiap akses sementara yang diberikan melalui autentikasi lintas platform passkey (transportasi hibrida) dicatat dan dipantau sesuai dengan praktik terbaik keamanan.

Autentikasi lintas platform passkey melalui kode QR / Bluetooth (transportasi hibrida) menawarkan keseimbangan antara keamanan dan UX. Namun, ini adalah proses yang sama sekali baru bagi sebagian besar pengguna dan dapat menyebabkan banyak situasi yang membingungkan, jadi perlu dipikirkan dengan cermat jika Anda ingin mempromosikannya.

Kami berharap kami dapat memberikan sedikit pencerahan tentang topik autentikasi lintas platform passkey (transportasi hibrida) melalui kode QR / Bluetooth, menjelaskan cara mengatur berbagai hal dan bagaimana perilaku pada kombinasi perangkat / browser yang berbeda terlihat. Jika Anda memiliki pertanyaan, jangan ragu untuk menghubungi kami melalui komunitas passkey kami atau berlangganan Substack passkey kami. Mari kita buat Internet menjadi tempat yang lebih aman dengan menyebarkan passkey.