Bagaimana Passkeys yang Terlalu Dihebohkan Membuat Security Key Menjadi Tidak Berguna

• Jika alur yang mendefinisikan dan mewajibkan Passkeys sebagai resident key makin meluas, security key seperti Yubikey, Feitian, dan Nitrokey akan cepat terbentur batas karena ruang penyimpanannya terbatas
• non-resident credential memiliki struktur di mana security key mendekripsi credential ID yang disediakan oleh Relying Party untuk memperoleh private key per RP, sehingga di dalam perangkat hanya tersimpan master key
• Sebaliknya, resident/discoverable credential menyimpan private key itu sendiri di security key, sehingga memakai satu slot untuk setiap akun; Nitrokey hanya mendukung 8 slot, sementara Yubikey umumnya hanya sekitar 20–32 slot
• Security key CTAP2.0 tidak dapat menghapus resident key satu per satu, sehingga perlu reset penuh; saat itu master key juga berubah, membuat non-resident key yang sudah ada ikut tidak berfungsi
• Jika layanan dan library secara default mewajibkan resident key, pengguna dengan 150 akun lebih harus mengelola beberapa security key beserta key cadangannya, sehingga sulit memilih authenticator yang diinginkan secara bebas

---

Mengapa resident key menjadi inti masalah

• Inti kekhawatiran bahwa ekspektasi berlebihan terhadap Passkeys dapat membuat security key tampak seperti perangkat usang terletak pada resident key
• Anggapan bahwa security key mendukung jumlah akun yang “tak terbatas” dalam banyak kasus bertumpu pada pendekatan non-resident credential
• Resident key benar-benar mengonsumsi ruang penyimpanan internal security key, sehingga ketika jumlah akun bertambah, batas perangkat langsung terlihat

Cara kerja non-resident credential

• Dalam non-resident credential, saat autentikasi Relying Party mengirimkan credential ID ke security key melalui browser
• Credential ID adalah blob terenkripsi yang hanya dapat didekripsi oleh security key, dan hasil dekripsinya adalah private key khusus untuk Relying Party tersebut
• Security key menandatangani challenge dengan private key yang telah didekripsi, lalu mengembalikan tanda tangan ke browser dan Relying Party
• Dalam struktur ini, private key tidak menetap di dalam secure enclave; di dalam security key hanya ada master key
• Credential ID dienkripsi dengan AES-128 dan diberi HMAC, sehingga dinilai sulit diubah atau didekripsi dari luar
  • Perbandingan yang muncul: jika AES-128 dapat ditembus hingga private key bisa didekripsi tanpa security key, maka enkripsi TLS atau SSH pun berada pada tingkat yang dapat diserang

Perbedaan resident/discoverable credential

• Resident key atau discoverable credential adalah pendekatan di mana private key disimpan di dalam security key
• Jika Relying Party mengirim daftar credential ID kosong, security key mencari key yang dapat digunakan untuk RP tersebut, memilihnya, lalu menandatangani
• Struktur ini tidak bergantung pada cara menerima credential ID dari luar lalu mendekripsinya dengan master key
• Sebagai gantinya, setiap credential menempati ruang internal security key, sehingga jumlah slot resident key menjadi batas jumlah akun yang sesungguhnya

userVerification terpisah dari resident key

• Ada kebingungan bahwa credential harus resident agar dapat memaksa userVerification, tetapi kedua konsep ini terpisah
• Security key tidak hanya memeriksa presence melalui sentuhan, tetapi juga dapat memverifikasi PIN atau biometrik secara internal untuk memastikan pengguna sebenarnya
• Perilaku ini dikendalikan oleh userVerification flag, dan bekerja secara terpisah dari key residency
• Karena itu, meskipun bukan resident key, perangkat tetap dapat digunakan seperti authenticator multifaktor secara mandiri

Ruang penyimpanan security key dan batasan CTAP

• Karena resident key disimpan di dalam perangkat, jumlah slot pada security key menjadi penting
  • Nitrokey mendukung 8 resident key
  • Yubikey umumnya mendukung 20–32 resident key
  • Sebagian key sama sekali tidak mendukung resident key
• Standar CTAP yang diimplementasikan security key juga sangat menentukan kemudahan pengelolaannya
  • CTAP2.1 dan CTAP2.1PRE dapat mengelola, memperbarui, dan menghapus resident key satu per satu
  • CTAP2.0 memerlukan reset seluruh perangkat untuk menghapus resident key
• Reset perangkat CTAP2.0 juga mereset master key, sehingga non-resident key yang sudah ada pun tidak lagi berfungsi
• Banyak security key kemungkinan besar masih CTAP2.0, dan dalam kasus Yubico, versi CTAP bergantung pada versi firmware

Nama passkeys dan meluasnya definisi resident key

• Pada 2022, Apple mengumumkan fitur passkeys di macOS/iOS yang menggunakan Touch ID dan Face ID seperti WebAuthn authenticator
• Nama passkeys dinilai lebih ramah bagi pengguna dibanding “webauthn authenticator” atau “security key”
• Setelah itu, sebelum makna passkeys benar-benar tetap, muncul berbagai interpretasi
  • Library Rust WebAuthn dan implementor Relying Party mendefinisikan passkeys sebagai nama untuk semua authenticator yang dapat dipilih pengguna
  • Sebagian anggota komunitas menyebut passkeys sebagai credential yang disinkronkan di antara beberapa perangkat
  • Di konferensi FIDO Authenticate, muncul definisi “passkey adalah resident key”, dan kemudian FIDO juga memakai definisi ini dalam FAQ
• Salah satu alasan definisi resident key mendapat perhatian adalah kaitannya dengan fitur browser yang direncanakan, yaitu conditional UI
  • Jika credential adalah resident key, nama pengguna dan credential WebAuthn dapat diisi otomatis
  • Ini memberikan pengalaman di mana pengguna tidak perlu mengetikkan nama pengguna secara langsung

Masalah pengguna yang muncul dari kewajiban resident key

• Jika library WebAuthn mendorong agar semua pendaftaran mewajibkan resident key, security key dengan ruang penyimpanan terbatas dapat cepat penuh
• Misalnya, jika ada lebih dari 150 kata sandi tersimpan di password manager, mengubah semuanya menjadi resident key akan membutuhkan setidaknya 5 Yubikey
• Jika memperhitungkan cadangan, pengguna mungkin harus mengelola 10–15 Yubikey
• Ini menjadi pengalaman pengguna yang buruk bagi mereka yang memilih security key, dan kewajiban resident key pada passkeys dapat membuat penggunaan security key itu sendiri menjadi sulit
• Dalam pemasaran key bersertifikasi FIDO, frasa seperti “penyimpanan key pair tak terbatas” atau “tanpa batas jumlah akun terdaftar” digunakan, tetapi meski benar untuk non-resident key, klaim ini bertentangan dengan kewajiban resident key
• Salah satu tujuan WebAuthn Work Group adalah memungkinkan pengguna memilih authenticator yang mereka inginkan secara bebas tanpa dirugikan, tetapi pemaksaan resident key tidak sejalan dengan tujuan ini
• Jenis authenticator yang disebut dapat berfungsi dengan baik di lingkungan passkey mencakup Apple passkeys, Android passkeys, password manager yang mendukung WebAuthn, Windows yang memakai TPM 2.0, serta browser berbasis Chromium di macOS yang menggunakan Touch ID seperti TPM

Arah respons yang mungkin

• Ada opsi untuk mengubah perilaku rk=preferred agar tidak membuat resident key pada security key
  • Saat ini Relying Party dapat menentukan tingkat permintaan resident key sebagai salah satu dari discouraged, preferred, atau required
  • Saat ini rk=preferred membuat resident key bahkan pada Yubikey yang merupakan roaming authenticator, sehingga pada akhirnya berperilaku mirip rk=required
  • Jika preferred dilonggarkan menjadi “buat resident key hanya ketika ruang penyimpanan tidak terbatas”, Android/iOS dapat membuat resident key sementara ruang penyimpanan security key tidak dikonsumsi
  • WebAuthn WG saat ini masih cenderung menolak perubahan ini, dan jika browser ingin mengimplementasikannya secara terpisah, secara realistis hal itu bergantung pada keputusan tim Chrome
• Ada juga cara untuk mewajibkan library passkey memakai rk=discouraged
  • rk=required dapat mengecualikan security key
  • rk=discouraged dapat membuat pengguna Android tidak mendapatkan conditional UI
  • Karena nama pengguna sudah memiliki sarana autofill, ini dinilai lebih baik daripada mengecualikan security key
• Ada pula opsi meminta FIDO menjadikan ruang penyimpanan resident key sebagai kemampuan wajib untuk sertifikasi
  • Saat ini FIDO tidak mewajibkan persyaratan kapasitas penyimpanan untuk perangkat tersertifikasi
  • Jika FIDO menginginkan resident key, tuntutannya adalah perangkat tersertifikasi harus mampu menyimpan ribuan resident key

Kesimpulan

• Arus berlebihan yang memandang passkeys sebagai resident key dapat menghalangi atau sangat menyulitkan pengguna security key untuk memilih authenticator yang mereka inginkan secara online
• Masalahnya bukan pada passkeys itu sendiri, melainkan pada penerapan menyeluruh kewajiban resident key terhadap security key yang memiliki ruang penyimpanan dan fungsi pengelolaan terbatas

[GN⁺]

Komentar Hacker News

• Ini agak berbeda dari kriptografi itu sendiri, tetapi ibu saya menelepon panik karena tidak bisa masuk ke Gmail. Ternyata Google otomatis mendaftarkan ponsel Android barunya sebagai passkey dan menjadikannya metode login default, tetapi antarmukanya sangat membingungkan
  Menurut saya terlalu berlebihan untuk mengharapkan orang harus menekan opsi kedua jika ingin login dengan kata sandi, atau memahami apa itu passkey. Katanya “passkey telah dikirim ke Android”, tetapi tidak ada notifikasi yang muncul di ponselnya, dan setelah 30 menit pun kami belum bisa menyelesaikannya. Passkey yang terdaftar otomatis itu juga tidak bisa dihapus, dan alur autentikasi default-nya tidak bisa dimatikan. UX Google buruk sekali, dan rasanya bodoh mempercayakan Android hasil modifikasi di ponsel Samsung kelas bawah sebagai fondasi sistem autentikasi berskala besar

  • Masalah yang sama juga ada di autentikasi dua faktor Google. Tertulis “notifikasi telah dikirim ke S21”, tetapi kenyataannya, meskipun saya sedang memegang S21 yang sudah terbuka, 1 dari 3 kali notifikasinya tidak muncul atau baru datang 5 menit kemudian
    Itu cuma salah satu dari banyak masalah yang akhir-akhir ini saya alami dengan Google. Dulu saya setengah menghindarinya karena alasan privasi, sekarang saya mengerahkan segala upaya untuk meminimalkan penggunaan Google. Bisnis saya tiba-tiba hilang dari Google Maps tanpa alasan, dan butuh 2 minggu untuk mendaftarkannya ulang, sementara berbicara dengan manusia sungguh mustahil. Setiap email dukungan memberi nomor telepon, tetapi itu nomor dukungan iklan sehingga tidak bisa berbuat apa-apa untuk akun bisnis yang ditangguhkan, dan mereka bahkan menolak percaya bahwa tim Google Business memberikan nomor itu sebagai nomor dukungan. Saya harus mengulang pertanyaan selama 30 menit sampai staf dukungan Google Ads mengakui bahwa memang tidak ada cara untuk berbicara dengan orang yang menangani Google Business. Sekarang saya sudah jadi penginjil anti-Google
  • Saya serius mempertimbangkan memindahkan bisnis saya keluar dari ekosistem Google karena permintaan verifikasi “notifikasi telah dikirim ke ponsel Anda” yang tidak saya inginkan. Kalau saya tiba-tiba login dari belahan bumi lain, atau biasanya selalu memakai Linux lalu browser saya terdeteksi sebagai Windows, saya masih bisa memahaminya, tetapi saat memakai ungoogled chromium yang berfokus pada privasi, hal ini terjadi setiap kali autentikasi bahkan dari IP yang sama
    Bagaimana kalau baterai ponsel habis? Bagaimana kalau ponselnya hilang, dan Anda perlu memulihkan kredensial layanan lokasi dengan mengirim reset kata sandi ke email, tetapi Anda tidak bisa masuk ke email itu? Dari situ mulailah prosedur “jawab pertanyaan”. Algoritme tersembunyi yang tanpa akuntabilitas memutuskan bahwa ungoogled chromium di Linux itu mencurigakan, dan jika Anda salah mengingat jawaban pertanyaan seperti “berapa persen ruang penyimpanan yang sedang digunakan saat ini?”, pemulihan akses sepenuhnya bergantung pada keberuntungan. Sebagai catatan, saya pengguna Google berbayar
  • Koreksi kecil: passkey tidak “dikirim” ke Android. Login Gmail bekerja dengan menampilkan kode QR di browser lalu memintanya dipindai agar Android membuktikan bahwa ia memiliki passkey tersebut
    Meski begitu, saya sepenuhnya paham maksud utamanya. UX dan terminologinya memang membingungkan. Walaupun tiap langkah memberi penjelasan, orang—terutama saat sedang panik—terlatih untuk melewati teks penjelasan kecil dan menekan tombol yang paling besar dan paling mencolok, jadi itu tidak banyak membantu. Dari sisi perancangan UX, ini memang masalah yang sangat sulit
  • Setelah mengalami ini, saya benar-benar melewati batas. Saya jadi sadar bahwa Google tidak mengambil keputusan berdasarkan pengguna. Mereka menghasilkan uang dari pengiklan, memberi layanan hanya sebatas agar pengguna tidak pergi, dan mempertahankannya hanya sebatas untuk menghalangi pesaing
    Selama pengguna tidak pergi, Google tidak peduli, dan memang tidak perlu peduli. Kalau menginginkan sesuatu yang lain, Anda butuh layanan yang biayanya tidak ditanggung pengiklan. Jika Google mengeksploitasi pengguna dengan satu cara, Apple hanya mengeksploitasi dengan cara lain, dan memilih racun bukanlah sebuah pilihan
  • Kalau mau adil, ini bukan masalah passkey itu sendiri, melainkan lebih karena UX produk Google yang bodoh. Jika Google tiba-tiba mengubah UX login ke cara yang tidak familiar bagi pengguna, kebanyakan orang pasti bingung

• Karena Apple tidak benar-benar mendefinisikannya, para pemikir pun mengisi kekosongan itu untuk pengguna yang ingin tahu, “sebenarnya passkey itu apa?”
  Selama ini saya memahami bahwa Apple mendefinisikan passkey sebagai pasangan kunci yang disinkronkan lewat iCloud Keychain. Dalam presentasi WWDC 2021 pun passkey dibedakan dari security key karena “selalu Anda bawa”, yakni sinkronisasi antarperangkat, dan “bisa dipulihkan”. Setelah itu, definisinya tampaknya meluas ke metode sinkronisasi cloud lainnya. Menurut saya artikel ini membuat kompromi yang keliru. Security key tidak penting[1]. Hanya sangat sedikit pengguna teknis dan segelintir perusahaan yang benar-benar peduli keamanan yang memakainya. Jika ingin meningkatkan keamanan web, kita harus membuat orang meninggalkan kata sandi, dan 99% populasi tidak akan memakai security key kecuali dipaksa. Passkey punya peluang besar menggantikan kata sandi, terutama karena integrasinya yang dalam dengan sistem operasi. Autentikasi tidak seharusnya dioptimalkan mengikuti pengguna kurang dari 1% hanya karena slot resident key mereka tidak cukup. [1] Saya punya 3 Yubikey, 3 Yubico security key, dan 1 SoloKey

  • Sasarannya bukan produk Apple Passkey, melainkan inisiatif tingkat industri. Menjelang peluncurannya pada 2022, definisinya dilonggarkan sehingga, misalnya, lebih mendekati sebuah “pengalaman” yang dapat ditemukan dan menyediakan opsi verifikasi pengguna
    Pengguna bisa memilih apakah akan memakai penyedia passkey yang mendukung pencadangan dan pemulihan, dan pihak yang mengandalkan sistem itu menerima sinyal tersebut. Berdasarkan sinyal ini, mereka bahkan bisa memutuskan apakah akan menyarankan penghapusan opsi login kata sandi
  • Passkey sebenarnya didefinisikan oleh FIDO Alliance
    Menurut standar FIDO, passkey menggantikan kata sandi dan memungkinkan pengguna login ke situs web dan aplikasi dengan lebih cepat, mudah, dan aman di berbagai perangkat mereka. Tidak seperti kata sandi, passkey selalu kuat dan tahan phishing. https://fidoalliance.org/passkeys/

• Saya tidak paham kenapa rk=required ada. Dari awal seharusnya ini tidak boleh menjadi opsi
  Karena hal seperti inilah saya terus khawatir dan skeptis terhadap passkey beserta pihak-pihak terkait. Mereka punya tanggung jawab merancang protokol agar tidak menjadi alat yang nyaman dipakai oleh praktik pasar yang jahat dari perusahaan besar seperti Microsoft, yang bisa merusak keamanan dan kompatibilitas secara serius serta mematikan persaingan. Tetapi sikap yang berulang kali terlihat dari tulisan dan postingan mereka lebih dekat ke “persetan, kami akan mempermudah penyalahgunaan”. Ini bukan cuma masalah kunci residen; misalnya, cara attestation diproses juga bisa dengan mudah disalahgunakan untuk mematikan perusahaan

  • Tujuannya di sini tampaknya adalah menjadikan ponsel sebagai passkey, dan tidak memakai apa pun selain itu. Dari sudut pandang itu, semua isi tulisan tersebut jadi masuk akal
  • Menurut saya ini masih tidak seburuk penyalahgunaan attestation
    Jika suatu layanan menetapkan rk=required tetapi platform tidak mau, tidak ingin, atau tidak mampu mengaktifkan atau mendukungnya, prosesnya tampaknya akan selalu gagal sehingga pendaftaran pun tidak bisa dilakukan. Kalau tujuannya adalah onboarding pengguna dan mengembangkan bisnis, ini terlihat seperti pilihan yang malah merugikan diri sendiri
  • Saya penasaran masalah apa yang dimaksud dengan “cara attestation diproses bisa disalahgunakan untuk dengan mudah mematikan perusahaan”

• Saya sama sekali bukan orang keamanan atau kriptografi, jadi tulisan ini sangat sulit diikuti, dan saya rasa orang lain juga akan begitu
  Bagi orang yang punya cukup pengetahuan latar, ini mungkin terdengar seperti pertanyaan aneh, tetapi saya tersendat setiap satu-dua kalimat. Saya tidak paham bagaimana dan kenapa “pada akhirnya semuanya bermuara pada kunci residen”, juga tidak paham hubungannya dengan passkey atau HSM. Kalimat “Anda harus memahami apa itu kunci yang dapat ditemukan/kunci residen” juga ambigu: apakah itu berarti semua kunci residen adalah kunci yang dapat ditemukan, semua kunci yang dapat ditemukan adalah kunci residen, atau keduanya? Lalu ada kalimat “Anda mungkin pernah melihat bahwa kebanyakan key mendukung akun ‘tanpa batas’”, tetapi saya tidak tahu apakah key di sini berarti passkey, kunci yang disimpan di HSM, atau keduanya. Kalimat “mengirim kunci yang dibungkus kunci ke security key” juga membingungkan: apakah itu berarti alasan HSM bisa diterapkan pada akun tanpa batas adalah karena ia dapat menyimpan suatu kunci dengan membungkusnya menggunakan kunci lain?

  • Intinya tampaknya adalah bahwa WebAuthn sedang didorong ke model passkey, di mana tiap situs membuat kredensial yang menghabiskan ruang penyimpanan. Nama situs yang bisa ditampilkan, nama akun pengguna, handle rekaman pengguna, kunci privat, dan item lain semuanya memakan ruang penyimpanan
    Ponsel bisa menyimpan 10.000 passkey tanpa masalah, tetapi hardware key modern mungkin total hanya bisa menyimpan 25 di flash yang tersedia. Alasan ruang penyimpanan ini diperlukan adalah discoverability. Misalnya, di halaman login GitHub.com, jika Anda menekan dukungan passkey baru, Anda bisa login tanpa memasukkan nama akun sama sekali. Browser memberikan pengalaman seperti pengelola kata sandi, dan seperti kata sandi di dalam pengelola kata sandi, passkey juga menjadi rekaman akun situs secara lokal. Namun, WebAuthn juga punya beberapa mode selain passkey. Kredensial yang tidak dapat ditemukan mengharuskan daftar handle disediakan untuk akun pengguna tertentu, dan handle ini adalah yang diberikan key saat registrasi. Saat autentikasi, hanya kredensial yang cocok dengan handle yang ditampilkan sebagai pilihan. Hardware security key memanfaatkan hal ini dengan menyimpan rekaman yang diperlukan untuk operasi kriptografi di masa mendatang di dalam handle itu sendiri, dan mode ini tidak memakai ruang penyimpanan flash. Setelah pengguna memasukkan nama pengguna, suatu API mengembalikan daftar handle, lalu ini diterapkan ke security key sehingga autentikasi bisa dilakukan tanpa batasan penyimpanan. Namun, banyak situs punya kebijakan untuk tidak mengungkap apakah suatu akun ada. Anda mungkin pernah melihat prosedur pemulihan seperti “Jika akun ini ada, Anda akan segera menerima email.” Dari sudut pandang situs, bisa jadi sulit menerima prosedur login yang menyediakan API untuk mendeteksi apakah ada akun yang terkait dengan nama pengguna atau email, dan berapa banyak kredensial yang tercatat. Pada akhirnya, tampaknya lebih mungkin akan muncul security key dengan penyimpanan 10x lebih besar daripada situs-situs mengadopsi prosedur ini secara luas sampai memengaruhi batasan hardware saat ini
  • Saya setuju bahwa argumen tulisannya kurang bagus. Poin intinya adalah klaim bahwa fitur dalam protokol WebAuthN yang memungkinkan relying party menentukan rk=required itu berbahaya. Alasannya, ini membuat banyak hardware TPM tidak dapat berfungsi sebagai dompet/database passkey
    Saya rasa sebagian besar komentar akan setuju soal ini. Namun itu tidak berarti kebingungan yang dibuat penulis dengan menghabiskan setengah tulisan untuk perdebatan definisi passkey jadi bisa dibenarkan
  • Tulisan ini memang mengasumsikan cukup banyak pengetahuan tentang FIDO2, jadi wajar kalau membingungkan
    Passkey diimplementasikan di atas FIDO2, dan secara khusus memanfaatkan fitur kunci residen dalam spesifikasi FIDO2. Perangkat autentikasi hardware FIDO2 tidak persis sama dengan HSM, tetapi mirip, dan ada juga perangkat yang sekaligus merupakan HSM dan perangkat autentikasi FIDO2, seperti Yubikey. Dalam FIDO2, “kunci residen” dan “kunci yang dapat ditemukan” adalah sinonim. Spesifikasinya memakai “kunci residen”, tetapi “kunci yang dapat ditemukan” juga sering dipakai, dan ini salah satu istilah membingungkan buatan FIDO. “Key” di sini bukan berarti passkey atau kunci yang disimpan di HSM, melainkan perangkat autentikasi hardware FIDO2 seperti Yubikey, yang sering disebut “security key”. Perangkat autentikasi hardware FIDO2 pada dasarnya tanpa state dan tidak menyimpan apa pun kecuali jika memakai kunci residen, sehingga dapat didaftarkan ke akun tanpa batas. Saat didaftarkan ke akun, perangkat membuat pasangan kunci seperti EdDSA tetapi tidak menyimpannya; kunci privatnya dienkripsi dengan master key bawaan, misalnya kunci AES256. Lalu perangkat mengirim kunci publik dalam bentuk plaintext dan kunci privat yang terenkripsi ke relying party seperti google.com untuk disimpan. Saat autentikasi, kunci privat terenkripsi tersebut, yaitu kunci yang “dibungkus”, dikirim ke perangkat autentikasi, didekripsi di dalam perangkat, lalu dipakai untuk membuat tanda tangan digital. Namun, FIDO2 sebenarnya tidak menentukan bagaimana kunci non-residen harus diimplementasikan, dan kunci yang dibungkus hanyalah salah satu cara. FIDO2 hanya mensyaratkan bahwa kunci privat harus bisa diturunkan dengan aman dari credential ID, dan credential ID itu adalah data arbitrer yang bisa berupa kunci yang dibungkus atau bukan

• Sepertinya ini melihat situasinya terlalu suram. Jika ingin mendapatkan manfaat dari standar autentikasi baru yang menghilangkan kata sandi lemah dan penggunaan ulang kata sandi sehingga mencegah 99% pembobolan akun sehari-hari, ini juga bisa dipandang sebagai keharusan mengeluarkan 30 dolar untuk upgrade dari Yubikey lama yang sudah bertahan sejak 2013

  • Saya tidak paham kenapa harus dipaksa upgrade. Kunci non-residen juga menghilangkan kata sandi lemah dan penggunaan ulang kata sandi. Kunci residen hanya menambahkan peningkatan kecil berupa layanan bisa mengetahui itu milik akun yang mana saat kunci dicolokkan, dan itu tampaknya bukan alasan yang cukup kuat untuk membuang semua perangkat autentikasi lama yang saat ini masih dipakai
  • Saya melihat manual teknis seri 5, dan tampaknya hanya mendukung 25. Saat ini saya baru punya 2, tetapi TOTP saya jauh lebih banyak dari 25
    Saya tidak tahu bagaimana model Bio FIDO, tetapi jika mirip, YubiCo mungkin tidak punya produk yang cocok untuk jumlah kunci residen yang besar. Sunting: Bio juga punya batas yang sama, 25
  • Menurut saya justru itu tafsiran yang terlalu murah hati
    Kunci residen yang dibagikan seharusnya tidak ada, kecuali untuk penggunaan sementara jangka pendek. Itu menambah beban tanggung jawab, merupakan risiko keamanan, dan mendorong praktik keamanan yang buruk. Contoh terbaiknya adalah TOTP yang penuh cacat dari sudut pandang keamanan. Anda seharusnya tidak ingin membagikan atau mencadangkan rahasia bersama ke banyak perangkat, tetapi karena hal itu dimungkinkan dan implementasi autentikasi dua langkah yang longgar menjadi standar alih-alih pengecualian, orang pada praktiknya dipaksa melakukannya. Melihat arah sekarang, passkey tampaknya juga akan menuju arah yang sama: penuh cacat dan tidak ramah pengguna
  • Tetap saja, tidak banyak yang berubah. Kunci saya hanya bisa menampung 25 kunci residen, sementara kata sandi yang tersimpan di pengelola kata sandi saya lebih banyak dari 25
  • Saya khawatir ke depan tidak akan ada pilihan selain mengambil “manfaat” ini. Jika situs mengimplementasikan standar autentikasi baru, apakah nama pengguna/kata sandi/autentikasi dua langkah yang sekarang juga akan terus dipertahankan sebagai alternatif?

• Autentikasi yang didasarkan pada “sesuatu yang Anda miliki tetapi bisa hilang” pada dasarnya rusak. Jika perangkat hilang, Anda kehilangan akses, atau kalau tidak, berarti titik terlemahnya harus ada di tempat lain sehingga keamanan hebat itu jadi tidak berarti

  • Cukup cetak kode cadangan atau tambahkan kunci cadangan di laci kedua. Idenya sendiri bagus, tetapi pemasarannya sangat buruk, alur penyiapannya aneh untuk pengguna umum, dan mendorong kunci yang bisa AirDrop atau sinkronisasi cloud juga ide yang buruk. Masalah paling penting adalah biaya kunci
  • Bukankah kata sandi juga termasuk di sini? Orang juga sering kehilangan kata sandi
    Nanti hasilnya akan membuktikan, tetapi jika passkey diadopsi luas, sepertinya bagi kebanyakan orang akun terkunci justru akan lebih jarang, bukan lebih sering

• Saya penasaran kenapa kapasitas penyimpanan kunci hardware sangat terbatas. Berapa banyak tambahan biaya untuk memasukkan media penyimpanan berkapasitas besar yang bisa diakses prosesor aman di dalam kunci?
  Media penyimpanan besar ini tentu bisa dienkripsi kuat oleh prosesor aman, dan saat semuanya dihapus, kunci untuk itu juga ikut dihapus

  • Karena penyimpanan antirusak yang aman itu mahal
    Dari sudut pandang keamanan, bahkan bisa dikatakan kunci keamanan terbaik adalah kunci keamanan dengan kapasitas penyimpanan 0. Protokol yang tidak menurunkan token keamanan dari rahasia bersama dan sejenisnya, melainkan menyuntikkan lalu menyimpannya di kunci keamanan atau secure enclave, umumnya punya cacat serius. Kadang itu cacat keamanan mendasar seperti TOTP, kadang cacat kompleksitas. Demikian juga, Anda sama sekali tidak seharusnya ingin membagikan kunci keamanan untuk HSK/autentikasi dua langkah ke banyak perangkat. Jika bocor dari satu perangkat, semuanya habis. Sebagai gantinya, setiap perangkat harus punya kunci terpisah, dan dari gambaran besarnya overhead ini nyaris bisa diabaikan bagi penyedia login atau sisi server
  • Ini tampaknya pilihan desain yang disengaja untuk menjaga perangkat seperti ini tetap semaksimal mungkin “bodoh”. Begitu Anda menambahkan penyimpanan, terbuka permukaan kerentanan yang sama seperti perangkat penyimpanan lain, lalu berikutnya muncul kemampuan komputasi, dan akhirnya yang Anda punya bukan lagi Yubikey bodoh melainkan komputer penuh
  • Mungkin saja kapasitas penyimpanan bisa ditambah, tetapi makin banyak yang dimasukkan, makin besar pula kemungkinan rusaknya. Kunci-kunci saat ini mampu menahan pemakaian yang cukup kasar sampai akhirnya benar-benar berhenti berfungsi
    Penyimpanan kecil juga punya keuntungan karena sedikit lebih mudah diaudit. Tentu, menurut standar masa kini, bahkan ukuran kecil itu pun mungkin sudah mendorong batas apa yang realistis untuk diaudit
  • Bukan semata karena memorinya terbatas, melainkan lebih dekat ke desain yang sejak awal tidak memiliki batas memori
    Lihat TPM: setiap kali menandatangani sesuatu, inputnya adalah data yang akan ditandatangani dan kunci privat tersegel. Kunci tersegel ini adalah kunci privat yang dibuat TPM lalu dienkripsi secara simetris dengan kunci yang tertanam di TPM. Kunci tersegel itu disimpan di media penyimpanan besar, lalu diberikan ke TPM pada setiap operasi penandatanganan. Desain ini memungkinkan memiliki sebanyak mungkin kunci selama media penyimpanan besar itu mengizinkan
  • Rasanya ini juga bisa dibuat modular. Misalnya menjual produk yang terlihat seperti USB flash drive, tetapi di bagian belakangnya ada slot untuk mencolokkan kunci keamanan berukuran kecil seperti YubiKey Nano
    Saat kunci keamanan dicolokkan ke slot, USB flash drive itu menyediakan penyimpanan bagi kunci keamanan dan terlihat seperti kunci keamanan bagi komputer. Saat kunci keamanan tidak dicolokkan, perangkat itu berfungsi sebagai USB flash drive biasa. Dalam penggunaan sehari-hari, kunci keamanan dibiarkan terpasang, lalu jika butuh lebih banyak penyimpanan Anda tinggal membeli modul penyimpanan yang lebih besar, mencabut kunci keamanan dari modul lama, mencolokkan modul lama ke komputer untuk menyalin file terenkripsi, memindahkannya ke modul baru, lalu mencolokkan kembali kunci keamanan itu

• Sejak awal saya tidak yakin apakah menggunakan kunci keamanan fisik sebagai passkey itu ide yang bagus. Passkey dimaksudkan sebagai pengganti kata sandi, dan untuk itu tampaknya dibutuhkan sifat dua faktor yang biasanya disediakan ponsel atau desktop, yang selain “sesuatu yang dimiliki” juga meminta “sesuatu yang diketahui” atau “diri sendiri” untuk membuka kunci
  Menurut saya, kunci keamanan fisik lebih baik tetap menjadi autentikasi dua langkah yang digunakan sebagai tambahan di atas passkey dalam konteks keamanan tinggi tertentu. Terutama ketika ketahanan terhadap penyalinan adalah fungsi utamanya. Untuk penggunaan itu, saat mencapai langkah kedua kita sudah tahu akun mana yang ingin dimasuki, jadi kunci residen tidak diperlukan. Selain itu, saya rasa fitur autofill yang diberikan kunci residen penting bagi UX passkey. Tidak masuk akal mengorbankan itu demi menjaga kompatibilitas ke belakang dengan segelintir kunci yang hanya dipakai penggemar keamanan. Tentu saja, kalau ada cara mempertahankan UX itu tanpa kunci residen, tidak masalah

  • Kurang lebih saya sepemikiran. Ide yang kini tampaknya disepakati semua orang adalah memiliki brankas keamanan enkripsi lokal yang tepercaya, lalu identitas harus diverifikasi ke sistem itu. Bisa dengan kata sandi, bisa juga dengan kunci
    Lebih mudah percaya bahwa pengelola kata sandi yang dipilih lebih aman daripada mengasumsikan semua layanan di dunia tempat kita membuat akun itu aman atau mustahil dipancing phishing. Jadi pada saat memakai passkey, sering kali kita sudah berada dalam konteks yang lebih aman karena identitas sudah ditegakkan di OS atau pengelola kata sandi yang memiliki passkey tersebut. Selain itu, tempat-tempat yang sekarang atau hingga baru-baru ini belum mendukung kunci hardware kemungkinan besar juga tidak akan mendukungnya dalam waktu dekat. Sebaliknya, solusi passkey jauh lebih mudah diadopsi karena biaya implementasinya sebatas dukungan perangkat lunak, sehingga kemungkinan ROI-nya jauh lebih tinggi. Tentu ini terutama berlaku untuk situs web, dan passkey kurang lebih seperti “kunci SSH yang distandardisasi” untuk situs web. Kunci hardware tampaknya lebih berguna sebagai faktor dua langkah untuk benar-benar membuka brankas yang berisi passkey, dan di sini kata sandi juga mungkin tetap diperlukan. Masa pakai kunci hardware tampaknya masih ada untuk sementara. Setelah memakainya sebagai metode utama di GitHub, Gmail, dan lain-lain, alur login passkey memang sangat, sangat bagus
  • Pengelola kata sandi sudah membuat kata sandi nyaris tidak berguna. Saya tidak tahu satu pun kata sandi saya selain satu master password. Passkey adalah solusi yang terlalu rumit untuk sesuatu yang sebenarnya tidak terlalu kita butuhkan
    Browser cukup punya API HATEOAS sederhana yang bisa dihubungkan pengelola kata sandi, dan aplikasi web cukup menampilkan HTML yang memicu browser. Lalu pengelola kata sandi menentukan bagaimana mengautentikasi pengguna, yaitu cara yang diinginkan pengguna, dan menyuntikkan secret untuk situs web itu secara otomatis sehingga pengguna login otomatis. Kalau ada masalah, gunakan reset lewat email. Saya paham dari sudut pandang situs web yang menginginkan “keamanan super mewah”, mereka akan menginginkan sesuatu yang lebih kompleks. Tetapi pengguna seharusnya bisa secara opsional mengaktifkan tingkat keamanan yang lebih tinggi. Misalnya, untuk sebagian besar situs web, hash kata sandi sederhana sudah cukup jika diasumsikan pengelola kata sandi memakai kata sandi acak. Situs mana pun bisa menerapkannya, semua pengelola kata sandi bisa menerapkannya, dan itu lebih baik daripada cara 99% pengguna biasa memakai kata sandi saat ini. Jadikan itu metode autentikasi dasar. Setelah itu, jika ingin TOTP, OIDC, kriptografi kunci publik, dan sebagainya, server bisa mengiklankannya dan klien bisa ikut serta secara opsional untuk melanjutkan autentikasi. Tidak semua situs dan semua pengguna harus memakai metode paling aman. Yang penting dulu adalah memudahkan peningkatan baseline keamanan, lalu keamanan yang lebih kuat bisa dipilih secara bertahap
  • Saat melakukan autentikasi tanpa kata sandi (FIDO2) dengan Yubikey, perangkat meminta PIN sebelum menyuruh Anda menyentuh perangkat. Jika salah memasukkan PIN terlalu banyak, Yubikey akan terkunci dan perangkat harus di-reset, dan semua pendaftaran lama yang memakai kunci itu untuk autentikasi akan menjadi tidak valid
    Kalau seseorang mencuri token hardware saya, itu tampaknya bukan masalah besar. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • Kalau dipikir-pikir, masalah intinya bisa dirumuskan sebagai “mengautentikasi keberadaan biologis ke sistem elektronik”
    Jika memakai kata sandi, antarmuka autentikasinya adalah keyboard, dan tidak ada jaminan nyata bahwa orang yang mengetik kata sandi itu benar-benar orang yang ia klaim. Kata sandi bergantung pada pengetahuan yang mudah dibagikan, sehingga bisa diekstrak dengan banyak cara. Jauh lebih baik memindahkan antarmuka autentikasi ke komunikasi perangkat ke perangkat. Alih-alih berasumsi bahwa pengetahuan yang mudah dibagikan itu tidak dibagikan, kita berasumsi bahwa keberadaan biologis itu mampu mengelola perangkat autentikasinya, dan manusia memang cukup piawai dalam hal seperti itu. Kita juga bisa menambah jumlah kanal autentikasi agar lebih kuat, dan membatasi autentikasi antara perangkat yang dipakai untuk autentikasi sistem jarak jauh dan keberadaan biologis itu sendiri, misalnya dengan FaceID. Pada intinya, terasa alami untuk menganggap perangkat seperti ponsel atau kunci itu sendiri sebagai orang tersebut. Di rumah kami berbagi bukan hanya kata sandi Netflix tetapi juga satu kartu kredit. Karena alasan praktis, satu kartu kredit diletakkan bersama kunci cadangan, dan jika perlu membeli sesuatu untuk rumah, siapa pun bisa mengambil dan memakainya. Kami percaya semua orang akan memakai kartu itu dengan benar, dan semua tahu PIN-nya, tetapi hampir tidak pernah diperlukan karena pembayaran nirsentuh sudah umum. Itu terasa jauh lebih alami daripada melacak biaya dan saling menghitung belakangan. Mungkin ini ilegal, dan bank akan membatalkan kartunya jika tahu, tapi begitulah. Sistem TI sangat perlu mendekati perilaku manusia sambil bekerja dengan cara yang mirip dunia nyata. Kebanyakan dari kita bertahan karena memang terlibat dengan sistem TI, tetapi orang yang tidak akrab dengan teknologi bahkan kesulitan dengan hal-hal sehari-hari seperti apa kata sandi iPhone, apa kata sandi iCloud, apa kata sandi Gmail, dan kenapa harus memasukkan kode ke WhatsApp. Sejujurnya saya juga tidak pernah paham Mastadon. Saya rasa saya akan tak berdaya terhadap phishing Mastadon, dan mungkin akan memasukkan apa pun yang diminta layar
  • Tidak tepat mengatakan bahwa passkey adalah pengganti kata sandi

Passkey, sesuai namanya, menumpang pada standar FIDO2 U2F yang dikembangkan sebagai faktor kedua. Kunci residen ditujukan untuk autentikasi dua langkah di perangkat dengan PIN, dan merupakan pengganti fungsional smart card. Seseorang, mungkin Apple, tampaknya berpikir bahwa WebAuthn saja sudah cukup untuk menjadi satu-satunya faktor autentikasi. Tidak ada kunci residen, tidak ada ikatan perangkat keras, dan kunci berpindah melalui iCloud, tetapi di perangkat dilindungi dengan TouchID/FaceID. Lalu ini diberi merek sebagai passkey. Autentikasi dua langkah itu sendiri bukanlah tujuannya. Tujuannya adalah autentikasi pengguna yang aman terhadap phishing, brute force, dan credential stuffing, serta tidak sesulit smart card untuk diimplementasikan. FIDO2 mencapai itu. Masalah pada implementasi Apple, Google, dan Microsoft bukanlah bahwa keamanan tingkat protokol antara situs autentikasi dan perangkat pengguna lebih lemah. Protokolnya sama. Masalahnya adalah situs kini harus mempercayai akun platform pribadi pengguna, percaya bahwa pengguna telah mengaturnya dengan benar, dan percaya bahwa platform akan terus selalu bertindak dengan benar di masa depan sehingga dapat menangani serangan terhadap akun pribadi pengguna dengan semestinya.

• Sebagai konteks, saya menjalankan perusahaan autentikasi tanpa kata sandi yang didanai YC dan telah menerapkannya di organisasi besar. Passkey tampaknya jelas akan menjadi jawaban untuk autentikasi tanpa kata sandi bagi konsumen, tetapi sepertinya hal itu belum benar-benar berlaku di lingkungan perusahaan
  Passkey sangat bagus untuk konsumen. Alasannya, passkey ditujukan agar kredensial bisa dicadangkan ke perangkat lain melalui backup bawaan iCloud atau cara seperti AirDrop, sehingga pengguna sendiri dapat memiliki akses darurat. Secara teknis, perangkat yang menerima kredensial yang dibagikan ini tidak dapat memberikan attestation. Attestation adalah “bukti” bahwa pasangan kunci dibuat di perangkat tertentu seperti Yubikey atau perangkat Apple. Produsen seperti Yubico mengirimkan kunci dengan pasangan kunci dan sertifikat yang tidak dapat diekstrak tertanam di dalamnya, dan karena tidak ada antarmuka eksternal untuk mengakses pasangan kunci ini, administrator dapat cukup yakin bahwa ini benar-benar Yubikey asli. Jika tidak ada attestation dan kunci bisa dibagikan, terlihat jelas di mana masalah mulai muncul. Perusahaan tidak mau menanggung risiko bahwa kredensial yang bisa dibagikan lewat AirDrop akan mengekspos akses ke akun karyawan yang memiliki hak istimewa. Pada Yubikey, praktis tidak ada risiko pencurian digital. Pada akhirnya, passkey juga tidak bisa dipakai untuk membuka kunci perangkat atau server. FIDO2, dan yang lebih penting para pengembang sistem operasi, masih jauh dari benar-benar mengakhiri kata sandi. Saat ini, di sebagian besar pasar enterprise, Yubikey mengisi kekosongan ini, dan sebagian pihak telah menghabiskan jutaan dolar untuk perangkat keras tersebut. Passkey dalam kondisinya saat ini akan sulit dijual

  • Passkey bukan istilah teknis, melainkan istilah pengalaman. Karena itu, ketika dipakai untuk argumen teknis, ia agak runtuh
    Apple mendukung passkey, Android dan Chrome juga, Microsoft juga, Yubikey juga mendukung passkey. Namun fitur dan batasan seperti prosedur autentikasi untuk verifikasi pengguna dan kemungkinan duplikasi dapat sangat berbeda. Lembaga pemerintah bisa saja mendukung passkey, tetapi hanya mengizinkannya jika disediakan lewat perangkat autentikasi bersertifikasi FIPS yang memenuhi persyaratan AAL2. Setidaknya untuk saat ini, itu bukan sesuatu yang akan datang dari Apple atau Google. Perusahaan dapat memilih untuk mendukung passkey yang dibuat melalui perangkat lunak dan konfigurasi yang disediakan produk manajemen MDM, dan Apple telah mengumumkan dukungan beta untuk ini. Namun, jika layanan pemerintah-ke-warga mencoba mewajibkan perangkat autentikasi hardware tertentu, kemungkinan akan timbul banyak kesulitan. Sulit meyakinkan warga untuk membeli hardware seharga lebih dari 80 dolar, dan karena teknologi web dibangun berpusat pada pilihan pengguna, kecil kemungkinan API WebAuthn dan pengalaman pengguna akan dioptimalkan untuk membantu membatasi pilihan pengguna
  • Bagaimana jika Google atau Apple secara tidak sengaja memblokir akun karena alasan konyol seperti anti-bot atau deteksi penipuan?
  • Yubikey 5 bisa digunakan sebagai passkey

• Dari sudut pandang keamanan, menurut saya ini solusi yang benar-benar buruk
  Ini adalah struktur impian bagi pemerintah dan perusahaan seperti Apple dan Google untuk mengendalikan kehidupan digital. Jika menggunakan kata sandi, kondisinya cenderung semacam stateless, sehingga meskipun seseorang melintasi perbatasan sambil memiliki akun email pribadi atau akun lain, tidak ada yang bisa tahu bahwa dia memiliki akun itu, sulit memaksa dia menyerahkan akses, mengekstrak faktor akses dari hardware, atau menguncinya dengan alasan kehilangan akses ke perangkat. Bahkan jika master key dan semacamnya disimpan di TPM atau secure element, pemerintah tertentu tetap bisa mengaksesnya, jadi itu hanya soal beberapa tahun dan daya komputasi. Dalam banyak kasus, itu sendiri juga menjadi bukti bahwa seseorang memiliki kredensial untuk akun tertentu. Produsen perangkat atau sistem operasi dapat dengan mudah dipaksa oleh otoritas untuk memberikan akses ke area aman, dan itu bisa terjadi baik secara sukarela maupun tidak