---
url: 'https://www.corbado.com/id/blog/pemulihan-kunci-sandi-fallback'
title: 'Fallback & Pemulihan Kunci Sandi: Pendekatan Identifier-First'
description: 'Baca panduan manajer produk/developer kami tentang strategi fallback dan pemulihan untuk autentikasi berbasis kunci sandi, guna memastikan akses pengguna yang aman dan lancar.'
lang: 'id'
author: 'Vincent Delitz'
date: '2026-05-24T16:11:03.587Z'
lastModified: '2026-05-24T16:16:25.686Z'
keywords: 'pemulihan kunci sandi, fallback kunci sandi, passkey recovery, passkey fallback'
category: 'Passkeys Strategy'
---

# Fallback & Pemulihan Kunci Sandi: Pendekatan Identifier-First

## Key Facts

- Hampir 95% perangkat siap menggunakan kunci sandi, namun **strategi fallback dan pemulihan** yang efektif tetap penting untuk skenario di mana kunci sandi tidak dapat diakses atau hilang.
- **Pendekatan Identifier-First** secara otomatis menentukan ketersediaan kunci sandi setelah pengguna memasukkan pengidentifikasi mereka, mengeliminasi perlunya inisiatif dari pengguna dan menghindari status error jalan buntu yang membingungkan.
- **Kunci sandi yang disinkronkan** lebih jarang hilang dibandingkan nomor ponsel, membuat biaya pemulihan kunci sandi yang disinkronkan di cloud lebih rendah daripada pemulihan MFA berbasis SMS OTP tradisional selama periode 36 bulan.
- **Identifikasi selfie dengan liveness check (pemeriksaan keaktifan)** memungkinkan pemulihan MFA cerdas untuk industri yang diatur (regulated), memverifikasi kehadiran fisik dan mencocokkan pengguna dengan ID yang difoto untuk mencegah penipuan.

## 1. Pendahuluan

Kunci sandi (passkey) telah berkembang menjadi alternatif nyata untuk metode autentikasi tradisional, dengan [hampir 95% perangkat siap menggunakan kunci sandi](https://state-of-passkeys.io/). Namun, bahkan sistem yang paling canggih sekalipun memerlukan strategi fallback dan pemulihan yang efektif untuk mengatasi skenario di mana kunci sandi tidak dapat diakses (Fallback) atau bahkan hilang (Pemulihan). Panduan ini bertujuan untuk mengeksplorasi berbagai skenario di mana fallback dan pemulihan diperlukan serta membahas seperti apa solusi yang mungkin dilakukan.

Ketika memikirkan metode fallback dan pemulihan, penting agar kekuatan metode tersebut setara dengan metode autentikasi utama. Panduan ini akan membedakan antara berbagai penggunaan kunci sandi, terutama berfokus pada konteks di mana kunci sandi digunakan sebagai MFA mandiri (self-contained), untuk menyesuaikan metode fallback dan pemulihan secara tepat.

**Pertanyaan Kunci:**

- **Skenario Fallback Apa Saja yang Ada?** Apa saja potensi skenario fallback yang dapat terjadi dengan sistem kunci sandi, dan bagaimana hal tersebut harus ditangani untuk menjaga keamanan?
- **Bagaimana Pemulihan Harus Ditangani?** Bergantung pada pola penggunaan kunci sandi, terutama di lingkungan yang menggunakan MFA, bagaimana seharusnya proses pemulihan dirancang untuk memastikannya tetap aman?

Melalui eksplorasi pertanyaan-pertanyaan ini, panduan ini akan memberi manajer produk dan developer wawasan yang diperlukan untuk merancang, mengimplementasikan, dan mengelola sistem kunci sandi secara efektif, memastikan bahwa keamanan tidak mengorbankan pengalaman pengguna (user experience).

## 2. Definisi: Pengidentifikasi, Tingkat Keamanan & Fallback & Pemulihan

Sebelum menyelami strategi fallback dan pemulihan, penting untuk membangun pemahaman yang jelas tentang beberapa istilah dasar yang akan kita gunakan.

### 2.1 Pengidentifikasi: Email, Nomor Telepon, dan Nama Pengguna

Di sebagian besar sistem bisnis dan konsumen, autentikasi mengandalkan tiga pengidentifikasi utama: **email**, **nomor telepon**, dan **nama pengguna (username)**.

Sebagian besar sistem menggunakan **email** sebagai pengidentifikasi utama, khususnya pada aplikasi berbasis web. Namun, platform mobile-first atau app-first sering kali lebih suka menggunakan **nomor telepon** sebagai pengidentifikasi karena kemudahan dalam mengisi otomatis OTP (One-Time Passcode) berbasis SMS, yang dapat dimasukkan secara otomatis. Dalam beberapa kasus, pengguna mungkin juga diminta untuk mengatur **nama pengguna** selain pengidentifikasi ini, terutama untuk platform yang membutuhkan nama tampilan yang unik. Ada juga tren yang berkembang, terutama di platform yang lebih besar, untuk mengizinkan penggunaan **email** dan **nomor telepon** demi fleksibilitas tambahan.

Selama pendaftaran awal, pengidentifikasi ini biasanya diverifikasi baik melalui tautan konfirmasi / OTP (untuk **email**) atau OTP (untuk **nomor telepon**), memastikan bahwa pengidentifikasi tersebut adalah milik orang yang tepat. Jika akses hilang, membuktikan kontrol atas **email** atau **nomor telepon** yang diverifikasi sebelumnya biasanya cukup untuk memulihkan akses akun. Karena pengidentifikasi ini adalah bentuk komunikasi paling andal dengan pengguna, **nomor telepon** sering dikumpulkan untuk tujuan MFA (Multi-Factor Authentication), dengan SMS sebagai faktor kedua yang umum digunakan.

**Nama pengguna** sering digunakan untuk memberikan lapisan identitas pengguna tambahan dalam sistem yang memerlukan pengidentifikasi yang menghadap publik, seperti media sosial, forum, atau platform profesional tertentu. Meskipun mereka tidak memiliki peran fungsional yang sama dalam autentikasi seperti **email** atau **nomor telepon**, nama pengguna memberikan pengguna identitas yang dapat dikenali dalam konteks publik atau peer-to-peer. Namun, hal ini memperkenalkan kompleksitas tambahan karena pengguna sering melupakannya, dan dalam kebanyakan kasus, pengidentifikasi lain diperlukan bersama dengan nama pengguna. Oleh karena itu, dalam artikel ini, kita tidak akan berfokus pada nama pengguna.

Opsi 2FA lainnya, seperti aplikasi autentikator (yang menghasilkan kode TOTP), tidak bergantung pada pengidentifikasi tetapi sering kali lebih rumit untuk diatur bagi rata-rata pengguna. **Kunci sandi** juga telah memperkenalkan kemungkinan untuk bekerja tanpa pengidentifikasi (autentikasi tanpa nama pengguna/usernameless), sebuah fitur yang semakin populer di dunia kripto. Namun, baik untuk solusi konsumen maupun bisnis, kebutuhan untuk berkomunikasi dengan pengguna (sering kali melalui **email**) untuk tujuan fallback atau pemulihan membuat sistem tanpa nama pengguna menjadi kurang praktis.

### 2.2 Tingkat Keamanan: Single-Factor Authentication (SFA) & Multi-Factor Authentication (MFA)

Sistem **Single-Factor Authentication (SFA)** adalah sistem yang mengandalkan satu bentuk autentikasi untuk memverifikasi identitas pengguna. Biasanya, faktor tunggal ini adalah kata sandi, tetapi juga bisa berupa login sosial, email OTP, atau metode apa pun yang hanya membutuhkan satu jenis bukti. Sebagian besar sistem di web saat ini adalah sistem SFA. Namun, ada trade-off yang terkenal dengan keamanan. Saat mengintegrasikan kunci sandi, ini biasanya berfungsi sebagai add-on atau pengganti kata sandi tradisional, yang meningkatkan kenyamanan sistem. Adalah hal yang umum bagi sistem tersebut untuk tetap mengizinkan opsi fallback seperti email OTP atau login sosial, yang meningkatkan pengalaman pengguna dengan mengurangi kata sandi tetapi tidak meningkatkan keamanan sistem melebihi SFA.

**Multi-Factor Authentication (MFA)** melibatkan dua atau lebih faktor independen untuk memverifikasi identitas pengguna; inilah yang membuatnya lebih aman daripada SFA. Faktor-faktor ini dapat mencakup sesuatu yang diketahui pengguna (kata sandi atau PIN), sesuatu yang dimiliki pengguna (token keamanan atau aplikasi ponsel), dan sesuatu pada diri pengguna (verifikasi biometrik seperti sidik jari atau pengenalan wajah). Sistem MFA dirancang untuk melindungi terhadap kerentanan spesifik yang tidak dapat dipertahankan oleh sistem SFA, seperti serangan phishing atau pelanggaran kata sandi. Saat menggunakan kunci sandi dalam sistem MFA, mereka umumnya dimanfaatkan sebagai opsi MFA yang mandiri (self-contained). Dalam kasus ini, sangat penting bahwa setiap metode fallback atau pemulihan mempertahankan tingkat keamanan yang sama dengan kunci sandi.

### 2.3 Fallback & Pemulihan

**Fallback** digunakan di semua sistem di mana beberapa metode autentikasi hidup berdampingan. Mereka digunakan saat metode utama tidak tersedia – sering kali pengguna memiliki pilihan di awal tentang cara mendaftar (misalnya, login sosial vs. kata sandi). Sebuah fallback bisa melibatkan strategi autentikasi alternatif seperti OTP melalui email, kata sandi, login sosial dengan email yang cocok, push aplikasi native, kode QR, atau kunci keamanan. Masing-masing metode fallback ini bervariasi dalam kualitas keamanannya, dan memilih opsi fallback yang tepat sangat penting dalam menyeimbangkan kenyamanan pengguna dengan persyaratan keamanan.

Di lingkungan yang memanfaatkan kunci sandi sebagai bagian dari sistem Multi-Factor Authentication (MFA), metode fallback ini harus dipertimbangkan dengan cermat untuk memastikan mereka memberikan keamanan multi-faktor yang sebanding dengan kunci sandi. Proses **Pemulihan** menjadi penting saat pengguna kehilangan akses ke **semua tindakan autentikasi yang ditetapkan** yang memenuhi standar keamanan yang dipersyaratkan (SFA atau MFA). Hal ini kurang kritis dalam sistem faktor tunggal, di mana beberapa opsi pemulihan mungkin tersedia, seperti menyetel ulang kata sandi melalui email OTP, yang secara efektif memvalidasi kontrol pengguna atas pengidentifikasi terkait. Namun, pemulihan sangat menantang dalam sistem 2FA/MFA karena sistem ini secara inheren mengandalkan beberapa faktor untuk verifikasi. Dalam skenario di mana pengguna beralih sistem operasi seluler – mis. dari iPhone ke ponsel Android – dan kehilangan kunci sandi yang terkait & nomor teleponnya – faktor yang tersisa (mis., hanya kata sandi) tidak dapat memenuhi persyaratan 2FA. Pemulihan dalam contoh ini mungkin mengharuskan pembuatan bukti identitas baru, yang dapat melibatkan permintaan dukungan manual atau solusi yang lebih inovatif yang akan kita bahas nanti.

## 3. Fallback Login Kunci Sandi: Login Kunci Sandi Manual vs. Login Kunci Sandi Otomatis

**Saat menerapkan solusi kunci sandi, salah satu keputusan pertama yang harus dibuat adalah pendekatan untuk login kunci sandi**. Tergantung pada kasus penggunaannya, login manual mungkin cukup untuk platform yang lebih kecil, tetapi untuk perusahaan berorientasi UX yang lebih besar, sangat disarankan menggunakan Pendekatan Identifier-First, yang menawarkan login kunci sandi setelah pengidentifikasi utama (kemungkinan besar email) dimasukkan.

### 3.1 Login Kunci Sandi Manual: Pendekatan Inisiatif Pengguna

![login kunci sandi manual](https://www.corbado.com/website-assets/manual_passkey_login_ca7554d1ba.jpg)

#### 3.1.1 Apa itu Pendekatan Inisiatif Pengguna?

Pada platform yang lebih kecil atau platform yang tidak berfokus pada rasio login kunci sandi yang tinggi, pendekatan inisiatif pengguna melibatkan tombol "Masuk dengan kunci sandi" yang terpisah. Dalam pendekatan ini, **tanggung jawab** untuk menggunakan kunci sandi sepenuhnya dibebankan kepada pengguna. Setelah menambahkan kunci sandi ke akun mereka, pengguna harus ingat untuk mengklik "Masuk dengan kunci sandi" agar dapat masuk menggunakannya.

![mygov passkeys manual](https://www.corbado.com/website-assets/mygov_passkeys_manual_f5311f61e4.png)

Tangkapan layar tersebut menunjukkan implementasi kunci sandi dari [https://my.gov.au](https://my.gov.au), yang menggunakan pendekatan login kunci sandi manual. Meskipun pendekatan ini lebih mudah diterapkan karena backend tidak perlu menentukan apakah login kunci sandi memungkinkan, ini biasanya mengarah pada tingkat login kunci sandi yang jauh lebih rendah. Hal ini karena sangat bergantung pada inisiatif pengguna, dan konsumen mungkin tidak ingat atau tidak yakin di platform atau penyimpanan cloud mana kunci sandi mereka berada. Pendekatan ini membuat pengguna berpikir. Mari kita lihat peluang fallback apa saja yang ada dengan pendekatan ini di bagian selanjutnya.

#### 3.1.2 Fallback

Fallback sangat penting dalam sistem apa pun yang memiliki kemungkinan kegagalan akses kunci sandi. Dalam pendekatan login kunci sandi manual, dialog dan fallback tidak dapat dikelola secara individual karena semua opsi login ditampilkan pada waktu yang sama dan kunci sandi dipilih atas kebijaksanaan pengguna. Hal ini menyebabkan beberapa tantangan:

- **Error yang Tidak Intuitif:** Pesan error yang dihadapi pengguna saat kunci sandi tidak tersedia atau diatur secara tidak benar sering kali tidak jelas dan dapat menyebabkan kebingungan. Pengguna mungkin tidak mengerti mengapa mereka tidak dapat menggunakan kunci sandi atau apa yang salah, yang mengarah pada rasa frustrasi.
- **Jalan Buntu (Dead Ends):** Pengguna mungkin mendapati diri mereka berada di jalan buntu di mana mereka tidak dapat melanjutkan. Jika kunci sandi hilang atau tidak dapat diakses, pengguna mungkin tidak diberi panduan yang jelas tentang cara melanjutkan atau memulihkan akses, yang menyebabkan mereka mengabaikan proses login.
- **Tidak Memandu:** Dalam situasi ini, sistem tidak dapat memberikan instruksi yang membantu untuk memandu pengguna menuju metode autentikasi alternatif. Pengguna dibiarkan mencari tahu sendiri cara menyelesaikan masalah, yang mengurangi pengalaman pengguna.

![mygov passkey errors](https://www.corbado.com/website-assets/mygov_passkey_errors_a31da4283e.png)

Contoh di atas menunjukkan, betapa membingungkannya pesan error di Windows 11, ketika kunci sandi tidak ditemukan pada platform authenticator. Sistem mungkin mengasumsikan bahwa kunci sandi berada pada kunci keamanan atau perangkat lain. Proses ini dapat membingungkan bagi pengguna yang tidak terbiasa dengan alur autentikasi seperti itu, terutama jika mereka belum pernah menggunakan kunci keamanan sebelumnya atau belum pernah membuat kunci sandi.

![mygov passkey not exists](https://www.corbado.com/website-assets/mygov_passkey_not_exists_be8a954d92.png)

**Jika tidak ada kunci sandi yang ditemukan pada platform authenticator, sistem operasi & browser berasumsi bahwa kunci sandi pasti ada di tempat lain, yang menyebabkan kebingungan lebih lanjut jika pengguna belum membuat kunci sandi.** Conditional UI dapat membantu dengan menampilkan kunci sandi yang ada, tetapi ini hanya membantu jika kunci sandi benar-benar ada. Untuk pengalaman kunci sandi terbaik, backend harus memutuskan apakah login kunci sandi perlu dipicu setelah pengguna memberikan pengidentifikasi utamanya.

### 3.2 Login Kunci Sandi Otomatis: Pendekatan Identifier-First

![login otomatis kunci sandi](https://www.corbado.com/website-assets/automatic_passkey_login_4786c4413f.jpg)

#### 3.2.1 Apa itu Pendekatan Identifier-First?

Dalam pendekatan identifier-first, pengguna diminta untuk memberikan pengidentifikasi utama mereka, seperti email atau nomor telepon, sebelum sistem menentukan apakah login dengan kunci sandi memungkinkan. **Setelah pengidentifikasi diverifikasi, sistem secara otomatis menyarankan metode login yang paling tepat, termasuk kunci sandi jika tersedia & dapat diakses**. Pendekatan ini lebih ramah pengguna karena menghilangkan keharusan pengguna untuk mengingat opsi "Masuk dengan kunci sandi" dan meningkatkan tingkat adopsi dengan menyederhanakan proses.

![google identifier first sign in](https://www.corbado.com/website-assets/google_identifier_first_sign_in_4d53b85a52.png)_Sign-In Google Identifier-First_

![google passkey sign in](https://www.corbado.com/website-assets/google_passkey_sign_in_df2e4978c5.png)_Sign-In Kunci Sandi Google_

**Tangkapan layar di atas menunjukkan perilaku login dari login Google untuk akun di mana kunci sandi dikaitkan di perangkat macOS.** Google juga mengikuti pendekatan Identifier-First dan menetapkan bahwa login kunci sandi kemungkinan besar akan dimungkinkan:

1. **Dukungan platform kunci sandi:** Platform yang mendasarinya mendukung platform authenticator sehingga login bisa dilakukan.
2. **Kunci sandi dapat diakses:** Kunci sandi kemungkinan besar akan dapat diakses pada klien ini (macOS) karena dibuat di sistem macOS.

Oleh karena itu, login kunci sandi dimulai secara otomatis, memandu pengguna ke pengalaman terbaik yang memungkinkan. Ini mengikuti strategi "jangan buat saya berpikir".

> Desain kunci sandi dan autentikasi yang baik tidak mengalihkan tanggung jawab kepada pengguna tetapi menyarankan strategi autentikasi yang optimal untuk akun tertentu tergantung pada lingkungan klien.

#### 3.2.2 Kurangnya Dukungan Platform Kunci Sandi atau Aksesibilitas Kunci Sandi

Sistem menentukan apakah login kunci sandi dimungkinkan. Jika:

- **Tidak ada kunci sandi:** Pengguna belum membuat kunci sandi untuk akunnya
- **Kunci sandi tidak dapat diakses:** Kunci sandi yang dibuat pengguna kemungkinan besar tidak tersedia di Klien ini (misalnya pengguna hanya memiliki Kunci Sandi MacOS dan sekarang masuk dari Windows).
- **Autentikasi kunci sandi tidak didukung:** Klien saat ini tidak mendukung platform authenticator dan juga sangat kecil kemungkinannya untuk mendukung Autentikasi Lintas Perangkat (Cross-Device-Authentication) melalui Kode QR

![google no conditional ui sign in](https://www.corbado.com/website-assets/google_no_conditional_ui_sign_in_7e1fa02c4d.png)

keputusannya adalah login kunci sandi yang berhasil tidak mungkin terjadi dan **karena itu opsi fallback akan disediakan secara otomatis tanpa memicu login kunci sandi**. Pendekatan ini jauh lebih ramah pengguna karena mengeliminasi keharusan bagi pengguna untuk mengingat memilih opsi "Masuk dengan kunci sandi", meningkatkan tingkat adopsi dengan menyederhanakan proses, dan menghindari skenario terburuk di mana jalan buntu yang membingungkan ditampilkan kepada pengguna.

Pada contoh di atas, login beralih kembali (fallback) ke kata sandi dan kemudian akan terus meminta faktor autentikasi lebih lanjut berdasarkan status dan keamanan akun, karena kliennya adalah perangkat Windows 11, yang tidak mungkin memiliki akses ke kunci sandi macOS. Bergantung pada persyaratan keamanan sistem autentikasi Anda, Anda memiliki kontrol penuh atas metode autentikasi mana yang akan dipicu dalam kasus tersebut (mis., opsi autentikasi non-kunci sandi terakhir yang berhasil).

#### 3.2.3 Pembatalan Proses (Ceremony) Kunci Sandi

Saat pengguna menjumpai layar autentikasi selama login web, mereka mungkin terkejut atau kewalahan, terutama jika ini adalah salah satu pertama kalinya mereka menggunakan autentikasi berbasis kunci sandi. Hal ini dapat menyebabkan pengguna membatalkan proses autentikasi, bukan karena kegagalan, tetapi semata-mata karena mereka tidak yakin tentang apa yang sedang terjadi. Sangat penting untuk merencanakan perilaku ini dan memperlakukan pembatalan pertama sebagai peristiwa normal daripada sebuah error:

![google passkey first abort](https://www.corbado.com/website-assets/google_passkey_first_abort_9024d11904.png)

Layar pembatalan (abort) pertama harus menjelaskan dengan jelas apa yang terjadi dengan cara yang tenang dan meyakinkan, merekomendasikan pengguna untuk mencoba kembali proses tersebut (lihat contoh Google di atas). Layar ini harus dirancang untuk meminimalkan kecemasan, memperlakukan pembatalan sebagai bagian biasa dan diharapkan dari pengalaman pengguna. Banyak pengguna mungkin membatalkan karena mereka tidak mengenali layar autentikasi atau tidak terbiasa dengan prosesnya. Oleh karena itu, coba lagi (retry) harus menjadi saran default.

Namun, jika **pembatalan kedua** terjadi, situasinya harus diperlakukan secara berbeda. Pembatalan kedua dapat mengindikasikan bahwa sesuatu benar-benar tidak beres - entah itu masalah dengan platform authenticator, pengguna tidak dapat menemukan kunci sandi yang sesuai, atau kegagalan teknis dalam proses (ceremony) WebAuthn. Pada titik ini, sistem harus menyajikan layar yang berbeda yang menjelaskan bahwa telah terjadi masalah dan menyarankan opsi fallback secara lebih jelas:

![google passkey second abort](https://www.corbado.com/website-assets/google_passkey_second_abort_b0487ba1bc.png)

**Layar pembatalan kedua harus mendorong pengguna untuk beralih ke metode autentikasi alternatif**. Ini harus memastikan pengguna masih dapat berhasil masuk tanpa menyebabkan rasa frustrasi lebih lanjut. Seperti yang dapat kita lihat di layar di atas, Google masih menyarankan "Coba lagi" tetapi pada saat yang sama menunjukkan kepada pengguna bahwa mungkin ada yang salah.

### 3.3 Perbandingan Pendekatan Implementasi Kunci Sandi

Tabel berikut membantu membandingkan pendekatan yang berbeda dengan merangkum karakteristik yang paling penting:

![perbandingan pendekatan implementasi kunci sandi](https://www.corbado.com/website-assets/passkey_falback_comparison_table_1f62928641.jpg)

Pendekatan do-it-yourself biasanya mengikuti **pendekatan Login Kunci Sandi Manual** dan mengandalkan Conditional UI serta pengguna untuk ikut serta (opt-in) menggunakan kunci sandi, yang menghasilkan rasio login kunci sandi yang sangat rendah dan pengguna yang frustrasi. **Pendekatan Identifier-First** membutuhkan pembangunan logika perangkat yang matang di atas Conditional UI, yang merupakan area di mana Corbado dapat membantu Anda. Membangun logika perangkat dan [passkey intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) Anda sendiri tidak disarankan, karena ruleset ini memerlukan penyesuaian terus-menerus terhadap perangkat baru, WebAuthn baru & fungsionalitas sinkronisasi cloud (mis. kunci sandi GPM).

## 4. Pemulihan Kunci Sandi

**Pemulihan kunci sandi adalah aspek krusial dalam menjaga keamanan dan pengalaman pengguna saat pengguna kehilangan akses ke kunci sandi mereka.** Ini sangat penting dalam sistem yang mengandalkan MFA. Dalam kasus MFA, proses pemulihan harus memastikan bahwa keamanan terjaga sekaligus memungkinkan pengguna untuk mendapatkan kembali akses ke akun mereka. Pendekatan pemulihan harus disesuaikan berdasarkan tingkat autentikasi yang digunakan dalam sistem.

### 4.1 Pemulihan Faktor Tunggal dan Pemulihan Multi-Faktor

Untuk menjaga keamanan di sistem SFA, pemulihan umumnya melibatkan pembuktian kontrol atas pengidentifikasi seperti alamat email atau nomor ponsel.

- **Email OTP:** OTP dikirim ke alamat email terdaftar pengguna. Setelah diverifikasi, ini memungkinkan pengguna untuk mendapatkan kembali akses dan membuat kunci sandi baru.
- **SMS OTP:** Mirip dengan pemulihan email, OTP dikirim ke nomor ponsel terdaftar. Pengguna dapat menggunakan OTP ini untuk mendapatkan kembali akses ke akun mereka.

Meskipun metode ini mudah, mereka mengandalkan informasi kontak pengguna yang mutakhir. Oleh karena itu, penting untuk meminta pengguna secara teratur memverifikasi email dan nomor telepon mereka selama login rutin.

Dalam sistem **Multi-Factor Authentication**, pemulihan menjadi lebih kompleks. Karena MFA mengandalkan beberapa faktor independen (misalnya, kunci sandi, login sosial, dan OTP), pengguna seharusnya tidak kehilangan akses hanya karena satu faktor (seperti kunci sandi) tidak tersedia.

- **Menggunakan faktor alternatif:** Jika kunci sandi hilang, pengguna dapat mengautentikasi menggunakan dua faktor lain, seperti kata sandi + SMS OTP atau aplikasi autentikator. Setelah mereka diautentikasi, mereka dapat membuat kunci sandi baru.
- **Menggunakan kunci sandi lain:** Jika pengguna memiliki perangkat lain dengan kunci sandi, mereka dapat menggunakannya untuk mendapatkan kembali akses dengan petunjuk yang sesuai (misalnya meminta penggunaan kunci sandi dari iPhone).
- **Membuat kunci sandi baru:** Setelah mengautentikasi dengan metode pemulihan, pengguna harus dipandu untuk membuat kunci sandi baru untuk memastikan setup MFA tetap utuh.

Untuk sistem SFA maupun MFA, kuncinya adalah memastikan bahwa proses pemulihan kuat dan aman sekaligus meminimalkan friksi bagi pengguna.

### 4.2 Pemulihan MFA Cerdas: Digitalisasi Biaya Pemulihan MFA

Dalam sistem yang menangani data pribadi yang sensitif, industri yang diatur, atau layanan [pemerintah](https://www.corbado.com/passkeys-for-public-sector), email OTP standar dan OTP nomor ponsel mungkin tidak selalu cukup atau tersedia untuk pemulihan. Dalam kasus tersebut, mekanisme **pemulihan MFA cerdas** menawarkan metode lanjutan untuk pemulihan akun yang mempertahankan standar keamanan tinggi sekaligus menawarkan pengalaman yang lancar kepada pengguna.

Salah satu metode yang paling efektif adalah **identifikasi selfie dengan liveness check (pemeriksaan keaktifan)**. Proses ini melibatkan pengguna untuk mengambil foto ID mereka. Selain itu, liveness check selfie memastikan bahwa selfie diambil secara real time, mengonfirmasi bahwa pengguna hadir secara fisik & cocok dengan ID yang difoto sehingga mencegah penipuan menggunakan gambar statis atau ID curian. Bergantung pada teknologi yang digunakan, liveness check dilakukan dengan merekam video pendek di mana jarak diubah ke kamera atau kepala diputar 180 derajat (misalnya Apple Face ID).

Metode ini sangat berguna saat metode pemulihan tradisional seperti email atau SMS OTP tidak tersedia atau kedaluwarsa. Sebagai contoh, berikut ini adalah contoh pengambilan selfie yang kemudian diikuti dengan liveness check dari onfido:

![liveness check onfido](https://www.corbado.com/website-assets/liveness_check_onfido_7109eb3d96.png)_Contoh: Identitas Selfie dengan liveness check dari onfido_

- **Sistem pemerintah, industri yang diatur, atau layanan komersial besar** memiliki data pribadi yang dapat digunakan untuk memverifikasi informasi yang tersedia di ID. Seandainya misal tanggal lahir tidak tersedia, informasi yang dikumpulkan melalui ID dapat digunakan sebagai faktor dalam proses pemulihan manual.

Selain itu, metode **pemulihan cerdas** lainnya dapat mencakup:

- **Pemulihan lintas perangkat (cross-device):** Jika pengguna memiliki perangkat kedua yang tepercaya, mereka dapat memulihkan akun mereka dengan memindai kode QR.
- **Lingkungan yang dikenal (Known environments):** Pengguna yang masih memiliki akses ke perangkat yang sama yang telah berhasil mereka gunakan sebelumnya, dapat memberikan faktor jaminan tambahan dengan menggunakan perangkat ini dan karenanya memberikan bukti bahwa mereka bertindak dari perangkat, penyedia, dan lokasi yang sama untuk membantu proses pemulihan manual. Pendekatan yang digunakan Google untuk [Pemulihan Akun Gmail](https://gmailaccountrecovery.blogspot.com/).
- **Digital Credentials API:** Dengan meningkatnya adopsi dompet ID (ID wallets), verifikasi langsung melalui API ini diharapkan memainkan peran yang terus berkembang dalam pemulihan akun yang aman dan ramah pengguna.

Metode pemulihan MFA cerdas bertujuan menawarkan cara yang aman dan intuitif kepada pengguna untuk mendapatkan kembali akses ke akun mereka, terutama saat berhadapan dengan informasi yang sangat sensitif atau diatur. Pendekatan ini memastikan bahwa bahkan jika metode tradisional seperti pemulihan email atau telepon tidak tersedia, pengguna masih dapat memulihkan akses mereka dengan aman dan efisien. Pemulihan cerdas membantu menekan biaya pemulihan MFA.

### 4.3 Frekuensi Pemulihan MFA: Nomor Telepon vs. Kunci Sandi

Penting untuk diingat bahwa karena kunci sandi disinkronkan di cloud, biaya pemulihan MFA jauh lebih rendah selama periode 36 bulan, karena mengubah nomor ponsel jauh lebih sering dilakukan daripada beralih dari Apple ke Android atau sebaliknya. Jika terjadi pergantian ponsel atau kontrak telepon, kunci sandi akan dipulihkan.

**Oleh karena itu, kehilangan akses ke kunci sandi yang disinkronkan akan lebih jarang terjadi daripada kehilangan akses ke nomor ponsel, yang menyebabkan sebagian besar masalah pemulihan pada sistem MFA tradisional yang berorientasi pada konsumen.**

Namun, dengan basis pengguna yang terus bertambah, kasus-kasus tersebut masih menyebabkan biaya dukungan manual yang signifikan dan harus ditangani dengan solusi digital, yang akan kita lihat di bagian selanjutnya.

## 5. Rekomendasi untuk Manajer Produk dan Developer

Saat mengintegrasikan kunci sandi ke dalam sistem autentikasi Anda, sangat penting untuk merencanakan opsi fallback dan strategi pemulihan secara hati-hati demi mempertahankan tingkat keamanan yang tinggi sekaligus memastikan pengalaman pengguna yang lancar. Untuk memaksimalkan rasio login kunci sandi, pertimbangkan rekomendasi berikut:

- **Pilih Pendekatan Identifier-First:** Pendekatan ini lebih ramah pengguna dan mengurangi hambatan (friksi) dalam proses login. Dengan meminta pengguna memasukkan pengidentifikasi utamanya terlebih dahulu (misalnya, email atau nomor telepon), sistem dapat secara otomatis menentukan apakah login kunci sandi memungkinkan. Hal ini memastikan pengalaman login yang mulus dan intuitif tanpa mengandalkan pengguna untuk memilih opsi kunci sandi secara manual.
- **Gunakan Layar Pembatalan yang Menjelaskan Demi Pengalaman Pengguna yang Lebih Baik:** Walaupun keamanan harus menjadi prioritas utama, merancang proses yang membantu pengguna mengadopsi kunci sandi sangatlah esensial. Pastikan bahwa pembatalan proses untuk pertama kalinya diperlakukan sebagai hal normal, dan berikan panduan yang jelas untuk mencoba lagi.
- **Jaga agar Opsi Fallback dan Pemulihan Tetap Aman:** Pastikan metode fallback (seperti email OTP dan/atau SMS OTP) sesuai dengan tingkat keamanan metode autentikasi utama. Misalnya, dalam sistem MFA yang menggunakan kunci sandi, fallback juga harus membutuhkan beberapa faktor untuk mempertahankan standar keamanan yang sama.
- **Otomatiskan Perintah Pemulihan Berkala:** Secara teratur minta pengguna untuk memverifikasi informasi kontak mereka (alamat email atau nomor telepon) selama login untuk memastikan opsi pemulihan tetap mutakhir ketika mereka menggunakan kunci sandi. Ini mengurangi kemungkinan pengguna terkunci dari akunnya karena metode pemulihan yang sudah usang.
- **Pertimbangkan Metode Pemulihan Cerdas untuk Keamanan Lebih Lanjut dan Mengurangi Biaya Pemulihan Dukungan:** Untuk industri yang diatur atau sistem yang memiliki akses ke data pribadi untuk membandingkannya dengan identifikasi online, pertimbangkan metode pemulihan lanjutan seperti identifikasi selfie dengan liveness check. Metode ini dapat memberikan lapisan keamanan tambahan sekaligus menjaga proses pemulihan tetap intuitif dan ramah pengguna bergantung pada persyaratan keamanan Anda.

Memaksimalkan rasio login kunci sandi bergantung pada seberapa baik Anda menerapkan elemen-elemen ini. Memastikan opsi fallback dan pemulihan berjalan mulus akan memberi pengguna keyakinan dalam menggunakan kunci sandi sebagai metode autentikasi utama mereka.

## 6. Apa yang Dapat Corbado Lakukan untuk Anda: Komponen UI & Passkey Intelligence

Corbado menyediakan semua yang diperlukan untuk menerapkan pendekatan identifier-first baik bagi proyek greenfield yang membutuhkan sistem autentikasi baru yang lengkap maupun bagi proyek yang sudah ada yang perlu menambahkan kunci sandi ke sistem autentikasi saat ini.

### 6.1 Komponen UI Untuk Berbagai Kasus Penggunaan

Kedua produk menawarkan komponen UI yang dapat disesuaikan dengan kebutuhan Anda:

1. **Corbado Complete: Mulai proyek Anda dengan autentikasi yang mengutamakan kunci sandi (passkey-first)**\
   Ini adalah sistem autentikasi lengkap kami, yang mencakup pendekatan identifier-first yang mulus untuk menyederhanakan proses login. Corbado Complete memungkinkan pengalaman yang aman dan ramah pengguna dengan menentukan secara otomatis apakah login kunci sandi dimungkinkan setelah pengguna memberikan pengidentifikasinya. Ini mengurangi friksi dan memastikan pengalaman login yang lancar, yang sangat krusial untuk memaksimalkan adopsi kunci sandi.
2. **Corbado Connect: Tambahkan kunci sandi tanpa migrasi ke aplikasi apa pun**\
   Untuk bisnis yang sudah memiliki proses autentikasi mapan dan ingin menambahkan kunci sandi sebagai penyempurnaan, Corbado Connect menawarkan solusi add-on untuk Strategi Faktor Tunggal dan Multi-Faktor. Pendekatan ini melengkapi infrastruktur Anda yang ada dengan mengintegrasikan kunci sandi sebagai opsi yang aman dan praktis, memungkinkan pengguna untuk mengautentikasi via kunci sandi tanpa perlu merombak sistem Anda saat ini. Misalnya, Corbado Connect dapat disematkan secara mulus ke dalam Amazon Cognito.

Kami secara ketat menyelaraskan metode kami dengan pemimpin industri seperti Google dan para pemain terkemuka lainnya di dunia big tech, khususnya yang dirancang untuk perusahaan yang berorientasi konsumen.

### 6.2 Passkey Intelligence Memungkinkan Pendekatan Identifier-First

Tujuan kami bukan sekadar memaksimalkan adopsi kunci sandi (yaitu pembuatan kunci sandi), melainkan juga untuk memastikan kunci sandi ini secara aktif digunakan guna mendorong tingkat login yang tinggi (dan karenanya meningkatkan keamanan serta menekan biaya SMS OTP). Komponen UI kami dibangun dengan mengutamakan pendekatan Identifier-First dan terhubung langsung ke [Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) kami, yang memutuskan ketersediaan & aksesibilitas kunci sandi berdasarkan lingkungan klien serta kunci sandi yang ada. Mereka mendukung seluruh fungsionalitas fallback dan pemulihan yang dibahas. Layar berikut menunjukkan logika pembatalan & coba lagi (abort & retry) kami:

![corbado passkey first abort](https://www.corbado.com/website-assets/corbado_passkey_first_abort_537bf2c410.png)_Pembatalan Kunci Sandi Pertama_

![corbado passkey second abort](https://www.corbado.com/website-assets/corbado_passkey_second_abort_a167225e5e.png)_Pembatalan Kunci Sandi Kedua_

Dengan berfokus pada adopsi dan penggunaan kunci sandi, kami membantu Anda mencapai keseimbangan antara keamanan dan pengalaman pengguna, memastikan pengguna terus berinteraksi dengan kunci sandi tanpa hambatan.

## 7. Kesimpulan

Dalam panduan ini, kita telah mengeksplorasi beragam strategi fallback dan pemulihan usai integrasi kunci sandi ke dalam sistem autentikasi. Pertanyaan kunci yang diajukan dalam pendahuluan telah dijawab secara menyeluruh:

- **Skenario fallback apa saja yang ada?** Beberapa skenario fallback dapat terjadi, seperti tidak adanya dukungan kunci sandi atau kunci sandi yang tidak dapat diakses di perangkat tertentu. Untuk menjaga keamanan serta memberikan UX yang lancar, opsi fallback seperti email atau SMS OTP perlu tersedia ketika login kunci sandi tidak dapat dilakukan.
- **Bagaimana pemulihan harus ditangani?** Proses pemulihan harus didesain agar sesuai dengan level keamanan dari sistem autentikasi. Di dalam sistem SFA, email atau SMS OTP bisa dibilang cukup, sementara dalam sistem MFA, faktor alternatif perlu dipakai untuk memperoleh kembali akses dan membikin kunci sandi baru. Dalam ranah yang diatur ketat atau lingkungan yang sensitif, ragam metode pemulihan cerdas seperti identifikasi swafoto dengan liveness check menyediakan keamanan ekstra.

Melalui penerapan best practices yang dijabarkan di panduan ini, para manajer produk serta developer dapat merancang sistem autentikasi berbasis kunci sandi yang mumpuni, yang dapat menyuguhkan pengalaman login yang mulus sekaligus aman kepada pengguna. Keamanan tidak harus mengorbankan pengalaman pengguna - keduanya dapat diraih dengan perencanaan dan desain yang cermat.

## Pertanyaan yang Sering Diajukan

### Bagaimana Pendekatan Identifier-First menangani login kunci sandi saat kunci sandi tidak dapat diakses di perangkat saat ini?

Ketika kunci sandi kemungkinan besar tidak dapat diakses (misalnya kunci sandi macOS yang diakses dari perangkat Windows), sistem secara otomatis melewati perintah (prompt) kunci sandi dan menyajikan opsi fallback seperti kata sandi atau OTP. Hal ini menghindari jalan buntu yang membingungkan dengan hanya memicu login kunci sandi saat tingkat keberhasilan dirasa tinggi, mengikuti strategi 'jangan buat saya berpikir'.

### Apa yang harus terjadi jika pengguna membatalkan proses autentikasi kunci sandi di tengah alur?

Pembatalan pertama harus diperlakukan sebagai peristiwa normal, dengan layar yang tenang yang mendorong pengguna untuk mencoba lagi, karena banyak pengguna membatalkan sekadar karena mereka tidak terbiasa dengan layar autentikasi. Jika pembatalan kedua terjadi, sistem harus memunculkan opsi autentikasi fallback, karena hal ini dapat menunjukkan masalah nyata dengan platform authenticator atau ketersediaan kunci sandi.

### Opsi pemulihan apa yang ada untuk sistem MFA saat pengguna kehilangan akses ke kunci sandinya?

Di dalam sistem MFA, pengguna dapat memulihkan akses dengan mengautentikasi menggunakan dua faktor alternatif seperti kata sandi ditambah SMS OTP, atau dengan menggunakan kunci sandi dari perangkat tepercaya lain, lalu membuat kunci sandi baru. Untuk industri yang diatur di mana metode pemulihan tradisional tidak tersedia, metode cerdas seperti identifikasi selfie dengan liveness check memberikan jalur pemulihan aman tambahan.

### Mengapa pendekatan tombol 'Masuk dengan kunci sandi' manual menghasilkan adopsi yang lebih rendah dibandingkan Pendekatan Identifier-First?

Pendekatan manual menempatkan tanggung jawab penuh pada pengguna untuk mengingat dan memilih opsi kunci sandi mereka sendiri, yang biasanya menghasilkan rasio login kunci sandi yang jauh lebih rendah. Pengguna mungkin juga menjumpai pesan error yang tidak jelas ketika kunci sandi tidak ditemukan di platform authenticator, yang berujung pada rasa frustrasi dan pengabaian upaya login.