Masalah Hari Ke-2 Kunci Sandi: 5 Risiko setelah Peluncuran

1. Pendahuluan: Risiko Kunci Sandi setelah Peluncuran#

Jangan implementasikan kunci sandi.

Setidaknya tidak dengan cara apa pun dan tidak jika Anda tidak memiliki sumber daya untuk melakukannya dengan benar.

Ya, kunci sandi (passkeys) adalah hal terbaik yang terjadi pada autentikasi konsumen dalam satu dekade terakhir. Ya, mereka membunuh phising. Ya, mereka dapat meningkatkan UX secara besar-besaran. Namun, kunci sandi yang diterapkan dengan salah juga dapat menyebabkan banyak kerugian.

Mengimplementasikan server WebAuthn tidak terlalu rumit. Tantangan sebenarnya adalah segala sesuatu di sekitarnya. Mengoperasikan kunci sandi secara efisien dalam skala besar memerlukan perencanaan ke depan. Anda perlu memikirkan semua masalah "Hari ke-2" - realitas operasional yang baru muncul setelah Anda memulai peluncuran kunci sandi.

Artikel ini membahas lima masalah Hari ke-2 yang secara konsisten membunuh proyek kunci sandi. Jika Anda tidak dapat menyelesaikan semuanya, Anda belum siap untuk meluncurkan kunci sandi. Jika Anda bisa, Anda akan membangun autentikasi yang lebih aman dan lebih mudah digunakan daripada yang bisa ditawarkan oleh kata sandi.

2. Apa itu Masalah Hari Ke-2 Kunci Sandi?#

Dalam rekayasa perangkat lunak, "Hari ke-1" adalah saat Anda membangun dan meluncurkannya. "Hari ke-2" adalah saat Anda mengoperasikan, memelihara, dan menskalakan apa yang telah Anda luncurkan. Untuk kunci sandi, Hari ke-1 bisa sangat mudah:

• integrasikan server WebAuthn ke dalam stack enterprise Anda
• tambahkan alur frontend dan luncurkan.

Sebagian besar tim bisa mendapatkan implementasi kunci sandi dasar berjalan dalam beberapa hari atau minggu.

Hari ke-2 adalah saat proyek gagal. Ini adalah momen pengguna nyata pada perangkat nyata dengan edge case nyata berinteraksi dengan sistem kunci sandi Anda. Ini adalah saat Anda menyadari bahwa demo mengkilap yang berfungsi sempurna di MacBook Anda, rusak di laptop Windows yang menjalankan Chrome di balik proxy perusahaan. Ini adalah saat tim dukungan Anda dibanjiri tiket "Saya tidak bisa masuk lagi".

Kesenjangan antara demo kunci sandi yang berfungsi dan penerapan kunci sandi tingkat produksi sangatlah besar. Kami telah membahas jebakan implementasi teknis dan alasan strategis mengapa proyek kunci sandi gagal sebelumnya. Artikel ini berfokus secara khusus pada apa yang terjadi setelah Anda go live dari perspektif operasional.

Berikut adalah lima masalah Hari ke-2 yang akan kami bahas:

• Masalah 1: Pemulihan dan Fallback sulit diamankan
• Masalah 2: Edge Case Lintas Perangkat dan Lintas Ekosistem merusak Alur Kunci Sandi
• Masalah 3: Aplikasi Native melipatgandakan Kompleksitas Kunci Sandi
• Masalah 4: Adopsi adalah Masalah Produk, bukan Masalah Teknologi
• Masalah 5: Perubahan Platform merusak Kunci Sandi secara diam-diam

3. Masalah 1: Pemulihan dan Fallback sulit diamankan#

Jika Anda tidak merancang pemulihan dan fallback dengan benar, Anda akan mengunci pengguna dalam skala besar atau Anda diam-diam memperkenalkan kembali alur rentan phising yang sama dengan yang ingin Anda hilangkan.

3.1 Risiko Penguncian Akun dalam Skala Besar#

Pertimbangkan pengguna yang mendaftar kunci sandi di iPhone mereka, lalu kehilangan iPhone tersebut. Biasanya, sebagian besar kasus pemulihan ini sekarang ditangani oleh manajer kredensial (kemungkinan besar iCloud Keychain di iPhone). Selama pengguna memiliki akses ke akun Apple mereka, mereka memiliki kunci sandi yang disinkronkan untuk masuk (log in) di perangkat baru. Tetapi bagaimana jika mereka tidak lagi memiliki akses ke akun cloud tersebut? Inilah saat jalur pemulihan rutin Anda berperan.

Katakanlah Anda mengasumsikan bahwa private key (kunci privat) masih tersedia di perangkat yang dicoba pengguna untuk masuk, sehingga Anda memulai seremonial login WebAuthn. Ini akan menghasilkan modal OS / browser yang meminta pengguna untuk "masuk dengan kunci sandi Anda di perangkat lain". Pada dasarnya, pengguna sekarang terkunci dari akun mereka. Tidak ada perangkat lain tempat kunci sandi disimpan. Pengguna menjadi sangat bingung. Kalikan ini dengan ribuan pengguna dan Anda akan menghadapi krisis dukungan.

Reaksi umumnya adalah menambahkan reset akun berbasis email sebagai fallback. Tetapi ini menggagalkan tujuan dari kunci sandi: Anda baru saja memperkenalkan kembali saluran pemulihan yang rentan phising. Penyerang yang dapat membahayakan email pengguna kini dapat mem-bypass implementasi kunci sandi tahan phising Anda sepenuhnya.

3.2 Merancang Fallback tanpa memperkenalkan kembali Phising#

Menurut pendapat kami, pendekatan yang tepat adalah pemulihan berlapis:

1. Kunci sandi yang disinkronkan sebagai strategi utama: pastikan pengguna membuat kunci sandi yang disinkronkan (melalui iCloud Keychain, Google Password Manager atau penyedia kunci sandi pihak ketiga) sehingga kehilangan perangkat tidak berarti kehilangan kredensial
2. Autentikasi lintas perangkat sebagai lapisan kedua: izinkan pengguna untuk mengautentikasi dari perangkat lain di mana kunci sandi lain tersedia dengan memindai kode QR
3. Verifikasi identitas (IDV) sebagai lapisan ketiga: tawarkan IDV otomatis dengan pemeriksaan keaktifan (liveness checks) alih-alih fallback ke kata sandi/OTP.
4. Kredensial yang dapat diverifikasi secara digital sebagai lapisan keempat: ini adalah versi pemulihan akun yang paling aman, menjaga privasi, dan ramah pengguna. Ini memungkinkan pengguna untuk menggunakan kredensial yang dapat diverifikasi secara digital (mis. ID nasional digital atau mDL) untuk memverifikasi identitas mereka dengan menggunakan API standar (mis. Digital Credentials API). Teknologi ini masih cukup baru dan tingkat adopsinya tidak tinggi tetapi akan memainkan peran utama dalam beberapa bulan dan tahun mendatang.

Secara umum, Anda perlu memutuskan lapisan pemulihan akun mana yang dapat dijustifikasi dari perspektif biaya / gesekan. Misalnya, di ritel / e-commerce, Anda mungkin hanya menawarkan dua lapisan pertama dan menerima risiko phising karena alasan keuangan. Di industri lain, di mana keamanan lebih penting, Anda lanjut ke lapisan 3 dan 4.

Setiap lapisan menambah kompleksitas. Anda perlu memutuskan lapisan mana yang dibutuhkan use case Anda, membangunnya, mengujinya di semua kombinasi perangkat, dan memantau penggunaannya. Ini jauh lebih banyak pekerjaan daripada integrasi WebAuthn awal.

3.3 Apa yang salah dilakukan oleh sebagian besar Tim#

Sebagian besar tim terlalu menyederhanakan pemulihan (fallback ke kata sandi atau SMS OTP) atau terlalu mempersulitnya (mis. mewajibkan kunci keamanan perangkat keras untuk setiap pemulihan). Keseimbangan yang tepat tergantung pada model ancaman Anda, basis pengguna, dan persyaratan peraturan. Melakukan kesalahan berarti melemahkan postur keamanan Anda atau menciptakan begitu banyak gesekan sehingga pengguna meninggalkan alur tersebut.

4. Masalah 2: Edge Case Lintas Perangkat dan Lintas Ekosistem merusak Alur Kunci Sandi#

Pengguna Anda tidak hidup di dunia Apple-only yang bersih. Mereka berganti perangkat, mencampur Windows dengan iOS, menggunakan browser yang berbeda, dan bekerja pada pengaturan yang dikelola perusahaan. Di situlah alur kunci sandi rusak jika Anda belum merencanakannya.

4.1 Fragmentasi Ekosistem itu nyata#

Ekosistem kunci sandi mencakup tiga platform utama (Apple, Google, dan Microsoft), beberapa browser (Chrome, Safari, Firefox, dan Edge), puluhan penyedia kunci sandi / manajer kredensial (mis. 1Password, Bitwarden, Dashlane dan lainnya) dan banyak kombinasi OS/browser/perangkat. Setiap kombinasi dapat berperilaku sedikit berbeda, mis.:

• Apple menyinkronkan kunci sandi secara default melalui iCloud Keychain di seluruh iOS, iPadOS, dan macOS tetapi tidak ke Windows atau Android
• Google menyinkronkan melalui Google Password Manager di seluruh Android dan Chrome tetapi pengalamannya di iOS berbeda (Anda perlu mengaturnya secara manual)
• Windows memiliki perilaku kunci sandi sendiri yang berbeda secara signifikan dari platform lain
• Manajer kata sandi masing-masing menangani pembuatan dan pemilihan kunci sandi secara berbeda, terkadang bertentangan dengan prompt asli platform

4.2 Alur Autentikasi Lintas Perangkat#

Ketika pengguna membuat kunci sandi di iPhone mereka tetapi ingin masuk di laptop Windows, mereka dapat menggunakan autentikasi lintas perangkat (biasanya melalui kode QR dan Bluetooth). Alur ini berfungsi tetapi rapuh:

• Ini memerlukan Bluetooth untuk diaktifkan di kedua perangkat
• Firewall perusahaan dan kebijakan MDM dapat mengganggu karena ada tunnel yang disiapkan di latar belakang
• UX sangat bervariasi antar browser
• Pengguna sering tidak mengerti apa yang sedang terjadi atau mengapa mereka memindai kode QR

Kami telah melihat sendiri edge case ini di ribuan kombinasi perangkat. Jika Anda membangun kunci sandi secara in-house, Anda perlu menguji dan menangani setiap edge case tersebut. Jika tidak bisa, pengguna Anda akan mengalami kesalahan yang tidak dapat dijelaskan oleh tim dukungan Anda.

4.3 Ketidakkonsistenan Browser dan OS#

Bahkan pada perangkat yang sama, browser yang berbeda berperilaku berbeda. Chrome di macOS menampilkan modal kunci sandi yang berbeda dari Safari di macOS. Firefox memiliki perilakunya sendiri. Client hints dan deteksi agen pengguna menjadi sangat penting untuk memberikan alur yang tepat kepada pengguna yang tepat, tetapi menguraikannya dengan benar di semua kombinasi adalah beban pemeliharaan yang tidak pernah berakhir.

5. Masalah 3: Aplikasi Native melipatgandakan Kompleksitas Kunci Sandi#

Pengujian kunci sandi dan QA sudah menjadi tantangan untuk aplikasi web (kami membahasnya secara rinci di Masalah 5: Perubahan Platform). Tetapi jika produk Anda juga memiliki aplikasi iOS dan Android native, kompleksitasnya berlipat ganda karena keputusan arsitektur dan perilaku spesifik platform yang tidak pernah dihadapi oleh tim web-only.

5.1 Keputusan Native vs. WebView#

Keputusan pertama adalah apakah akan mengimplementasikan kunci sandi secara native atau melalui WebView. Setiap pendekatan memiliki trade-off:

Di iOS saja, Anda dapat memilih antara WKWebView, SFSafariViewController, SFAuthenticationSession dan ASWebAuthenticationSession - masing-masing dengan karakteristik dukungan kunci sandi yang berbeda. Di Android, Chrome Custom Tabs berperilaku berbeda dari WebView standar. Ini adalah keputusan yang tidak pernah harus dibuat oleh tim web-only, dan setiap pilihan menciptakan permukaan pemeliharaannya sendiri.

5.2 Perilaku Spesifik Platform di Aplikasi Native#

Di luar keputusan arsitektur, iOS dan Android menangani kunci sandi secara berbeda di tingkat OS:

• iOS mengintegrasikan kunci sandi dalam-dalam ke dalam manajer kredensial sistem, dengan perilaku autofill khusus yang dapat berubah di setiap versi iOS
• Android merutekan permintaan kunci sandi melalui Credential Manager API, yang berinteraksi dengan beberapa penyedia kunci sandi secara bersamaan
• Kondisi kesalahan (error states), perilaku timeout, dan prompt pengguna berbeda antar platform. Pengguna yang sama yang membatalkan (cancel) akan memunculkan NotAllowedError di web tetapi sebagai SimpleAuthenticationServices.AuthorizationError di iOS dan User cancelled the operation di Android's Credential Manager - lihat webAuthn errors in production untuk pemetaan kesalahan lintas platform secara lengkap
• Siklus peninjauan app store menambah penundaan ketika Anda perlu merilis perbaikan mendesak untuk regresi kunci sandi

5.3 Cakupan QA yang Dilipatgandakan#

Jika Anda mengoperasikan aplikasi web dan aplikasi native, Anda bukan hanya menggandakan upaya QA tetapi Anda melipatgandakannya. Web, iOS, dan Android masing-masing berperilaku sebagai lingkungan kunci sandi terpisah yang memerlukan pengujian end-to-end independen dan pemantauan. Dan tidak seperti web, di mana Anda dapat menerapkan perbaikan secara instan, perbaikan aplikasi native dibatasi oleh siklus peninjauan app store.

6. Masalah 4: Adopsi adalah Masalah Produk, bukan Masalah Teknologi#

"Kunci sandi didukung" bukan berarti "kunci sandi digunakan." Jika Anda tidak memiliki strategi peluncuran dan pengukuran, adopsi Anda akan mengecewakan dan proyek tersebut akan dicap gagal secara internal.

6.1 Mengapa Adopsi yang Rendah Membunuh Proyek Anda#

Kami telah membahas hal ini secara ekstensif dalam artikel kami tentang mengapa implementasi kunci sandi gagal: jika pengguna tidak beralih ke kunci sandi, proyek tersebut sudah gagal. Kata sandi tetap dominan, biaya SMS OTP tetap tinggi, risiko phising bertahan, dan organisasi Anda tidak melihat hasil atas investasi rekayasa yang signifikan.

Kasus bisnis untuk adopsi kunci sandi sangat kuat tetapi hanya jika adopsi benar-benar terjadi. Kami telah melihat enterprise meluncurkan kunci sandi dengan implementasi teknis hebat yang mencapai adopsi kurang dari 5% karena tidak ada yang memikirkan peluncuran dan strategi adopsi.

6.2 Adopsi Membutuhkan Pekerjaan Produk yang Disengaja#

Mendorong adopsi kunci sandi adalah tantangan produk yang membutuhkan:

• Progressive enrollment: mendorong pengguna untuk membuat kunci sandi pada momen yang tepat (mis. setelah berhasil masuk, selama peninjauan keamanan akun)
• Komunikasi pengguna yang jelas: menjelaskan apa itu kunci sandi dan mengapa kunci sandi lebih baik, dalam bahasa yang dipahami pengguna non-teknis
• Prompt yang sadar perangkat: hanya menawarkan pembuatan kunci sandi ketika perangkat pengguna benar-benar mendukungnya dengan baik, menghindari pengalaman yang membuat frustrasi pada konfigurasi yang tidak didukung
• Infrastruktur pengukuran: melacak tingkat pembuatan kunci sandi, tingkat keberhasilan login, tingkat fallback, dan tingkat pengabaian untuk mengidentifikasi dan memperbaiki hambatan

6.3 Seperti apa Adopsi yang "Bagus"#

Berdasarkan pengalaman kami dengan penerapan kunci sandi berskala besar, berikut yang harus ditargetkan enterprise:

Jika angka adopsi Anda terlihat seperti kolom "lemah" setelah tiga bulan, proyek tersebut sedang dalam masalah. Tanpa analitik untuk mengukur ini, Anda bahkan tidak akan tahu.

7. Masalah 5: Perubahan Platform merusak Kunci Sandi secara diam-diam#

Pembaruan OS dan browser mengubah prompt, perilaku autofill, dan alur fallback. Jika Anda tidak memiliki pemantauan berkelanjutan, Anda akan mendapatkan regresi dan tiket dukungan tanpa peringatan.

Kami baru saja menerbitkan ikhtisar komprehensif tentang kesalahan WebAuthn yang terjadi dalam produksi.

7.1 Mengapa Kunci Sandi sangat terpengaruh oleh Perubahan Platform#

Tidak seperti kata sandi (yang hanya berupa string yang divalidasi server Anda), kunci sandi bergantung pada integrasi yang mendalam dengan sistem operasi, browser, dan manajer kredensial. Saat Apple merilis versi iOS baru, prompt pembuatan kunci sandi mungkin terlihat berbeda. Saat Chrome memperbarui logika autofill-nya, alur login Anda mungkin rusak. Saat manajer kata sandi merilis versi baru, ia mungkin mulai mencegat permintaan kunci sandi dengan cara yang tidak Anda antisipasi.

Satu contoh baru-baru ini adalah bug iOS 26.2 di mana isUserVerifyingPlatformAuthenticatorAvailable() mengembalikan false di semua browser non-Safari (Chrome, Edge, Firefox), membutuhkan logika deteksi sadar platform menggunakan getClientCapabilities() sebagai perbaikan (workaround).

7.2 Pemantauan bukan opsional#

Untuk memastikan Anda mengetahui semua potensi bug dan melacak adopsinya, Anda perlu mengatur stack observabilitas autentikasi Anda. Kami merekomendasikan setidaknya hal berikut:

• Analitik autentikasi real-time: melacak tingkat keberhasilan dan kegagalan berdasarkan kombinasi OS, browser, dan penyedia kunci sandi
• Pemantauan sadar versi: deteksi saat versi OS atau browser baru menyebabkan lonjakan kesalahan atau fallback. Bedakan antara kesalahan yang diharapkan (pembatalan pengguna yang muncul sebagai NotAllowedError) dan kesalahan tak terduga (lonjakan AbortError karena bug konkurensi atau kesalahan kunci sandi Credential Manager baru setelah pembaruan Android)
• Peringatan (Alerting): dapatkan notifikasi sebelum pengguna Anda mulai mengajukan tiket dukungan
• Kemampuan respons cepat: kemampuan untuk mendorong perbaikan atau menonaktifkan kunci sandi untuk kombinasi perangkat yang terpengaruh dengan cepat

Ini adalah jenis infrastruktur analitik autentikasi yang sebagian besar tim tidak bangun sampai mereka mengalami insiden. Pada saat itu, kerusakan pada kepercayaan pengguna dan kredibilitas proyek internal telah terjadi.

7.3 Biaya Pemeliharaan Berkelanjutan#

Biaya sebenarnya dari penerapan kunci sandi bukan pada pembuatan awalnya. Melainkan pada pemeliharaan berkelanjutan:

• Memantau perubahan platform di iOS, Android, Windows, macOS, dan semua browser utama
• Menguji setiap pembaruan untuk regresi
• Memperbarui SDK frontend Anda saat API browser berubah
• Menjaga kompatibilitas dengan ekosistem penyedia kunci sandi yang terus berkembang
• Mendokumentasikan dan mengomunikasikan perubahan ke tim dukungan Anda

8. Kapan Anda (tidak) Harus Meluncurkan Kunci Sandi#

Mengingat masalah Hari ke-2 ini, berikut adalah penilaian jujur tentang kapan Anda harus dan tidak boleh meluncurkan kunci sandi.

8.1 Jangan luncurkan Kunci Sandi jika#

• Anda tidak memiliki strategi fallback dan pemulihan yang jelas
• Anda belum menguji di berbagai kombinasi perangkat yang benar-benar digunakan pengguna Anda
• Anda memiliki aplikasi native tetapi tidak ada rencana untuk QA spesifik platform yang berkelanjutan
• Anda tidak memiliki infrastruktur analitik untuk mengukur adopsi
• Anda tidak dapat memberikan komitmen sumber daya rekayasa untuk pemeliharaan berkelanjutan
• Anda menerapkan kunci sandi murni untuk persyaratan kepatuhan (compliance) tanpa perencanaan yang tepat

Mengerahkan segalanya karena alasan regulasi tanpa perencanaan yang tepat dapat meningkatkan biaya secara signifikan. Sistem kunci sandi yang diimplementasikan dengan buruk lebih buruk daripada tidak ada sistem kunci sandi sama sekali: hal itu mengikis kepercayaan pengguna, menghasilkan beban dukungan, dan memberi pemangku kepentingan internal alasan untuk membunuh proyek tersebut.

8.2 Luncurkan Kunci Sandi jika#

• Anda telah merencanakan kelima masalah Hari ke-2 yang dijelaskan di atas
• Anda memiliki kemampuan produk, rekayasa, keamanan, dan analitik untuk mendukung peluncuran berkelanjutan
• Anda telah menganggarkan untuk pemeliharaan berkelanjutan, bukan hanya pembuatan awal
• Anda memiliki strategi peluncuran bertahap dengan target adopsi yang jelas
• Anda bekerja dengan mitra seperti Corbado yang menangani kompleksitas operasional untuk Anda

8.3 Keputusan Bangun (Build) vs Beli (Buy)#

Masalah Hari ke-2 yang dijelaskan dalam artikel ini adalah alasan yang tepat mengapa banyak enterprise memilih untuk membeli daripada membangun infrastruktur kunci sandi mereka. Membangun server WebAuthn adalah bagian yang mudah. Mengoperasikan sistem kunci sandi tingkat produksi di ribuan kombinasi perangkat, dengan pemulihan yang tepat, pemantauan, dan analitik adopsi, adalah hal yang membedakan demo dari penerapan nyata.

9. Bagaimana Corbado Menyelesaikan Masalah Hari Ke-2 Kunci Sandi#

Corbado ada khusus karena masalah Hari ke-2 itu sulit. Platform kami menangani kompleksitas operasional sehingga Anda tidak perlu membangun dan memeliharanya sendiri.

9.1 Pemulihan dan Fallback#

Corbado menyediakan alur pemulihan out-of-the-box dengan tingkat keamanan adaptif. Mulai dari strategi kunci sandi yang disinkronkan, autentikasi lintas perangkat, hingga verifikasi identitas otomatis. Logika pemulihan dibangun di dalam dan diperbarui secara berkelanjutan.

9.2 Kompatibilitas Lintas Perangkat#

SDK frontend kami telah diuji sebelumnya pada ribuan kombinasi OS, browser, dan penyedia kunci sandi. Deteksi perangkat, penanganan UI bersyarat (conditional UI) dan perutean fallback terjadi secara otomatis. Ketika versi browser baru merusak sesuatu, kami memperbaikinya di SDK kami sebelum pengguna Anda menyadarinya.

9.3 Dukungan Aplikasi Native#

Corbado mendukung implementasi kunci sandi native dan WebView dengan SDK yang mengabstraksi perbedaan platform. Anda fokus pada UX aplikasi Anda sementara kami menangani teknis dasar kunci sandi di seluruh iOS dan Android.

9.4 Analitik Adopsi#

Dasbor analitik kami melacak setiap metrik yang penting: tingkat pembuatan kunci sandi, tingkat keberhasilan login, tingkat fallback, dan rincian tingkat perangkat. Anda mendapatkan wawasan yang dapat ditindaklanjuti untuk mendorong adopsi, bukan hanya data mentah.

9.5 Pemantauan Perubahan Platform#

Corbado terus memantau perubahan OS dan browser yang memengaruhi kunci sandi. SDK kami diperbarui secara proaktif. Penerapan kunci sandi Anda tetap stabil bahkan saat lanskap platform bergeser di bawahnya.

10. Kesimpulan#

Kunci sandi adalah standar emas autentikasi. Itu tidak dipertanyakan. Namun jalan dari "mendukung kunci sandi" ke "kunci sandi yang bekerja secara andal dalam skala besar" diaspal dengan masalah Hari ke-2 yang diremehkan oleh sebagian besar tim.

Kelima masalah yang telah kita bahas (pemulihan, edge case lintas perangkat, kompleksitas aplikasi native, adopsi, dan perubahan platform) tidak jarang terjadi. Itu adalah inti tantangan operasional dari setiap penerapan kunci sandi produksi. Mengabaikannya tidak membuatnya hilang. Itu hanya berarti pengguna Anda yang akan menemukannya lebih dulu.

Rekomendasi jujur saya: jika Anda tidak memiliki know-how dan sumber daya untuk mengimplementasikan kunci sandi dengan benar, jangan meluncurkannya. Baik Anda berinvestasi dalam kapabilitas (produk, rekayasa, keamanan, dan analitik) atau bekerja sama dengan mitra yang telah menyelesaikan masalah ini. Hasil terburuknya adalah penerapan kunci sandi setengah matang yang dibatalkan karena tidak ada yang merencanakan Hari ke-2.

Tentang Corbado

Corbado adalah Passkey Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

Pertanyaan yang Sering Diajukan (FAQ)#

Apa saja 5 masalah Hari ke-2 yang menyebabkan kegagalan proyek kunci sandi setelah peluncuran?#

Kelima masalah operasional tersebut adalah alur pemulihan dan fallback yang tidak aman, edge case ekosistem lintas perangkat, kompleksitas aplikasi native, adopsi pengguna yang rendah, dan regresi diam-diam dari pembaruan OS serta browser. Sebagian besar tim fokus pada integrasi WebAuthn awal dan meremehkan tantangan pasca-peluncuran ini, yang menyebabkan banyak proyek kunci sandi dibatalkan atau diam-diam ditinggalkan secara internal.

Bagaimana cara menangani autentikasi kunci sandi lintas perangkat untuk pengguna enterprise di Windows yang mendaftar di iPhone?#

Pengguna dapat mengautentikasi melalui kode QR dan alur lintas perangkat Bluetooth, tetapi ini memerlukan Bluetooth yang aktif di kedua perangkat dan dapat diblokir oleh kebijakan MDM perusahaan dan firewall. UX bervariasi secara signifikan antar browser dan pengguna sering kali tidak mengerti mengapa mereka memindai kode QR, membuat perutean fallback yang sadar perangkat dan komunikasi yang jelas menjadi sangat penting untuk penerapan enterprise.

Metrik adopsi kunci sandi apa yang harus saya targetkan dan pantau setelah peluncuran?#

Adopsi yang kuat berarti tingkat pembuatan kunci sandi di atas 60% dari pengguna yang memenuhi syarat dan tingkat login kunci sandi di atas 40% dari semua login. Tingkat pembuatan di bawah 10% dan login di bawah 5% setelah tiga bulan menandakan peluncuran yang gagal. Mengukur ini memerlukan pelacakan infrastruktur khusus untuk tingkat pembuatan, tingkat keberhasilan login, tingkat fallback, dan pengabaian yang dirinci berdasarkan kombinasi perangkat dan OS.

Haruskah saya membangun kunci sandi secara native di aplikasi seluler saya atau menggunakan WebView?#

Implementasi native memberikan UX terbaik di kelasnya tetapi memerlukan basis kode iOS dan Android yang terpisah dengan penanganan API spesifik platform dan pipeline QA independen. Pendekatan WebView berbagi logika web tetapi memperkenalkan ketidakkonsistenan dukungan kunci sandi tergantung pada jenis WebView. Di iOS saja, pilihan antara WKWebView, SFSafariViewController, dan ASWebAuthenticationSession masing-masing membawa karakteristik dukungan kunci sandi yang berbeda yang harus dievaluasi sebelum berkomitmen pada arsitektur.

Mengapa pemulihan akun kunci sandi lebih sulit daripada kelihatannya dan apa pendekatan yang tepat?#

Pemulihan yang disederhanakan seperti reset berbasis email memperkenalkan kembali saluran rentan phising, sementara pemulihan yang terlalu ketat seperti wajib menggunakan kunci keamanan perangkat keras menciptakan pengabaian. Pendekatan yang disarankan berlapis: kunci sandi yang disinkronkan sebagai strategi utama, autentikasi kode QR lintas perangkat sebagai lapisan kedua, verifikasi identitas otomatis dengan pemeriksaan keaktifan (liveness checks) sebagai lapisan ketiga, dan kredensial yang dapat diverifikasi secara digital sebagai lapisan keempat. Lapisan mana yang akan diimplementasikan bergantung pada model ancaman, basis pengguna, dan persyaratan peraturan Anda.