Perintah dan konteks yang sesuai
SaaS ini telah mendukung kata sandi dan sedang menambahkan passkey. Pengguna dapat masuk dari ponsel, laptop, atau kunci keamanan perangkat keras; beberapa kredensial dapat disinkronkan melalui platform, sementara tindakan enterprise berisiko tinggi memerlukan verifikasi pengguna yang lebih kuat. Rancang registrasi, autentikasi, pemulihan, migrasi, dan observabilitas.
Cakupannya adalah WebAuthn dan batas verifikasi server. Passkey tidak secara otomatis menyelesaikan manajemen sesi, pemulihan akun, pencabutan perangkat, atau otorisasi bisnis.
Apa yang dievaluasi pewawancara
Pewawancara memeriksa apakah Anda memahami bahwa browser dan autentikator memegang kunci privat sementara server menyimpan kunci publik; setiap seremoni menggunakan challenge acak sekali pakai; dan pemverifikasi memeriksa challenge, RP ID, origin, tanda tangan, serta flag kehadiran pengguna atau verifikasi pengguna yang diperlukan.
Jawaban yang kuat juga memisahkan antara "tahan phishing" dan "tidak pernah hilang." Kredensial yang dapat disinkronkan meningkatkan ketersediaan tetapi mungkin tidak memenuhi persyaratan non-ekspor yang paling ketat. Jika pemulihan melewati bukti yang setara, seluruh desain hanya sekuat jalur terlemahnya.
Klarifikasi yang perlu ditanyakan terlebih dahulu
- Tindakan mana yang hanya memerlukan proses masuk, dan mana yang memerlukan UV atau kredensial yang terikat perangkat?
- Apakah RP ID mencakup beberapa subdomain, dan apakah WebAuthn akan berjalan dalam iframe lintas-origin?
- Bisakah pihak enterprise melarang kredensial yang dapat disinkronkan atau mewajibkan kunci perangkat keras?
- Faktor yang ada mana yang tetap dipertahankan untuk pemulihan, dan bisakah operator meninjaunya?
- Bagaimana lini masa migrasi dan pencabutan untuk kata sandi, TOTP, dan passkey?
Kerangka jawaban 30 detik
"Server membuat challenge sekali pakai untuk setiap registrasi atau autentikasi dan mengikatnya ke sesi. Setelah seremoni, server memverifikasi RP ID, origin, challenge, tanda tangan, dan flag UP/UV yang diperlukan. Registrasi menyimpan kunci publik, ID kredensial, penghitung, dan metadata kebijakan, bukan kunci privat. Saya akan membagi tingkatan kredensial yang dapat disinkronkan berdasarkan risiko dan mewajibkan UV atau pengikatan perangkat untuk tindakan sensitif. Pemulihan menggunakan faktor kuat yang ada, alur sekali pakai berdurasi singkat, dan tinjauan risiko; SMS bukan pintu belakang tanpa syarat."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan data registrasi dan autentikasi
Sebelum registrasi, server membuat challenge sekali pakai, berdurasi singkat, dan tidak dapat ditebak, lalu menyimpannya dalam sesi atau penyimpanan sekali pakai. Klien memanggil navigator.credentials.create(); autentikator membuat pasangan kunci dan mengembalikan kredensial kunci publik.
Simpan ID kredensial, kunci publik, akun, RP ID, penghitung tanda tangan, kelayakan pencadangan, dan status pencadangan sesuai kebutuhan. Kunci privat tetap berada di dalam autentikator atau pengelola kredensial platform.
Langkah 2: Lakukan pemeriksaan autentikasi yang ketat
Untuk masuk, server membuat challenge baru dan publicKeyCredentialRequestOptions; klien memanggil navigator.credentials.get(). Verifikasi:
const valid = await verifyAuthenticationResponse({
response,
expectedChallenge: session.challenge,
expectedOrigin: "https://app.example.com",
expectedRPID: "app.example.com",
requireUserVerification: true
});Gunakan (hanguskan) challenge segera setelah verifikasi berhasil. Tolak respons yang diputar ulang (replayed), kedaluwarsa, atau lintas-sesi, lalu verifikasi tanda tangan dengan kunci publik yang disimpan. Tangani juga pembatalan, browser yang tidak didukung, dan autentikator yang tidak tersedia untuk sementara.
Langkah 3: Pahami RP ID, origin, dan risiko lintas-origin
RP ID mengidentifikasi pihak yang mengandalkan (relying party) untuk suatu kredensial; kredensial tidak dapat mengautentikasi ke RP ID yang berbeda. Server juga harus memeriksa origin pemanggil daripada hanya membandingkan domain yang dapat didaftarkan. Iframe lintas-origin atau Related Origin Request memerlukan tinjauan eksplisit mengenai apakah pengguna mengetahui siapa yang meminta seremoni dan uji kompatibilitas terpisah.
Logo perusahaan bukanlah bukti origin. Origin, RP ID, challenge, dan tanda tangan harus diverifikasi bersama di seluruh konteks browser/autentikator dan server.
Langkah 4: Analisis UP, UV, dan status sinkronisasi berdasarkan risiko
UP berarti pengguna berinteraksi dengan autentikator; UV berarti autentikator memverifikasi pengguna secara lokal. Masuk biasa dapat memilih kebijakan berdasarkan risiko, sedangkan transfer, ekspor kunci, dan tindakan administrator harus mewajibkan UV dan meminta server memeriksa flag yang dikembalikan.
Kredensial yang dapat disinkronkan meningkatkan ketersediaan lintas perangkat, tetapi NIST mencatat bahwa sinkronisasi melibatkan eksporabilitas kunci. Apakah hal itu memenuhi tingkat kepastian tergantung pada kebijakan penerapan. Catat kelayakan dan status pencadangan; jangan menyebut "dapat disinkronkan" sebagai "sudah disinkronkan" atau "terikat perangkat."
Langkah 5: Rancang pemulihan, migrasi, dan pencabutan
Saat pengguna kehilangan perangkat, utamakan passkey terdaftar lainnya, kunci pemulihan enterprise, atau alur identitas kuat yang ditinjau. Token pemulihan harus berdurasi singkat, sekali pakai, terikat sesi, dan dapat dicabut. Setelah pemulihan, beri tahu pengguna, rotasi sesi, dan izinkan pengguna meninjau serta menghapus kredensial lama.
Selama migrasi kata sandi, pertahankan masa transisi yang terkontrol dan kurangi ketergantungan pada kata sandi setelah passkey dibuat; jangan menghapus setiap faktor lama secara diam-diam dalam permintaan yang sama. Setiap kredensial memerlukan status pencabutan independen, sementara penghitung yang anomali, perangkat berisiko, dan peristiwa pemulihan dicatat ke dalam aliran audit.
Contoh jawaban berkualitas tinggi
"Saya akan mulai dengan menyusun tingkatan tujuan keamanan. Server membuat challenge sekali pakai untuk setiap registrasi dan autentikasi serta menyimpannya dalam sesi berdurasi singkat. Server memverifikasi challenge, RP ID, origin, tanda tangan, dan flag UP/UV yang diperlukan oleh tindakan tersebut, lalu menghanguskan challenge. Basis data menyimpan kunci publik, ID kredensial, penghitung, akun, dan status pencadangan; kunci privat tidak pernah keluar dari autentikator.
Saya tidak akan mengaktifkan penggunaan iframe lintas-origin secara default. Jika diperlukan, saya akan memasukkan origin pemanggil, origin tingkat atas, dan RP ID ke dalam matriks pengujian. Masuk biasa dapat menerima kredensial tersinkronisasi yang sesuai dengan kebijakan, sementara tindakan sensitif memerlukan UV atau pengikatan perangkat. Pemulihan mengutamakan passkey kuat lainnya atau kunci pemulihan enterprise, dengan masa kedaluwarsa sekali pakai, kontrol risiko, dan notifikasi. SMS dapat menjadi fallback yang diterima secara eksplisit, bukan jalan pintas permanen untuk melewati autentikasi kuat. Telemetri produksi memantau replay challenge, ketidakcocokan origin, ketiadaan UV, keberhasilan pemulihan, dan pencabutan anomali."
Kesalahan umum
- Hanya memverifikasi tanda tangan → tanda tangan yang valid tidak membuktikan challenge, RP ID, atau origin yang benar → periksa setiap bidang dan hanguskan challenge.
- Memperlakukan UP sebagai UV → menyentuh autentikator bukanlah verifikasi pengguna lokal → wajibkan dan periksa UV untuk tindakan berisiko tinggi.
- Menyebut passkey yang dapat disinkronkan sebagai terikat perangkat → kelayakan sinkronisasi dan sinkronisasi aktual adalah fakta yang berbeda → catat flag pencadangan dan putuskan berdasarkan tingkat kepastian.
- Segera memulihkan dengan tautan SMS → jalur terlemah dapat mengambil alih akun → gunakan faktor kuat yang ada, token berdurasi singkat, tinjauan risiko, dan notifikasi.
- Hanya memeriksa domain yang dapat didaftarkan → suatu origin mencakup skema, host, dan port → bandingkan origin lengkap yang telah dinormalisasi.
- Menggunakan kembali challenge → asersi yang dicegat dapat diputar ulang → buat challenge acak, berdurasi singkat, sekali pakai, dan terikat sesi.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa passkey tahan terhadap phishing?
Autentikator memilih kredensial berdasarkan origin dan RP ID serta menandatangani challenge server dengan konteksnya. Situs phishing tidak dapat memperoleh bukti yang valid untuk layanan nyata dari autentikator. Server tetap harus memverifikasi origin, RP ID, dan challenge.
Pertanyaan lanjutan 2: Mengapa tidak menyimpan challenge hanya di klien?
Server harus mengetahui nilai acak yang dikeluarkannya untuk menghubungkan respons dengan niat login saat ini dan menolak replay. Nilai yang dibuat klien atau disimpan secara terpisah tidak membuktikan bahwa server yang memulai seremoni ini.
Pertanyaan lanjutan 3: Apakah kredensial yang dapat disinkronkan pada dasarnya tidak aman?
Hindari klaim biner. Sinkronisasi meningkatkan pemulihan dan kegunaan lintas perangkat, sementara eksporabilitas, kebijakan penyedia, dan persyaratan kepastian organisasi berbeda-beda. Server harus memeriksa flag pencadangan berdasarkan tingkat risiko dan mewajibkan faktor yang lebih kuat untuk tindakan sensitif.
Pertanyaan lanjutan 4: Bagaimana jika pengguna kehilangan semua perangkat?
Perlakukan pemulihan sebagai autentikasi berisiko tinggi: gunakan kunci pemulihan enterprise, faktor kuat lain yang ditinjau, atau tinjauan operator, dengan cakupan dan waktu terbatas, notifikasi, serta pencabutan kredensial yang tidak dikenal. Kenyamanan tidak boleh menurunkan tingkat kepastian login secara permanen.