Pola “Email adalah autentikasi”

• Sebagian pengguna, alih-alih mengingat atau mengelola kata sandi, menggunakan prosedur “lupa kata sandi” setiap kali seolah itu adalah cara login
• Alur nyatanya adalah menerima tautan pemulihan lewat email dari halaman login, memasukkan kata sandi sementara, lalu mengulangi proses yang sama pada kunjungan berikutnya
• Kebiasaan ini lebih dekat dengan perilaku yang dipelajari dan mengakar seiring waktu, bukan strategi keamanan yang disadari
• Perbaikan seperti pengelola kata sandi dan autentikasi dua langkah·multi-faktor juga bisa terasa bagi pengguna sebagai peningkatan friksi, bukan penguatan keamanan
• Desain sistem perlu berangkat dari asumsi perilaku berulang pengguna, dan mengarahkan mereka agar secara alami berpindah ke cara penggunaan yang lebih baik

---

Pemulihan kata sandi yang dipakai seperti login

• Sebagian pengguna tidak memasukkan kata sandi saat login ke akun online mereka, dan malah mengulangi prosedur pemulihan setiap saat
  • Tiba di halaman login
  • Mengklik “I forgot my password”
  • Berpindah ke email
  • Mengklik tautan pemulihan
  • Memasukkan kata sandi sementara yang tidak akan diingat
  • Lalu mengulangi proses yang sama
• Ketika ditanya mengapa mereka melakukannya, mereka tidak bisa menjawab atau bereaksi seolah belum pernah memikirkan alasannya
• Perilaku ini bukan strategi login yang diputuskan di pagi hari, melainkan lebih mirip prosedur berulang yang mengeras seiring waktu

Friksi yang diciptakan peningkatan keamanan bagi pengguna

• Cara ini berfungsi sebagai solusi berupaya rendah karena pengguna tidak perlu mengingat frasa sandi
• Pengelola kata sandi, pencurian identitas, autentikasi dua langkah dan multi-faktor, serta menuanya metode nama pengguna/kata sandi sudah lama menjadi topik yang banyak dibahas
• Prosedur keamanan yang lebih baik sering kali menambah hambatan dan friksi, sehingga sulit diterima pengguna secara alami
• Perancang harus mempertimbangkan perilaku yang dipelajari pengguna, lalu membuat alur yang memungkinkan perpindahan ke cara penggunaan yang lebih baik seiring waktu

[GN⁺]

Komentar di Hacker News

• Akun email adalah penyebut umum yang paling universal dalam autentikasi online. Ponsel juga kompetitif, tetapi bisa hilang; nomor telepon memang lebih umum dan tahan lama, tetapi tingkat keamanannya jauh lebih rendah dibanding akun di penyedia email utama.
  Jika ingin merancang “sistem autentikasi imajiner untuk internet”, hal pertama yang harus dilihat adalah pemulihan akun. Saat autentikator keren hilang, jika jawabannya adalah “ya sudah, tidak bisa mengakses” atau “panel rekan menjamin identitas”, maka sistem itu hanya akan bekerja jika penggunanya bukan manusia, melainkan makhluk cerdas imajiner.

  • Ini adalah alasan terbesar saya menentang blockchain/cryptocurrency selama bertahun-tahun. Model “kalau kunci hilang, dompet juga hilang” pada dasarnya tidak cocok dengan pengguna nyata.
    Manusia harus bisa pulih dari kesalahan.
  • Identitas digital yang diterbitkan pemerintah bisa menyelesaikan banyak bagian dari masalah ini. Tentu ada masalahnya sendiri, tetapi menyerahkan identifikasi individu kepada pemerintah tampaknya lebih bernilai dan lebih tidak berisiko dibanding penguncian akun oleh perusahaan seperti Google.
  • Sayangnya, bahkan di penyedia email besar seperti Google, pola “ya sudah, tidak bisa mengakses” juga umum terjadi. Orang-orang yang kehilangan ponsel atau ponselnya dicuri lalu terkunci permanen dari akun mereka menunjukkan hal ini dengan jelas.
  • Bahkan untuk “akun email penyedia utama” ada catatan: “akun ditangguhkan tanpa alasan, tidak ada cara mengajukan keberatan, dan mereka tidak memberi tahu mengapa akun ditangguhkan.”
  • Pendekatan panel rekan yang menjamin identitas seseorang adalah masalah desain yang menarik. Jika ada sistem umum yang bisa menggabungkan kembali rahasia autentikasi yang terdistribusi dengan tepat sesuai instruksi pihak terkait, ini bisa dibuat cukup mulus.
    Bisakah dibuat agar bekerja untuk manusia biasa juga? Saya rasa ada cukup kreativitas untuk merancangnya.

• Layanan kami adalah bisnis yang sifatnya cukup ringan, jadi pengguna hanya memakai akun demi kenyamanan. Pendekatan yang akhirnya kami pakai seperti ini: pengguna memasukkan email, kami mengirim kode verifikasi lewat email, lalu saat pengguna memasukkan kode, kami menerbitkan cookie yang sangat panjang sehingga mereka praktis login tanpa batas waktu.
  Tidak penting apakah akun sudah ada; jika email baru, cukup buat akun baru. Kadang pengguna yang punya beberapa email tidak sengaja membuat akun baru, tetapi konversi pendaftaran dan login meningkat besar, jadi masih layak diterima. Masa berlaku kode dan jumlah percobaan perlu analisis risiko, dan sebaiknya memakai mekanisme penguncian jika memungkinkan. Kalau layanan Anda tidak terlalu penting, saya merekomendasikan strategi ini. iOS Mail sekarang juga mendukung pola seperti ini, mirip fitur kode sekali pakai di Messages, jadi untuk sebagian pengguna cukup nyaman.

  • Berdasarkan data yang pernah saya lihat, pendekatan ini luar biasa bagus untuk memaksimalkan pendapatan e-commerce.
    Jangan memaksa pembeli membuat akun; cukup minta detail yang dibutuhkan. Toh browser akan mengisi otomatis. Setelah itu kirim tautan untuk mengecek status pesanan lewat email, lalu pada pesanan berikutnya minta email lagi. Gesekan tambahan menyebabkan kehilangan pendapatan yang lebih besar daripada manfaat mendapatkan “pengguna terdaftar”.
  • Saya menjalankan aplikasi B2C kecil; pengguna mendaftar hanya dengan alamat email dan tidak ada field kata sandi sama sekali. Akun dibuat dan di perangkat tersebut mereka login tanpa batas waktu.
    Kata sandi baru hanya bisa diminta saat mereka perlu login dari perangkat lain. Ini mengurangi friksi pendaftaran dan kata sandi yang lemah. Kebanyakan pengguna toh hampir tidak pernah perlu login dari perangkat lain.
  • Saya sudah beberapa kali mengimplementasikan cara login seperti ini, dan pendekatan ini muncul dari pengalaman harus membuang banyak asumsi tentang apa itu “akun pengguna”. Agar funnel benar-benar berjalan sesuai keinginan kedua pihak, penyederhanaan seperti ini diperlukan.
    Jika bukan area yang harus menjaga anonimitas, cara ini boleh saja dilakukan, lalu passkey bisa diintegrasikan belakangan. Kekurangannya, berbagi kata sandi menjadi tidak mungkin, sehingga masalah mengelola beberapa pengguna dalam satu akun harus dipikirkan lebih awal. Namun jika ditangani secara sadar, funnel maupun pengalaman pengguna pada akhirnya membaik. Selain itu, keamanan memang terikat pada rata-rata tingkat keamanan penyedia email pengguna, tetapi biasanya itu lebih baik daripada tingkat yang dibutuhkan. Kata sandi bisa digunakan nanti sebagai faktor kedua saat diperlukan, atau faktor lain bisa ditambahkan; untuk B2B bisa langsung memakai SAML atau OIDC. Di B2B maupun D2C, ini selalu bekerja dengan baik, dan kasus pengecualian layak diselesaikan karena manfaat akuisisinya.
  • Saya pernah melihat metode login seperti ini; bukankah bisa mengirim tautan lewat email yang mengarahkan ke beranda aplikasi dalam keadaan sudah login?
    Menyalin kode, mencari tab tempat halaman login terbuka, lalu menempelkannya itu merepotkan.
  • Saya memakai pendekatan ini di aplikasi CRUD kecil yang hampir hanya satu form, dan selama periode kampanye permintaan dukungan hampir mendekati nol, jadi jelas layak.

• Pada titik ini, bukankah cukup mengirim tautan URL sekali pakai ke alamat email dan membuat pengguna login dengan sekali klik? Buat agar kedaluwarsa dalam 10 menit dan dibuang setelah sekali pakai.
  Tentu saja siapa pun yang memegang tautan pertama bisa login ke akun tersebut, tetapi toh aksesnya hanya dari email. Rasa keamanan di luar akun email memang hilang semua, tetapi kenyataannya kita sudah sampai di titik itu. Jika memakai pola seperti “klik untuk verifikasi login: www.someurl.com?p=134234535” lewat pesan ponsel, itu menjadi autentikasi dua faktor tanpa harus memasukkan kode dengan bodoh.

  • Beberapa webapp memakai pendekatan ini, tetapi ini membingungkan pengguna (“kenapa saya sudah punya akun? Saya tidak pernah daftar!”), ada biaya (mengirim email tidak gratis), dan juga lambat.
    Email bisa masuk spam, atau pengguna tidak bisa login selama berjam-jam karena greylisting, atau butuh 1 menit untuk tiba dan bahkan itu terasa terlalu lama. Saya tidak yakin akan merekomendasikannya.
  • Saya sangat tidak suka situs yang hanya menyediakan cara seperti ini tetapi tidak bisa mengirim email dalam 30 detik.
    Untuk “klik untuk verifikasi login” yang dikirim ke ponsel, harus diberikan kode dan tautan sekaligus. Perangkat yang dipakai login tidak selalu ponsel, jadi harus berupa “masukkan 1234 atau klik”.
  • Beberapa situs seperti Netdata melakukan itu.
    Tetapi lebih lambat daripada pengelola kata sandi yang mengisi otomatis kombinasi username/kata sandi, karena harus menunggu email lalu menekan tautan.
  • Saya sedang membuat webapp dengan alur login persis seperti ini, dan ada masalah di mobile. Aplikasi seperti Gmail tidak mengizinkan menyalin tautan ke browser tanpa pratinjau, dan pratinjau itu menghabiskan tautannya (next.js auth).
    Saya tidak ingin login di browser dalam aplikasi Gmail, melainkan di browser biasa, dan ini cukup menjengkelkan.
  • Kalau begitu, lebih baik sekalian pakai single sign-on sampai tuntas. 95% pengguna toh akan memakai salah satu dari Gmail, Outlook, atau Apple.
    Tombol “Login dengan Google” lebih baik daripada “kirim tautan lewat email”, dan pelacakan tetap bisa dilakukan dengan cara mana pun.

• Gagasan bahwa orang akan membuat dan mengingat kata sandi untuk setiap layanan remeh itu tidak realistis. Membuat satu lagi sistem autentikasi berbasis kata sandi lebih mirip semacam permainan peran
  Kata sandi biasanya dipakai dengan salah satu dari dua cara: pengelola kata sandi yang dilindungi oleh satu kata sandi asli, atau kata sandi yang sama yang diulang di tiap layanan. Karena hampir semua layanan menyediakan pemulihan lewat email, pada praktiknya emaillah sarana autentikasi. Email pribadi jarang diganti, tidak dibagikan, dan tidak dipakai ulang. Kemungkinan besar Anda sudah memakai email pribadi lebih lama daripada nomor telepon. Selama memakai alamat email saat ini, nomor telepon saya sudah berganti setidaknya lima kali, dan nomor-nomor itu sekarang dipakai orang lain

  • Ada juga kata sandi turunan, semacam bentuk campuran. Bisa berupa pola yang diingat orang, atau alat pengelola yang menghitungnya per domain
    Dan fitur lupa kata sandi setidaknya memberi tahu pemilik alamat tentang semua percobaan. Login berbasis kata sandi tidak selalu mengirim email setiap kali ada login dari lokasi baru
  • Apple membuat proses “tidak bisa sekadar memasukkan kata sandi 1Password/Keychain, harus direpotkan lewat email” menjadi jauh lebih baik. Setidaknya ketika ia mengenali email atau SMS dan mengisikan kode untuk Anda

• Jawabannya sederhana. Biasanya terkait dengan ketidaknyamanan yang sengaja dibuat penyedia layanan bagi pengguna. Dalam kasus ini terlihat jelas: sesi penyedia email biasanya pada dasarnya tidak pernah berakhir dan tetap login selama cache browser tidak dibersihkan
  Buat saja token autentikasi layanan sendiri dengan masa hidup yang sama seperti Gmail, dan sebagai alternatif izinkan login setiap kali dengan kata sandi sekali pakai. Namun praktik tidak masuk akal seperti token autentikasi 12 jam harus dihentikan. Dengan begitu pengguna tidak akan pernah lagi login lewat pemulihan kata sandi

  • Alasan sebenarnya mungkin karena situs-situs web itu memang tidak bekerja dengan benar
    Dulu saya pernah bermasalah dengan akun Epic dan Spotify. Setelah membuat akun dan memakainya seminggu, sesi kedaluwarsa dan Spotify mengeluarkan saya dari akun. Saat mencoba login, katanya kata sandi salah, padahal itu mustahil karena tersimpan di pengelola kata sandi. Pada akhirnya tidak ada pilihan selain mereset lewat email. Beberapa kali pertama, setelah menerima email dan mereset, pola yang sama terulang; setelah 3–4 kali, emailnya pun tidak datang sehingga harus membuat akun baru. Sekarang saya login ke Spotify dengan akun Google dan sejauh ini tidak ada masalah. Namun jika memakai email biasa, sistem autentikasi mereka memang tidak berfungsi
  • Saya rasa ini petunjuk yang lebih dekat dengan kebenaran. Gmail, Cloudflare, dan banyak “organisasi berkeamanan tinggi” lain memiliki sesi autentikasi yang sangat panjang. Alasannya, kemungkinan seseorang mengakses PC pengguna sistem seperti ini saat pengguna belum logout sebenarnya sangat rendah. Sebagian besar peretasan dilakukan dari jarak jauh dengan menargetkan kata sandi yang lemah
    Masalahnya adalah kita kekurangan bahasa yang konsisten untuk mengukur risiko dan menilai “apakah situs ini benar-benar membutuhkan autentikasi dua faktor?” atau “apakah durasi sesi 30 menit masuk akal?”. Jika memiliki antivirus terbaru, kebanyakan orang mungkin ingin tetap login. Pernah diminta menghapus semua cookie untuk memperbaiki masalah suatu situs? Jawaban saya selalu menolak. Saya pernah mendengar, “Akun itu milik Anda, dan jika Anda ingin tetap login serta menanggung risiko diretas, itu risiko Anda, bukan operator layanan,” dan saya makin setuju. Jika seseorang menghapus semua instans EC2 ketika laptop Anda masih login, itu salah Anda, bukan salah AWS karena tidak mengeluarkan Anda lebih cepat. AWS bisa saja melakukannya, tetapi mengapa harus begitu? Tidak ada alasan membuat satu juta orang kesal demi melindungi satu orang yang ceroboh
  • Benar. Saya sudah lelah platform bersikap seperti pengasuh dengan batasan sesi dan autentikasi dua faktor paksa. Cukup sediakan toggle di pengaturan

• Saya pernah melihat situs yang menghapus langkah lupa kata sandi, atau menghapus kata sandi itu sendiri. Email adalah autentikasi
  Caranya: masukkan alamat email, terima email berisi kode, lalu masukkan kode untuk login. Saya paham mengapa begini, tetapi sebagai orang yang memakai beberapa email, saya cukup tidak suka. Saya harus memasukkan email dan catatan ke pengelola kata sandi untuk mengingat email mana yang harus dipakai, dan itu tersisa seperti entri tanpa kata sandi

  • Karena friksi memakai magic link terlalu besar, saya pernah tidak jadi membelanjakan uang di situs seperti itu dan mencari alternatif
    Kalau mereka tidak bisa membuat sistem login yang layak, kemungkinan besar mereka juga kurang mampu menyediakan fitur yang dijanjikan. Magic link kini bukan sekadar gangguan, melainkan sudah menjadi filter
  • Di SaaS B2B kami memakai cara ini. Pengguna individual mungkin login hanya sekali atau dua kali dalam 6 bulan, jadi login tanpa kata sandi menguntungkan
    Tidak ada beban untuk mengingat kata sandi layanan yang jarang dipakai, dan onboarding perusahaan juga lebih mudah. Saat perusahaan mengunggah CSV pengguna, para pengguna bisa langsung mulai bekerja tanpa proses membuat kata sandi, mengonfirmasi, dan memenuhi aturan. Saya tidak menyukai tautan email, karena pratinjau aplikasi ponsel atau pemindai antivirus korporat bisa “mengklik” tautan tersebut
  • Sebagian besar konsumen nonteknis tidak akan memakai pengelola kata sandi. Jika hanya menyediakan pendaftaran dengan kata sandi tanpa magic link atau kode, berarti membuat hidup mayoritas konsumen lebih sulit
    Bahkan jika keduanya disediakan, kalau meminta kata sandi sekaligus verifikasi email, sepertinya lebih banyak orang akan keluar dari alur pendaftaran. Selain itu, kodenya juga jauh lebih sederhana karena tidak perlu menangani kata sandi dan berbagai alur login email
  • Situs “login tamu” untuk menukarkan voucher menyediakan cara ini, dan menurut saya itu kasus penggunaan yang valid bagi orang yang mungkin tidak ingin membuat akun
    Karena voucher harus ditautkan dengan email, kepemilikan perlu dikonfirmasi lewat klik tautan untuk berjaga-jaga jika nanti ada masalah dukungan akibat voucher hilang. Jika setelah itu membuat akun, voucher yang diterima sebelumnya juga bisa dilihat
  • Artinya situs tidak menyimpan kata sandi saya, jadi hal yang perlu dikhawatirkan berkurang

• Baru setelah membaca tulisan ini saya menyadari bahwa saya memakai persis cara ini di Best Buy
  Bukan disengaja. Kata sandi saya tersimpan di 1Password, jadi saya tahu itu benar, tetapi setiap kali saya mencoba membeli sesuatu di bestbuy.com, ada semacam pencegahan pengambilalihan akun yang aktif dan berbohong bahwa kata sandinya salah. Saya cukup percaya bahwa bisa saja masalahnya ada di sisi saya. Mungkin pemblokir iklan atau pemblokiran DNS lokal. Namun setelah terjadi beberapa kali, keinginan untuk men-debug hilang dan saya tinggal mengikuti jalur dengan hambatan paling kecil

  • Jangan-jangan ini ketidakcocokan panjang maksimum? Sangat umum jika field ubah kata sandi dan halaman login punya maxlength yang berbeda
    Misalnya saat mengganti kata sandi Anda memasukkan kata sandi 60 karakter, tetapi panjang maksimum di halaman login 40 karakter, maka saat login akan menjadi “kata sandi salah”. Jadi sekarang saya menerapkan kebijakan menyimpan panjang maksimum di konfigurasi aplikasi agar disebarkan ke semua field kata sandi. Setelah dicek, ternyata memang ada ketidakcocokan panjang. Form pengaturan kata sandi punya maxlength 54, tetapi halaman login tidak punya maxlength. Jadi jika kata sandinya lebih dari 54 karakter dan 1Password tidak otomatis memangkas kata sandi tersimpan menjadi 54 karakter atau kurang, Anda tidak bisa login

• Bagi kebanyakan orang, bekerja dengan komputer adalah soal mencoba berulang-ulang secara membabi buta sampai kira-kira berhasil. Perangkat lunak dibuat oleh orang-orang yang memahami sistem di lapisan bawah secara terperinci, tetapi dibuat untuk orang-orang yang tidak punya pemahaman seperti itu
  Begitu pengguna menemukan pola yang berhasil sekali, mereka akan bertahan di sana. Kini banyak sekolah memakai tablet untuk pendidikan, sehingga kecenderungan ini makin besar. Mereka tidak benar-benar punya intuisi tentang cara kerja komputer. Kebanyakan tidak memikirkannya secara mendalam. Itu ada begitu saja, dan karena mereka sudah terbiasa dengan sesuatu yang memang rusak dari awal, apa susahnya melakukan beberapa klik tambahan

  • Di antara pengembang perangkat lunak, mungkin hanya sekitar 10% yang benar-benar memahami secara mendalam apa yang mereka kerjakan. Justru karena para pengembang tidak memahami dengan benar apa yang mereka lakukan, orang biasa terpaksa memakai perangkat lunak yang buruk dengan cara mencoba-coba berulang kali

• Kalau dilebih-lebihkan, alur login itu sama saja
  A) Buka situs web, salin-tempel string acak lewat pengelola kata sandi, lalu terima permintaan TOTP lewat email untuk verifikasi identitas. Atau B) buka situs web, tekan lupa kata sandi, terima tautan login, lalu masukkan string acak. Dalam banyak kasus B sebenarnya lebih cepat, dan hampir tidak pernah jauh lebih lambat. Kotak centang “ingat saya” tidak ada efeknya

  • Siapa yang menyalin-tempel dari pengelola kata sandi?
    Menurut saya alur saya lebih baik daripada keduanya. Saat membuka situs, Safari menawarkan autofill, saya memakai TouchID/FaceID, lalu diminta kode tahap kedua. Jika datang lewat SMS atau email, Safari menawarkan autofill. Bahkan untuk TOTP, Safari juga mengisi otomatis. Sangat mudah. Passkey lebih mudah lagi karena tidak ada tahap kedua dan tidak perlu menunggu SMS/email
  • TOTP bukan sesuatu yang sifatnya dikirim lewat email. Inti TOTP adalah Anda dapat membuat kode autentikasi sendiri dari waktu saat ini dan secret yang sudah dibagikan sebelumnya
  • Jika ada greylisting, alur B bisa memakan waktu sekitar 10 menit
  • Metode B bisa dilakukan di mana saja selama Anda bisa mengakses email, dan tidak bergantung pada apakah aplikasi atau ponsel ada di tangan Anda
  • Bukankah browser mengingat kata sandi?

• Motivasinya langsung bisa dipahami. Jika memakai “lupa kata sandi”, Anda tidak perlu mengingat kata sandi. Dan keamanan akun juga tidak menjadi lebih lemah. Karena jalur itu toh sudah terbuka bagi penyerang
  Sebagian situs web menjadikannya alur default, dan secara implisit berargumen bahwa jika mereka bisa mengirim tombol login kepada seseorang lewat email, maka kata sandi itu sendiri tidak bermakna. Secara pribadi saya tidak suka. Saya tidak mempercayai email, dan saya juga tidak suka email menjadi single point of failure untuk puluhan akun. Jika Anda bisa login hanya dengan faktor kedua, itu bukan autentikasi dua faktor. Saya ingin login dengan kata sandi tanpa opsi reset, tetapi kenyataannya tidak begitu

  • Jika email dilindungi dengan autentikasi dua faktor, maka itu kembali menjadi autentikasi dua faktor