Passkeys & WebAuthn PRF untuk Enkripsi End-to-End (2025)

WebAuthn & Passkeys telah merevolusi autentikasi web, menawarkan login tanpa kata sandi yang tahan-phishing melalui kriptografi kunci-publik. Namun, kemampuannya lebih dari sekadar login. Salah satu fitur menarik adalah ekstensi WebAuthn Pseudo-Random Function (PRF). Ekstensi ini memungkinkan aplikasi web untuk menurunkan kunci rahasia langsung dari passkey pengguna atau kunci keamanan perangkat keras selama autentikasi. Ini membuka kemungkinan untuk data terenkripsi end-to-end atau mendekripsi brankas aman hanya dengan menggunakan passkey Anda, tanpa memerlukan kata sandi terpisah. Dalam artikel ini, kita ingin menjawab pertanyaan berikut:

• Kasus penggunaan Passkey PRF: Apa saja kasus penggunaan yang menarik untuk ekstensi WebAuthn PRF?
• Dukungan ekstensi PRF: Bagaimana dukungan nyata dari ekstensi WebAuthn PRF di berbagai sistem operasi dan browser saat ini?

Artikel ini menganalisis ekstensi WebAuthn PRF, menjelajahi spesifikasi teknis, kasus penggunaan, detail implementasi, pertimbangan keamanan, dan lanskap dukungan browser serta sistem operasi saat ini. Kita akan fokus pada perubahan dalam ekosistem 2025 dan memperluas dasar yang telah diletakkan oleh Matthew Miller dan Levi Schuck pada tahun 2023, yang artikel-artikel sebelumnya memberikan latar belakang teknis yang mendetail, contoh langsung, dan tes online (termasuk enkripsi).

Ekstensi WebAuthn PRF (PRF) secara resmi didefinisikan dalam spesifikasi WebAuthn Level 3. Tujuan utamanya adalah untuk memungkinkan Relying Party (aplikasi web Anda) untuk meminta evaluasi fungsi pseudo-random yang terkait dengan kredensial WebAuthn tertentu (passkey) selama proses autentikasi (navigator.credentials.get()).

Sebuah PRF mengambil kunci rahasia (yang disimpan dengan aman di dalam autentikator dan terikat pada kredensial) dan satu atau lebih nilai input (disediakan oleh Relying Party) untuk menghasilkan output deterministik yang terlihat acak secara kriptografis. Output ini, biasanya berupa string 32-byte, kemudian dapat digunakan oleh aplikasi sisi klien, terutama sebagai materi kunci simetris untuk enkripsi WebAuthn atau penurunan kunci.

Banyak autentikator, terutama kunci keamanan FIDO2, mengimplementasikan kapabilitas dasar yang didefinisikan dalam Client-to-Authenticator-Protocol (CTAP2) yang disebut ekstensi hmac-secret. Ekstensi CTAP2 ini menyediakan akses ke fungsi HMAC (Hash-based Message Authentication Code) yang didukung perangkat keras, yang berfungsi sebagai fungsi pseudo-random. Ekstensi WebAuthn PRF bertindak sebagai cara standar bagi aplikasi web untuk mengakses kapabilitas hmac-secret ini melalui API WebAuthn browser.

Untuk mencegah potensi konflik atau masalah keamanan di mana sebuah situs web mungkin menipu autentikator untuk menghasilkan HMAC yang ditujukan untuk tujuan non-web (seperti login OS lokal), spesifikasi WebAuthn mengamanatkan langkah penting: input yang disediakan oleh situs web (salt pertama dan kedua) pertama-tama di-hash dengan string konteks tertentu ("WebAuthn PRF" dan byte null) sebelum diteruskan ke fungsi hmac-secret yang mendasarinya. Ini secara efektif mempartisi ruang input PRF, memastikan bahwa output yang diturunkan dari web berbeda dari yang mungkin digunakan dalam konteks lain.

Kemampuan untuk menurunkan kunci yang terikat pada autentikator membuka beberapa kasus penggunaan yang menarik bagi para pengembang:

1. Enkripsi Sisi Klien / End-to-End (E2EE): Ini adalah motivator utama untuk ekstensi WebAuthn PRF. Aplikasi berbasis browser dapat menurunkan kunci enkripsi unik per kredensial selama login. Kunci ini kemudian dapat digunakan dengan WebCrypto API untuk mengenkripsi data pengguna yang disimpan secara lokal atau di server. Data tetap terenkripsi saat disimpan (at rest) dan hanya dapat didekripsi oleh pengguna setelah berhasil melakukan autentikasi dengan passkey tertentu, meningkatkan privasi dan keamanan data. Penyedia layanan dapat menyimpan data pengguna tanpa pernah memiliki akses ke plaintext. Ini sangat membantu untuk aplikasi di dunia tanpa kata sandi, karena tanpa ekstensi PRF, mereka perlu meminta rahasia tambahan dalam bentuk kata sandi, yang bertentangan dengan arsitektur tanpa kata sandi.

2. Dekripsi Brankas Tanpa Kata Sandi: Layanan seperti pengelola kata sandi (misalnya, Bitwarden, 1Password) atau aplikasi catatan aman (misalnya, Notesnook, Reflect) dapat menggunakan PRF untuk menggantikan kata sandi utama tradisional. Pengguna melakukan autentikasi dengan passkey mereka, ekstensi PRF menurunkan kunci dekripsi brankas, dan brankas pun terbuka - tidak perlu kata sandi utama. Bitwarden telah mengumumkan dukungan untuk ini. Selain itu, Dashlane baru-baru ini mengadopsi ekstensi WebAuthn PRF untuk memperkuat ketahanan terhadap phishing dan meningkatkan keamanan untuk mengakses brankas terenkripsi. Pengguna melakukan autentikasi menggunakan passkey mereka, memungkinkan PRF untuk menurunkan kunci dekripsi brankas dengan aman, sepenuhnya menghilangkan kebutuhan akan kata sandi utama.

3. Rotasi Kunci Aman: Ekstensi WebAuthn PRF memungkinkan penyediaan dua input "salt" (pertama dan kedua) selama autentikasi. Ini memfasilitasi skema rotasi kunci kriptografis. Sebuah server dapat meminta kunci "saat ini" menggunakan salt pertama dan kunci "berikutnya" menggunakan salt kedua. Seiring waktu, server dapat memperbarui salt mana yang sesuai dengan kunci saat ini, memungkinkan rotasi yang mulus tanpa mengganggu pengalaman pengguna. Ini sangat penting jika persyaratan peraturan atau kebijakan internal mengharuskan semua kunci dirotasi dalam jadwal tertentu dan meningkatkan keamanan.

4. Dompet Identitas & Sistem Non-Kustodial: PRF dapat menurunkan kunci untuk mengamankan data identitas di dalam dompet digital atau mengaktifkan sistem non-kustodial di mana kunci privat tidak pernah terekspos di sisi server.

Meskipun spesifikasinya telah didefinisikan, dukungan aktual dari browser dan platform adalah faktor krusial bagi para pengembang. Dukungan telah berkembang dan, hingga baru-baru ini, sebagian besar terbatas pada browser berbasis Chromium. Melacak dukungan bisa menjadi tantangan karena tidak ada entri khusus di CanIUse.com untuk ekstensi PRF itu sendiri (mencari "webauthn" menunjukkan dukungan API umum, tetapi bukan ekstensi spesifik). Informasi seringkali harus dikumpulkan dari catatan rilis browser, pelacak bug, dan halaman status. Keberhasilan menggunakan ekstensi WebAuthn PRF memerlukan upaya terkoordinasi di tiga lapisan tumpukan teknologi yang berbeda. Dukungan ekstensi PRF harus ada di setiap level agar fitur ini berfungsi:

1. Autentikator: Ini adalah perangkat keras (seperti kunci keamanan) atau komponen platform (seperti Windows Hello, iCloud Keychain dan modul perangkat keras yang sesuai, mis. TPM atau Secure Enclave) yang secara aman menyimpan kunci rahasia kredensial dan melakukan perhitungan fungsi pseudo-random yang sebenarnya (biasanya menggunakan kapabilitas CTAP2 hmac-secret). Jika autentikator tidak memiliki kapabilitas kriptografis fundamental ini, PRF tidak dapat bekerja.

2. Sistem Operasi (OS): OS bertindak sebagai jembatan antara browser dan autentikator. OS menyediakan driver dan API tingkat sistem yang diperlukan agar browser dapat menemukan, berkomunikasi dengan, dan meminta operasi dari autentikator (terutama autentikator platform dan yang terhubung melalui USB/NFC/Bluetooth). OS harus dapat mengenali dan mengekspos kapabilitas PRF (hmac-secret) autentikator ke browser. Jika OS tidak menyediakan jalur ini, browser tidak dapat mengakses fitur tersebut.

3. Browser: Sebagai antarmuka untuk aplikasi web, browser harus mengimplementasikan API JavaScript WebAuthn, secara spesifik mengenali ekstensi prf, menerjemahkan permintaan web menjadi perintah yang sesuai untuk OS/autentikator, menangani langkah keamanan krusial yaitu hashing input dengan string konteks, dan dengan benar mem-parsing serta mengembalikan hasilnya ke aplikasi.

Kegagalan atau kurangnya dukungan di salah satu dari tiga tingkatan ini—kapabilitas Autentikator, eksposur OS, atau implementasi Browser—akan mencegah ekstensi PRF berfungsi.

Diagram urutan ini menunjukkan versi sederhana tentang bagaimana para aktor ini bekerja sama untuk memfasilitasi dukungan PRF.

Alur kerja PRF yang berfungsi memerlukan setiap lapisan dalam rantai WebAuthn ↔ CTAP untuk bekerja sama.
Untuk kejelasan, kita memisahkan diskusi menjadi (1) perilaku browser + sistem operasi dan (2) perilaku autentikator.

Perjalanan menuju dukungan PRF yang luas menyoroti tantangan umum dengan ekstensi standar web: implementasi seringkali bertahap, dengan masalah spesifik platform yang perlu diselesaikan. Kami akan berusaha untuk menjaga tabel ini tetap diperbarui, tetapi perlu diingat bahwa karena ekstensi PRF adalah salah satu tambahan terbaru yang memerlukan seluruh rantai kompatibilitas untuk beradaptasi, penyesuaian yang berkelanjutan diharapkan terjadi.

Di bawah ini, kami memecah dukungan berdasarkan sistem operasi.

Dukungan untuk ekstensi WebAuthn PRF di Windows terbatas, karena autentikator platform asli (Windows Hello) saat ini tidak memiliki kapabilitas hmac-secret yang diperlukan. Oleh karena itu, fungsionalitas PRF bergantung pada kunci keamanan eksternal.

Dengan macOS 15, dukungan PRF telah hadir untuk autentikator platform. Baik Safari maupun Chrome mendukung PRF melalui iCloud Keychain. Dukungan Firefox untuk autentikator platform masih dalam proses. Kunci Keamanan hanya berfungsi dengan Chrome.

Status di iOS dan iPadOS mencerminkan macOS, dengan PRF berfungsi melalui iCloud Keychain. Namun, ada peringatan penting: bug di versi awal iOS 18 dapat menyebabkan kehilangan data, dan dukungan untuk kunci keamanan eksternal belum diimplementasikan.

Android saat ini menawarkan dukungan yang paling kuat dan luas untuk ekstensi WebAuthn PRF. Passkey yang disimpan di Google Password Manager menyertakan dukungan PRF secara default, dan berfungsi di sebagian besar browser utama, dengan pengecualian Firefox.

Dalam tabel di atas, kami telah menyertakan kombinasi paling penting untuk dukungan penyedia passkey pihak pertama. Namun, saat menggunakan pengelola kata sandi sebagai penyedia passkey pihak ketiga, kapabilitas spesifik mereka harus dipertimbangkan secara terpisah. Misalnya, 1Password mendukung PRF di versi Android-nya tetapi tidak di versi iOS-nya. Juga, Profil Chrome sebagai autentikator tidak mendukung prf. Untuk detail lebih lanjut tentang autentikator, lihat di bawah.

Meskipun WebAuthn menentukan apa yang dapat diminta oleh Relying Party, Client‑to‑Authenticator Protocol (CTAP) mendefinisikan bagaimana autentikator harus berperilaku. Dalam praktiknya, autentikator terbagi dalam empat kategori:

1. Tidak ada dukungan PRF: Autentikator platform lama (misalnya, Windows Hello), kunci keamanan lawas tanpa ekstensi hmac‑secret, dan penyedia pihak ketiga yang belum mengadopsi ekstensi prf.

2. PRF hanya jika flag PRF diatur saat pembuatan kredensial: Beberapa kunci keamanan CTAP 2.0/2.1 mengekspos hmac‑secret, tetapi akan menolak evaluasi PRF kecuali Relying Party memintanya saat kredensial pertama kali dibuat untuk menginisialisasi rahasia.

3. PRF tersedia saat autentikasi meskipun tidak diminta saat pembuatan: Token perangkat keras generasi baru serta iCloud dan Google Password Manager mengekspos fungsionalitas hmac‑secret tanpa syarat; kredensial yang dibuat tanpa flag tersebut masih berfungsi dengan PRF selama navigator.credentials.get().

4. Kepatuhan penuh CTAP 2.2 (PRF + nilai PRF pertama saat pembuatan): Autentikator platform yang menyinkronkan passkey—seperti iCloud Keychain dan Google Password Manager—dapat, jika diminta, mengembalikan output PRF pertama sudah selama navigator.credentials.create(), menyederhanakan alur pembentukan kunci.

Mengetahui kategori mana yang dimiliki oleh sebuah autentikator sangat penting saat Anda merancang logika pencadangan, migrasi, atau pembentukan kunci. Kami juga telah menyertakan tes untuk skenario ini di demo kami.

Anda dapat merasakan ekstensi WebAuthn PRF secara langsung menggunakan aplikasi demo PRF WebAuthn interaktif kami. Dalam demo ini, Anda akan dapat:

• Mendaftarkan passkey dengan PRF dan mengonfirmasi apakah autentikator Anda mendukung ekstensi yang kuat ini.
• Melakukan autentikasi menggunakan passkey Anda dan melihat nilai kriptografis yang dihasilkan PRF beraksi.

Melihat nilai PRF sendiri menyoroti implikasi praktis dari penggunaan passkey untuk operasi berbasis kunci yang aman. Ini memungkinkan Anda untuk secara langsung memverifikasi kompatibilitas autentikator untuk ekstensi PRF dan mengamati bagaimana kunci yang diturunkan dari PRF dapat mendukung enkripsi end-to-end WebAuthn dan dekripsi brankas aman tanpa kata sandi.

Luangkan waktu sejenak untuk mencoba demo ini; memahami kapabilitas PRF di lingkungan spesifik Anda membantu Anda merencanakan pengalaman tanpa kata sandi yang aman dan disesuaikan untuk pengguna Anda dengan lebih baik.

Siap menguji kekuatan PRF? Klik gambar di atas atau ikuti tautan ini untuk memulai eksplorasi langsung Anda.

Ekstensi WebAuthn PRF bukanlah satu-satunya ekstensi WebAuthn yang terkait dengan penyimpanan atau penurunan data. Bagaimana perbandingan passkey PRF?

• PRF vs. credBlob / largeBlob:

  • credBlob: Memungkinkan penyimpanan blob statis kecil (32 byte) bersama kredensial, mungkin pada saat pembuatan. Ini tidak dirancang terutama untuk rahasia, dan dukungannya terbatas, terutama untuk kredensial yang tidak dapat ditemukan.

  • largeBlob: Memungkinkan penyimpanan lebih banyak data (~1KB) dengan kredensial yang dapat ditemukan, seringkali ditujukan untuk data tambahan seperti sertifikat. Dukungannya juga terbatas (didukung oleh iCloud Keychain sejak iOS 17, tetapi tidak oleh GPM). Pengembang Chrome secara eksplisit lebih memilih untuk fokus pada PRF daripada largeBlob untuk sebagian besar kasus penggunaan, meskipun pengembangan mungkin terjadi di masa depan.

  • PRF: Sebaliknya, PRF dirancang khusus untuk menurunkan kunci rahasia sesuai permintaan selama autentikasi menggunakan rahasia yang terikat pada perangkat keras, daripada menyimpan blob statis. Ini umumnya dianggap sebagai mekanisme standar yang paling tepat dan aman untuk menurunkan kunci enkripsi yang terikat pada passkey. Evolusi dari diskusi tentang blob untuk rahasia ke standardisasi dan fokus implementasi pada PRF menunjukkan konvergensi pada PRF sebagai solusi khusus untuk kasus penggunaan ini.

• PRF vs. Kunci Turunan Kata Sandi (misalnya, PBKDF2): Secara tradisional, kunci enkripsi sisi klien diturunkan dari kata sandi pengguna. PRF menawarkan keuntungan signifikan:

  • Sumber yang Lebih Kuat: Kunci diturunkan dari materi kriptografis yang kuat di dalam autentikator, bukan dari kata sandi yang mungkin lemah atau digunakan kembali.

  • Tahan Phishing: Penurunan kunci terikat pada alur autentikasi WebAuthn yang tahan-phishing.

  • Tanpa Kata Sandi: Memungkinkan kasus penggunaan seperti dekripsi brankas tanpa memerlukan kata sandi sama sekali.

• PRF vs. Data WebAuthn Lainnya: Mencoba menurunkan kunci dari bagian lain dari respons WebAuthn (seperti tanda tangan, authenticatorData, atau kunci publik) pada dasarnya tidak aman dan salah. Komponen-komponen ini bersifat publik, bukan rahasia, atau dirancang untuk verifikasi, bukan penurunan kunci.

Untuk menurunkan materi kunci kriptografis yang aman dan terkait langsung dengan kredensial WebAuthn atau passkey, ekstensi WebAuthn PRF adalah pendekatan standar yang dibuat khusus dan direkomendasikan.

Saat mengintegrasikan ekstensi PRF ke dalam aplikasi Anda, pertimbangkan panduan praktis berikut:

Rekomendasi berikut membantu pengembang menavigasi keadaan dukungan ekstensi PRF saat ini secara efektif dan merencanakan pengembangan di masa depan:

• Perlakukan PRF secara Oportunistik:
  Dukungan untuk ekstensi WebAuthn PRF saat ini sangat bervariasi di berbagai browser, sistem operasi, dan autentikator. Oleh karena itu, perlakukan integrasi PRF sebagai peningkatan daripada ketergantungan inti.

• Hindari Ketergantungan Kritis pada PRF:
  Hindari menjadikan PRF penting untuk fungsionalitas yang krusial. Dukungan saat ini, terutama pada platform seperti Safari di macOS dan iOS, masih tidak konsisten dan tidak lengkap.

• Bersiap untuk Skenario Kehilangan Passkey:
  Ingatlah bahwa data yang dienkripsi dengan kunci turunan PRF terikat secara eksklusif pada passkey tertentu. Kehilangan passkey akan membuat data terenkripsi tidak dapat diakses secara permanen. Selalu implementasikan mekanisme pencadangan dan pemulihan yang kuat.

• Antisipasi Dukungan yang Lebih Luas pada Tahun 2026:
  Dukungan ekstensi PRF berkembang pesat. Pada tahun 2026, antisipasi ketersediaan yang konsisten di seluruh browser utama, sistem operasi, dan autentikator, terutama dengan penyedia passkey pihak pertama.

• Pantau Ekosistem Windows:
  Dukungan autentikator platform melalui Windows Hello saat ini tidak ada. Integrasi PRF penuh di lingkungan Windows sangat bergantung pada strategi adopsi Microsoft, jadi terus pantau ekosistem ini dengan cermat.

Mengikuti panduan ini memastikan pengembang dapat menggabungkan PRF dengan lancar sambil menjaga kompatibilitas dan keamanan selama fase adopsinya.

Memahami bagaimana PRF selaras dengan strategi passkey Anda secara keseluruhan membantu Anda memaksimalkan manfaatnya tanpa komplikasi yang tidak perlu:

• Integrasi Fleksibel:
  Tidak perlu memutuskan apakah akan memanfaatkan PRF pada saat pembuatan passkey. Passkey yang ada nantinya dapat diintegrasikan dengan mulus dengan kasus penggunaan PRF tanpa overhead manajemen kredensial tambahan.

• Memasang PRF pada Sistem Lama:
  Karena PRF beroperasi selama fase autentikasi (navigator.credentials.get()), passkey yang dibuat sebelumnya dapat mendukung alur kerja berbasis PRF di kemudian hari. Ini memungkinkan aplikasi Anda untuk meningkatkan keamanan secara bertahap tanpa mengganggu metode autentikasi yang sudah ada. Pendekatan ini berfungsi dengan iCloud Keychain dan Google Password Manager (GPM) serta kunci keamanan yang lebih baru. Untuk kunci keamanan yang lebih lama, hmac-secret mungkin hanya akan dibuat jika diminta saat pembuatan kredensial.

• Pertimbangan Kompleksitas Passkey:
  Kompleksitas yang melekat pada manajemen passkey—seperti sinkronisasi kredensial, autentikasi lintas perangkat, dan proses pemulihan—berlaku sama saat menggunakan PRF. Pastikan implementasi PRF Anda selaras secara kohesif dengan strategi autentikasi passkey Anda secara keseluruhan, menjaga pengalaman pengguna yang efisien dan kontrol keamanan yang kuat.

Mempertimbangkan PRF sebagai bagian dari strategi passkey holistik memungkinkan transisi yang lebih mulus ke praktik autentikasi yang lebih aman dan ramah pengguna.

Bagi penyedia layanan perusahaan yang menangani data pengguna sensitif, kemampuan untuk memanfaatkan WebAuthn PRF bersama passkey membuka kemungkinan untuk meningkatkan keamanan dan pengalaman pengguna, terutama dalam skenario yang memerlukan enkripsi sisi klien untuk Informasi Pengenal Pribadi (PII) atau mengamankan aplikasi yang memerlukan Enkripsi End-2-End. Meskipun Corbado Connect terutama dirancang untuk integrasi passkey perusahaan yang mulus, ia juga dapat memfasilitasi implementasi ekstensi passkey seperti SPC atau PRF.

Berikut cara Corbado dapat membantu organisasi yang ingin mengintegrasikan PRF:

• Memfasilitasi PRF untuk Penyimpanan Terenkripsi: Dalam lingkungan perusahaan, terkadang ada persyaratan untuk menyimpan informasi sensitif dengan aman, bahkan mungkin langsung di sisi klien untuk meminimalkan paparan PII di sisi server. Corbado Connect dapat dikonfigurasi untuk meminta nilai PRF selama alur autentikasi passkey (navigator.credentials.get()), memungkinkan aplikasi untuk menurunkan kunci kriptografis yang diperlukan.
• Pola Penyimpanan Fleksibel: Data yang dienkripsi menggunakan kunci turunan PRF dapat disimpan dengan berbagai cara tergantung pada persyaratan keamanan dan arsitektur:
  • Sisi Klien: Disimpan langsung di browser menggunakan mekanisme seperti localStorage atau Cookie yang aman. Data plaintext hanya ada secara sementara di klien selama dekripsi.
  • Backend Corbado (E2EE): Meskipun Corbado umumnya menghindari penyimpanan PII pelanggan, mekanisme PRF secara teknis memungkinkan penyimpanan data yang dienkripsi di sisi klien di server Corbado. Corbado tidak akan memiliki kunci untuk mendekripsi data ini; dekripsi akan tetap terjadi di sisi klien setelah autentikasi pengguna berhasil.
  • Backend Klien: Data terenkripsi juga dapat dikirim dan disimpan di sistem backend perusahaan sendiri, sambil tetap mendapat manfaat dari enkripsi sisi klien.
• Alur Penurunan Kunci yang Aman: Komponen Corbado Connect mengelola interaksi dengan API WebAuthn. Saat PRF diminta:
  1. Output PRF khusus pengguna dihasilkan oleh autentikator, terikat pada passkey individu.
  2. Output ini dikembalikan dengan aman ke aplikasi sisi klien.
  3. Aplikasi kemudian harus menggunakan Fungsi Penurunan Kunci (KDF) melalui WebCrypto API (misalnya, HKDF) untuk menurunkan kunci enkripsi simetris yang kuat dari output PRF.
  4. Kunci simetris ini digunakan dengan WebCrypto (misalnya, AES-GCM) untuk mengenkripsi atau mendekripsi informasi target (seperti PII).
• Dekripsi Mulus pada Login Berikutnya: Saat pengguna melakukan autentikasi lagi menggunakan passkey yang sama, Corbado Connect akan memulai permintaan PRF yang sama. Ini menghasilkan output PRF yang identik, memungkinkan aplikasi untuk menurunkan kembali kunci simetris yang sama dan mendekripsi informasi yang disimpan sebelumnya di sisi klien.
• Intelijen Adopsi PRF: Mengimplementasikan PRF memerlukan pengetahuan apakah lingkungan pengguna (OS, browser, autentikator) mendukungnya. Corbado Connect mengumpulkan sinyal tentang perangkat dan kapabilitas pengguna selama autentikasi. Intelijen ini dapat digunakan untuk:
  • Menentukan kesiapan PRF di seluruh basis pengguna sebelum mengaktifkan sepenuhnya fitur yang bergantung pada PRF.
  • Mengimplementasikan PRF secara oportunistik, menyediakannya sebagai peningkatan untuk pengguna yang didukung sambil mempertahankan mekanisme fallback (seperti meminta verifikasi ulang atau menggunakan metode alternatif) bagi mereka yang tidak memiliki dukungan.
• Menyederhanakan Ketersediaan PII: Dengan menggunakan PRF untuk mengenkripsi PII yang terverifikasi (misalnya, atribut identitas yang diperoleh melalui alur verifikasi) dan menyimpannya di sisi klien, aplikasi dapat membuat data ini segera tersedia setelah login passkey untuk interaksi atau transaksi berikutnya, secara signifikan mengurangi gesekan dibandingkan dengan verifikasi ulang atau alur berbasis aplikasi.
• Mengaktifkan Sistem E2EE Kustom: Meskipun Corbado Connect menawarkan komponen UI untuk alur standar, prinsip-prinsip dasarnya dapat memungkinkan pengembang untuk mengintegrasikan fungsionalitas PRF lebih dalam ke aplikasi sensitif. Ini memungkinkan pembangunan sistem terenkripsi end-to-end di mana aplikasi frontend secara langsung memanfaatkan kunci turunan PRF untuk operasi kriptografis kompleks pada data yang ada atau baru. Untuk saat ini, ini masih hanya akan mungkin dilakukan secara oportunistik dan mekanisme fallback perlu mengimplementasikan cara yang berbeda untuk menyimpan informasi tersebut.

Corbado bertujuan untuk menyederhanakan kompleksitas integrasi passkey dan PRF, memungkinkan perusahaan untuk memanfaatkan standar secara aman dan efektif, beradaptasi dengan kasus penggunaan spesifik seperti enkripsi PII sisi klien sambil menavigasi lanskap yang terus berkembang.

Ekstensi WebAuthn PRF menandai langkah maju yang penting dalam mewujudkan aplikasi yang benar-benar tanpa kata sandi dan terenkripsi end-to-end menjadi kenyataan praktis. Dengan memanfaatkan passkey untuk menurunkan kunci kriptografis secara aman, ini memberikan pengalaman pengguna yang mulus dan aman tanpa mengorbankan privasi.

Menjawab langsung pertanyaan yang diajukan di awal artikel ini:

• Kasus penggunaan PRF yang menarik: PRF memungkinkan kasus penggunaan yang menarik seperti penyimpanan data terenkripsi end-to-end, dekripsi brankas tanpa kata sandi untuk pengelola kata sandi, skema rotasi kunci kriptografis yang aman, dan dompet identitas yang aman atau sistem non-kustodial yang melindungi privasi pengguna dengan memastikan kunci privat tidak pernah meninggalkan perangkat klien.

• Keadaan dukungan PRF saat ini (Juni 2025): Dukungan masih terfragmentasi dan terus berkembang. Meskipun Android memiliki dukungan yang kuat di seluruh browser dan autentikator, platform seperti macOS dan terutama iOS masih goyah, khususnya sebagai sumber CDA dengan bug yang parah. Dukungan Windows terbatas terutama pada kunci keamanan eksternal, dengan dukungan platform asli melalui Windows Hello yang secara mencolok tidak ada.

Pengembang yang mempertimbangkan ekstensi PRF harus mengantisipasi perbaikan yang cepat, namun tetap melanjutkan dengan hati-hati, membangun aplikasi yang tangguh yang dapat menangani keterbatasan saat ini dengan baik. Seiring dengan munculnya adopsi yang lebih luas di platform utama dan ekosistem autentikator, masa depan untuk enkripsi tanpa kata sandi yang didukung PRF tampak cerah, menjanjikan peningkatan privasi dan kegunaan dalam autentikasi web.