evilfactorylabs

Rizaldy
Rizaldy

Posted on

Passkeys dan masa depan autentikasi

Passkeys Demo

Setelah sekian lama merantau ke ibukota, bulan Mei kemarin gue berencana untuk pulang ke kampung halaman. Kedatangan gue disambut oleh beberapa anggota keluarga meskipun gue sedikit kecewa karena tidak digelar dengan karpet merah. Just kidding.

Saat beristirahat sambil menghisap beberapa batang rokok di teras, nyokap gue menghampiri. Sambil membawa handphone nya dan dengan pandangan yang sudah gue hafal apa maksudnya, beliau memulai percakapan.

"A, ai password instagram mamah apa, ya?"

Ini bukan kejadian pertama. Terakhir yang gue ingat, gue ditanya kata sandi akun Gmail nyokap dan masih bisa gue tebak karena gue ikut bantu buat.

Dan ini, gue harus menebak kata sandi yang tidak pernah gue buat yang bahkan gue tidak tahu kalau nyokap punya akun instagram.

Sambil menjaga gengsi gue sebagai "si paling IT di keluarga" gue klik tautan lupa password dan meminta nyokap untuk memasukkan alamat email yang beliau miliki.

"No Users Found" muncul dalam toast hitam di layar itu, yang terlihat selama 10 detik.

Gue coba ubah alamat email menjadi username yang sekiranya sama dengan username di email namun tanpa @gmail.com, dan hasilnya masih sama.

Sampai hari ini masih menjadi misteri terkait kombinasi username/email dan password akun instagram nyokap gue ataupun kebenaran bahwa nyokap gue pernah membuat akun instagram.

Mencintai kata sandi

Tahu apa yang menarik dari aktivitas mengingat? Yakni sebuah fakta bahwa kita melupakan sesuatu. Mengingat, bagi sebagian orang termasuk gue, adalah aktivitas yang sangat menyebalkan.

Namun beda cerita jika proses "pengingatan" terjadi berdasarkan gerakan motorik. Seperti, gerakan jari menekan tombol di keyboard tanpa perlu melihat ataupun mengingat letak dari huruf yang dimaksud. Atau, menekan tombol pin saat di mesin ATM. Atau, membuka twitter.com dengan command tab + command t + ketik "tw" setiap selesai menjalankan git push.

Semua terjadi seperti reflek tanpa memberi jeda untuk membuat otak berpikir.

Bahkan jika ada 5 orang bernama fariz di satu ruangan, saat seseorang meneriaki "fariz!", besar kemungkinan kelima orang tersebut akan menoleh tanpa perlu mengingat kembali jika nama mereka adalah fariz.

Ini adalah kebiasaan. Kebiasaan terbentuk dari aktivitas yang dilakukan berulang, dan jika melibatkan motorik, ada sebuah konsep bernama muscle memory.

Saat memilih kata sandi, kita cenderung akan memilih kata sandi yang mudah diingat karena kita yakin di lain hari pasti akan lupa. Memilih kata sandi yang mudah diingat relatif mudah, bisa melibatkan kesukaan; tanda unik, bahkan pola khusus bagi yang suka ngide.

Memilih kata sandi yang mudah diingat tidak selalu berarti memilih kata sandi yang mudah ditebak. Satu kasus umum kata sandi yang mudah ditebak adalah dalam menggunakan satu kata sandi untuk semua kredensial. Terlepas kata sandi tersebut seribet $(openssl rand -hex 8 | base64) ataupun sesederhana hunter2, jika 1 bocor, besar kemungkinan bocor semua.

Tapi sistem hari ini sudah cukup aman dalam membuat proses autentikasi. Kata sandi umumnya disimpan dalam hash dan tidak lupa dibalut dengan garam dan cost agar proses pencocokkan terasa sangat lama—jika memang tidak selamanya—saat terjadi "kebocoran data pengguna".

Selain itu, si "penyedia identitas" besar kemungkinan menyediakan opsi autentikasi multi-faktor untuk memberikan keamanan ekstra kepada pengguna nya.

Tapi pada akhirnya, sistem yang tidak ada "tambalannya" adalah kebodohan manusia itu sendiri. Penerapan sistem autentikasi khususnya di tahun 2023 seharusnya sudah relatif aman, kecuali salah satu sistem autentikasi yang terjebak di masa lalu seperti ini:

plain text password wtf

In the meantime, apakah ada cara untuk hanya bisa mengingat "satu kata sandi yang saya sukai" tanpa mengorbankan apapun yang tidak layak dikorbankan?

The answer is yes.

Pengelola kata sandi

Sejauh ini tidak ada pendidikan formal yang mengajarkan "cara menggunakan internet yang baik dan benar" namun bisa dimaklumi karena tidak ada pelajaran cara melapor pajak ataupun cara menggunakan asuransi di pendidikan formal either, meskipun sama-sama tidak bisa dihindari.

Salah satu komponen penting dalam menggunakan internet adalah penggunaan pengelola kata sandi, karena autentikasi adalah kewajiban yang harus dilakukan setidaknya di internet dengan sebutan "web 2.0" ini.

Tugas utama dari pengelola kata sandi adalah... untuk mengelola semua kata sandi yang digunakan. Karena pada dasarnya otak kita dibuat bukan untuk mengingat semua kata sandi yang ada, atau setidaknya gue tidak menemukan yang membahas itu saat pelajaran biologi dulu.

Memilih pengelola kata sandi adalah pekerjaan yang cukup tricky. Selain fakta bahwa kita menaruh kepercayaan penuh terhadap si pengelola, juga keberadaannya di setiap perangkat yang kita gunakan. Silahkan tanya pengguna password store saat mereka membuka termux untuk menjalankan pass(1) di perangkat kesayangannya.

Di ekosistem Apple, penggunanya cukup "dipaksa" untuk mengelola kata sandi "the Apple way". Jika melakukan registrasi pada suatu layanan melalui peramban Safari, Safari akan memberikan usul untuk menggunakan kata sandi yang "aman" dan tidak jarang juga menawarkan untuk menggunakan alamat email acak khususnya untuk pengguna iCloud+. Jika pengguna menerima usul dari Safari, Safari akan mengelola kredensial tersebut dan menyimpannya di sesuatu bernama "Rantai Kunci".

Peramban lain—terlepas dari sistem operasi yang digunakan—pun menawarkan fitur serupa, kecuali peramban yang digunakan adalah lynx, setidaknya per tulisan ini diterbitkan.

Menggunakan pengelola kata sandi yang bergantung pada sesuatu sebenarnya cukup menyebalkan. Jika menggunakan pengelola kata sandi yang ditawarkan oleh Google Chrome, maka pengguna harus memasang Google Chrome di semua perangkatnya. Bisa ganti kata Google Chrome diatas menjadi Mozilla Firefox, Microsoft Edge, Brave Browser, apapun.

Yang mana bukanlah masalah besar. Sayangnya, peramban mainstream dikembangkan oleh entitas yang bertindak sebagai penyedia identitas juga: Google Chrome (Google), Safari (Apple), Microsoft Edge (Microsoft). Yang maksudnya, jika akun yang bersangkutan bermasalah, secara tidak langsung akan berdampak ke fungsionalitas pengelola kata sandi yang digunakan juga. Alias, dampak dari "one account to rule them all".

Pertimbangannya adalah dengan menggunakan layanan yang memang bertugas untuk mengelola kata sandi, dan hanya melakukan itu. Ini seharusnya bukanlah pilihan alternatif, melainkan pilihan utama. Penyedia layanan dalam urusan pengelolaan kata sandi ini yang cukup populer dan terpercaya menurut gue adalah 1Password, Bitwarden, dan Dashlane.

Gue pribadi menggunakan Bitwarden (via Vaultwarden) dan menjalankannya di server rumah. Bitwarden tersedia lintas platform dan menyediakan "pilihan universal" seperti akses melalui peramban alias versi web nya yang relatif viable—dan selama kode JavaScript dapat dijalankan.

Benefit utama dari menggunakan pengelola kata sandi adalah hanya perlu mengingat 1 kata sandi alias "master password" yang kemungkinan adalah kata sandi favorit kalian yang mudah diingat, dan biarkan si pengelola kata sandi mengatur sisanya.

Per tulisan ini dibuat, setidaknya ada 84 "identitas" yang dikelola oleh Vaultwarden gue dan menggunakan 84 alamat email serta kata sandi yang berbeda yang tidak pernah gue ingat sama sekali. Setiap ingin autentikasi, yang gue perlukan hanyalah menekan tombol "cmd+shift+l", memasukkan touch ID, lalu tekan enter.

Jika dalam kondisi touch ID tidak bisa diakses (laptop ditutup dan menggunakan layar eksternal) gue tinggal memasukkan "master password" sambil menyanyi karena memang penggalan dari lirik lagu dengan tambahan angka dan simbol sebagai pemanis.

Tapi apakah menggunakan pengelola kata sandi saja cukup?

Hampir.

Tapi sayangnya, hampir itu tidak pernah cukup.

Autentikasi Multi-faktor

Sistem autentikasi umumnya melibatkan satu faktor, yakni faktor pengetahuan. Ini adalah tentang kombinasi dari username/email + kata sandi yang umum ditemukan di layanan yang berada di internet. Jika kombinasi tersebut salah, maka proses autentikasi gagal.

Ada faktor lain untuk keamanan ekstra yakni faktor kepemilikan, dan ini sifatnya komplemen. Faktor ini berguna dikasus ketika terkena phising, numpang login di perangkat berbagi, atau mungkin ketika komputer tertanam keylogger.

Berbeda dengan faktor utama yang melibatkan informasi faktual, di faktor kedua ini, melibatkan informasi aktual yang hanya valid pada waktu tertentu. Informasi tersebut adalah "kata sandi sekali pakai" atau yang umum disebut OTP. Dan idealnya, OTP melibatkan waktu alih-alih "penghitung".

Di sistem OTP yang menggunakan penghitung, biasanya kode dikirim ke "sesuatu yang dimiliki pengguna terdaftar" seperti telepon genggam dan kode tersebut hanya valid dalam satu sesi. Ini ada celahnya: kode dikirim melalui protokol yang relatif kurang aman dan juga siapapun dengan izin tertentu dapat mengakses konten dari perpesanan melalui API yang disediakan, jika memang ada dan diizinkan.

Berbeda dengan TOTP yang menggunakan kombinasi "kata rahasia" + "waktu pada saat itu" dalam membuat kata sandi sekali pakai, karena si perangkat harus mengetahui "kata rahasia" yang digunakan yang umumnya disimpan di perangkat yang si pengguna gunakan.

Karena pengelola kata sandi umumnya menyediakan "manajemen TOTP" juga, terkadang ini membuat dilema. Tidak jarang pengguna menyimpan kedua faktor tersebut di satu tempat (pengelola kata sandi) yang mana membuat "faktor kedua" terasa sia-sia, yang meskipun tidak 100% adalah hal yang salah.

Solusinya biasanya si pengguna menggunakan aplikasi lain yang memang khusus untuk menyimpan kode OTP seperti Google Authenticator, Authy, dan TOFU Authenticator atau menggunakan perangkat khusus seperti yubikey.

Sejauh ini pengelolaan kata sandi (atau identitas secara umum) menjadi terasa cukup ribet. Namun sayangnya, nobody said it was easy either.

Passwordless

Di dunia per-autentikasi-an sempat populer konsep passwordless dengan pendekatan "magic link". Ini adalah tentang autentikasi yang literally tanpa password: pengguna cukup memasukkan alamat email terdaftar, lalu tautan untuk autentikasi akan dikirim ke alamat email yang dimaksud, dan voila. Tautan tersebut hanya valid untuk satu sesi, jadi, jika program "anti virus" di email server yang digunakan memindai tautan tersebut, sampai valve merilis half-life 3 pun akan selalu kadaluwarsa. Kecuali sampai mematikan fitur pemindaian tersebut atau si sistem bisa membedakan pengakses tautan tersebut.

Pendekatan ini sekilas cukup efektif dan secara teknis melibatkan 2 faktor tanpa upacara tambahan: pengguna harus mengingat alamat email yang digunakan dan harus memiliki akses ke alamat email yang umumnya tersambung di perangkat yang pengguna miliki.

Dan bagaimana jika si "penyerang" memiliki akses ke email si korban? Kabar buruknya, bahkan identitas si korban di internet sudah dikuasai, bukan hanya sebatas identitas di platform tertentu.

Meskipun magic link sekilas terlihat sempurna, tapi masih memiliki celah. Satu-satunya celah yang sejauh gue tahu dari magic link ini adalah pengguna harus menggunakan email yang aktif. Yang maksudnya, jika suatu saat pengguna ingin mengganti alamat email ke alamat email baru dan sedangkan alamat email lamanya sudah tidak aktif/tidak bisa diakses, gue rasa tidak ada cara lain untuk memulihkannya kecuali mungkin jika si sistem memberikan cara menggunakan "recovery code" yang anggap hanya bisa digunakan selama 6x, misalnya.

Selain itu, ada biaya tambahan dalam sistem yang menggunakan magic link ini yang salah satunya adalah di biaya pengiriman transaksi email yang sekalipun harganya relatif terjangkau.

Ancaman lain adalah di menentukan apakah si email tersebut dikirim oleh pengirim asli dengan konten yang valid or otherwise, yang meskipun masalah ini sudah memiliki solusi seperti mengatur DMARC, DKIM, blablabla tapi tidak mencegah masalah inti tersebut terjadi.

Passkeys

Pada 05 Mei 2022 tahun lalu, FIDO Alliance menerbitkan tulisan berjudul "Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard to Accelerate Availability of Passwordless Sign-Ins", dan 1 tahun setelahnya (03 Mei 2023), Google membagikan perkembangannya berjudul "The beginning of the end of the password".

Di lain sisi, 1Password—perusahaan penyedia layanan manajemen kata sandi—pada 09 Februari 2023 menerbitkan tulisan berjudul "Goodbye, passwords" yang intinya mereka akan menerapkan Passkeys di 1Password.

Passkeys merupakan teknologi yang dibuat berdasarkan standar FIDO (Fast IDentity Online), dan FIDO sendiri adalah sebuah protokol untuk melakukan autentikasi. Pernah bermain dengan OAuth 2.0? OAuth adalah sebuah protokol untuk autorisasi (i.e permohonan dari penyedia layanan untuk mengakses properti (alamat email, nama, dll) yang dimiliiki si pengguna di layanan lain (identity provider) untuk digunakan). Membawa sedikit topik OAuth gue rasa sebuah keharusan karena tidak jarang yang sedikit keliru terkait perbedaan antara autentikasi dan autorisasi.

Lanjut, protokol untuk autentikasi cukup beragam, namun yang cukup populer adalah OpenID Connect (OIDC). Hampir setiap layanan yang bertindak sebagai identity provider/IdP juga mendukung autentikasi melalui protokol OIDC ini. Aman dibilang menjadi de facto standard dalam sistem autentikasi lah.

Penerapan protokol FIDO dalam sistem autentikasi gue rasa awal populernya adalah di penerapan FIDO U2F via WebAuthn, yang umumnya bertindak sebagai faktor kedua. Jika umumnya faktor kedua adalah memasukkkan OTP berdasarkan kode yang dibuat oleh perangkat yang dimiliki, dengan WebAuthn, melibatkan PKI alias Partai ehm Public Key Infrastructure (private key yang ada di si perangkat) alih-alih sebuah kode unik yang harus diketahui.

Sukses dengan FIDO U2F (projekan antara Yubico dan Google), terbitlah Passkeys alias WebAuthn alias FIDO2 (projekan antara W3C dan FIDO Alliance). Jadi, jika ada yang membahas tentang Passkeys atau WebAuthn, besar kemungkinan mereka membahas 1 hal yang sama (sama seperti membahas "containerd" dengan "teknologi container")

For the record, FIDO U2F pun dibuat diatas FIDO2 by the way.

Misi dari FIDO2 pada dasarnya adalah menghapus autentikasi yang menggunakan "rahasia bersama" seperti kombinasi alamat email/username + kata sandi seperti saat ini. Penerapannya adalah menggunakkan WebAuthn API, baik untuk platform web ataupun platform lainnya.

Protokol FIDO sangat bergantung dengan Trusted Platform Module alias TPM untuk kebutuhan PKI thing, dan hampir setiap "komputer" modern sudah memiliki itu.

Oke, sekarang ke bagian menariknya. Saat melakukan autentikasi, biasanya klien memasukkan kombinasi username + kata sandi, mengirimnya ke server, lalu si server menentukan apakah kredensial tersebut valid. Bagaimana dengan Passkeys?

PKI PKI PKI

Alih-alih si server menyimpan kata sandi dalam bentuk hash (hopefully), si server menyimpan kunci public dari si pengguna tersebut. Teknologi ini bukanlah hal yang baru dan sudah cukup sukses diterapkan di beberapa kebutuhan seperti remote access via protokol SSH.

auth via SSH

Jika kasus SSH umumnya kunci private disimpan di tempat yang bisa dipindahkan (block storage), di kasus WebAuthn, kunci private tersebut disimpan di tempat yang tidak bisa dipindahkan ataupun diubah, yakni di Trusted Platform Module (TPM) atau "Secure Enclave" jika di platform mobile.

Kunci yang dibuat dijamin unik per perangkat, dan ini bagian pentingnya.

Kunci private umumnya dilindungi oleh "passphrase", gampangnya adalah password. Passphrase bersifat opsional dan melibatkan sesuatu yang diketahui, tipikal, bukan?

Dalam teknologi Passkeys, kunci private pun dilindungi namun melibatkan sesuatu unik yang hanya dimiliki oleh pemiliknya: sidik jari atau Face ID.

Konsep autentikasi melalui Passkeys bisa disederhanakan seperti ini:

  • fariz: bang gw mau login username gw oss@rizaldy.club
  • server: buktikan (kasih payload yang di-enkripsi menggunakan kunci public yang sudah terdaftar untuk user tersebut)
  • fariz: *perangkat memindai muka gw* centereng
  • server: welcome, fariz

Tidak ada proses mengingat dibutuhkan, dan bahkan, proses pemasukan username bisa menggunakkan auto complete via "pengelola kata sandi" yang mungkin akan berubah menjadi "pengelola passkeys" lol.

MFA?

Pelibatan "sesuatu yang dimiliki" umumnya berada di faktor kedua dalam alur autentikasi, bagaimana bila itu sekarang menjadi faktor pertama?

Teknologi Passkeys pada dasarnya melibatkan dua faktor juga: sesuatu yang dimiliki (laptop/handphone/security keys) dan sesuatu unik yang hanya dimiliki oleh pemiliknya (sidik jari/komuk). Jika seseorang entah bagaimana mendapatkan handphone mu, well, at least doi harus punya komuk mu yang ganteng itu untuk bisa masuk ke akun Instagram milikmu via autentikasi Passkeys.

Bagaimana dengan passphrase favorit saya yang sudah saya ingat bertahun-tahun dan tidak pernah diganti? Well, waktunya meng-ikhlaskan dan move on ;)

Tradeoffs

Sampai hari ini gue masih menggunakan FIDO U2F di beberapa layanan, dan jika gue sedang nongkrong, besar kemungkinan ada kalung yang melingkar di leher gue dan yes itu adalah YubiKey untuk kebutuhan just in case moment.

Artinya, gue harus membawa YubiKey itu kemanapun ketika butuh dan harus memiliki "cadangan" jika suatu saat YubiKey tersebut hilang ataupun rusak. In fact gue tidak memiliki cadangan, tapi besar kemungkinan si penyedia layanan akan menawarkan 2FA alternatif seperti menggunakan TOTP.

Di Passkeys, kunci berada di perangkat yang dilindungi dengan "sesuatu unik yang hanya dimiliki oleh pemiliknya" yang bisa kita singkat menjadi "biometrics".

Unless lo meninggalkan kepala lo pas nongkrong, well, lo ga bisa login ke dasbor GCP saat just in case moment terjadi pas lagi asik-asiknya nongkrong.

Tapi concern dari Passkeys ini menurut gue ada di interoperabilitas: vendor lock-in.

Berbicara realita sedikit, pasar perangkat keras (dan lunak) pada saat ini dikuasai oleh 3 big co: Apple (Mac/iOS), Microsoft (Windows) dan Google (Chrome OS/Android). Ketiganya adalah identity provier (IdP) juga dan sama-sama wajib memiliki "identitas" (akun) saat menggunakan perangkat keras ataupun lunak yang dikelola oleh mereka: Apple ID, Google Account, dan Microsoft Account.

Passkeys dapat disingkronkan antar perangkat sehingga akun Twitter yang didaftarkan di iPhone dapat digunakan juga di iPad untuk username yang sama. Proses singkronisasi terjadi jika perangkat yang terdaftar menggunakan akun yang sama.

Yang berarti, untuk saat ini, akun Twitter tersebut tidak bisa digunakan di PC dengan OS Windows ataupun di peramban Mozilla Firefox dengan OS GNU/Linux.

Dan ini bagian pentingnya: pengguna menjual jiwanya ke IdP.

Namun ada tapinya.

Passkeys pada dasarnya hanyalah teknologi yang menggunakan protokol FIDO2 dan diterapkan dalam Passkeys. Seperti Gmail yang pada dasarnya hanyalah sebuah teknologi yang menggunakan protokol IMAP dan SMTP dan diterapkan dalam sebuah aplikasi web.

Salah satu yang mendorong teknologi Passkeys yang relatif independen adalah 1Password. Yang singkatnya, besar kemungkinan pengguna bisa autentikasi via Passkeys dimanapun 1Password dapat berjalan.

Selebihnya, gue pribadi all-in dengan teknologi ini.

Tidak perlu verifikasi email, tidak perlu tautan "Forgot passwords?".

What is passwords anyway?

Penutup

Saat mengembangkan aplikasi, tidak jarang gue memikirkan "kenapa gue harus membuat sistem autentikasi sendiri dan mengelola identitas mereka?" yang dilanjutkan dengan memberikan opsi lain seperti Masuk menggunakan akun Google/Apple/Mastodon/GitHub/Pornh

Ya, setiap layanan sekarang menjadi IdP dan bertanggung jawab dalam mengelola identitas penggunanya, di layanannya.

Mungkin kita berpikiran bahwa membuat sistem autentikasi sendiri lebih mudah daripada integrasi dengan IdP yang sudah ada mengingat harus memiliki access/secret token this and access/secret token that. Mungkin Passkeys akan merubah itu.

Selain itu, kadang kita mempertanyakan keberadaan terhadap IdP yang ada yang mungkin memiliki SLA yang sembilan lebih banyak dari kita (what if Google is down?), dan sekali lagi, mungkin Passkeys akan merubah itu.

Ini pertanyaan terakhir: What if Google/Microsoft/Apple get mad at us? Seperti, semua perangkat kita sampai terkunci karena sesuatu terjadi? Gue sampai hari ini belum kepikiran ketika gue ga bisa akses macbook gue misal karena Apple ID gue terkunci.

Tapi anyway, Passkeys tersimpan di TPM/Security enclave. Di level perangkat. Secara teori seharusnya tidak berhubungan, seperti, kita masih bisa unlock HP dengan Face ID sekalipun dalam mode pesawat.

Sebagai penutup, coba bayangkan dunia tanpa konsep kata sandi. Bayangkan pembayaran menggunakan QRIS tanpa harus mengingat kode PIN yang digunakan untuk rekening X. Bayangkan kasus pembobolan data pengguna.. yang itu jangan deng.

Passkeys ini teknologi yang relatif baru, mungkin akan luas diterapkan khususnya di Indonesia sekitar 1-2 tahun lagi. Akan terdapat tantangan-tantangan baru khususnya di ranah keamanan dan privasi.

Tapi sekali lagi, gue pribadi all-in dengan teknologi ini.

Dan berharap tidak mendapatkan pesan seperti "Gunakan OTP 869420 untuk login akun PeduliLindungiCiShani Anda. OTP akan kadaluarsa dalam waktu 2 menit. 4K3wxuQ69Zm" lagi setiap ini masuk ke layanan tertentu.

Ataupun ditanya kombinasi username + password yang digunakan pada platform tertentu yang mungkin hanya tuhan yang tahu.

Top comments (0)