Mengirim kode sekali pakai lewat email lebih buruk daripada kata sandi
(blog.danielh.cc)- Belakangan ini banyak layanan mengadopsi metode login dengan kode 6 digit berbasis email atau nomor telepon
- Setelah memasukkan email/nomor telepon, kode verifikasi 6 digit dikirim, lalu pengguna masuk dengan memasukkan kode tersebut
- Metode ini menimbulkan kerentanan serius pada keamanan akun
- Penyerang cukup memasukkan alamat email orang lain ke layanan yang sah untuk meminta pengiriman kode verifikasi
- Pengguna mengalami masalah karena sulit mengetahui apakah kode verifikasi yang diterima benar-benar untuk situasi yang semestinya atau merupakan upaya phishing
- Alat pencegahan phishing yang ada, seperti password manager (pengelola kata sandi), menjadi tidak efektif
- Metode kode verifikasi ini memang terus disalahgunakan dalam kasus nyata
- Metode serupa juga digunakan pada login akun Minecraft yang dioperasikan Microsoft
- Berbagai kasus pencurian akun telah dilaporkan di Reddit, YouTube, dan beragam komunitas online serta media lainnya
Kesimpulan
Metode verifikasi email dengan kode 6 digit secara keamanan merupakan cara yang lebih rentan daripada yang diperkirakan
- Dibandingkan metode kata sandi yang ada, risiko phishing justru meningkat tajam
- Meski diperkenalkan untuk meningkatkan pengalaman pengguna atau keamanan, metode ini sebenarnya dapat memicu hasil yang lebih buruk
3 komentar
Saya kurang merasa setuju; rasanya ini seperti trik yang hanya bekerja dalam situasi yang sangat spesifik.
Kalau pakai passkey lalu perangkatnya hilang, sepertinya bakal benar-benar merepotkan...
Komentar Hacker News
Pola serangannya seperti berikut
1) Pengguna mendaftar ke situs palsu
2) Situs itu lalu memberi tahu, “kode login dari situs GOOD sudah dikirim ke email Anda, silakan masukkan”
3) Situs palsu memulai alur “login dengan kode sekali pakai via email” di situs GOOD menggunakan email pengguna
4) Situs GOOD mengirim kode login ke pengguna lewat email
5) Pengguna percaya karena email itu datang dari GOOD, lalu memasukkan kodenya
6) Pengguna memasukkan kode itu ke situs palsu
7) Situs palsu memakai kode itu untuk login ke situs GOOD seolah-olah sebagai pengguna
Karena itulah metode autentikasi “mengirim kode sekali pakai lewat email” sangat rentan terhadap serangan phishing
Metode “klik tautan di email” sedikit lebih baik, karena pengguna akan langsung berpindah ke situs GOOD, dan menyalin/menempel tautan itu ke situs palsu terasa lebih merepotkan sekaligus mencurigakan
Namun, kalau layanan email populer tiba-tiba mulai memblokir email login atau tautan itu sendiri, banyak pengguna bisa jadi sama sekali tidak dapat login
Passkeys adalah pendekatan yang paling benar
Dukungan passkey di password manager makin lama makin baik
Bahkan jika seseorang kehilangan perangkat yang menyimpan passkey dan akhirnya kehilangan semua passkey, saya yakin itu tetap jauh lebih aman daripada sistem kata sandi lama
Menurut saya lebih baik nenek harus datang ke bank untuk memulihkan akses akun daripada uangnya habis dicuri lewat phishing
Masalah passkeys lebih rumit daripada sekadar “kalau perangkat hilang maka akses ikut hilang” (tergantung pengaturannya, ada solusi meski perangkat hilang)
Masalah terbesar adalah Attestation
Ini memungkinkan layanan memblokir orang yang memakai alat yang justru menambah kebebasan pengguna, misalnya solusi autentikasi open source
Passkeys atau protokol challenge-response pada awalnya bisa menjadi perbaikan besar yang benar-benar menggantikan kata sandi
Tapi kenyataannya, desainnya justru menguatkan dominasi Big Tech dan mengurangi kebebasan pengguna
Soal argumen “lebih baik nenek datang ke bank untuk pemulihan akun”
Coba pikirkan bagaimana kalau seseorang mengancam dengan senjata, memaksa akun dibuka, lalu menguras semua uangnya
Di negara dunia ketiga tempat saya tinggal, perampokan smartphone sangat parah sampai 2FA pun praktis tidak realistis
Saya pernah sekali memulihkan 2FA, dan rasanya seperti neraka
Dengan kata sandi, saya dulu cukup login ke Bitwarden dari mana saja dan beres
Saya mengatur passkey di github, dan memastikan itu tersimpan di Chrome
Saat mencoba login ke github dengan passkey, Chrome memunculkan pop-up yang meminta PIN Google Password Manager
Saya tidak tahu PIN itu apa, dan juga tidak bisa menemukan cara untuk meresetnya
Tidak ada penjelasan soal PIN itu di profil Google, password manager, maupun pengaturan keamanan
Menanggapi pendapat bahwa tidak masalah jika nenek harus datang ke bank untuk memulihkan akun
Saya mungkin bisa datang langsung ke bank atau helpdesk IT perusahaan untuk memulihkan akun,
tapi saya tidak bisa datang ke kantor pusat Google, Facebook, atau Xitter untuk melakukan hal yang sama
Passkey yang terikat ke perangkat sangat rentan menimbulkan kegagalan dalam situasi seperti ini
Kebanyakan pengguna tidak mempertimbangkan keadaan semacam itu
Passkeys saja tidak cukup
Intinya jangan mengulang kesalahan lama
Password manager harus jadi dasar, dan MFA khusus hanya dipakai pada kasus yang benar-benar pengecualian, seperti akun email atau rekening keuangan
Saya juga berpikir pengaturan MFA seharusnya mewajibkan setidaknya 3 metode, dan harus menggunakan 2 atau lebih di antaranya
Kalau hampir semua metode tidak didukung, seperti kode cetak, aplikasi autentikasi yang independen dari sistem operasi, atau hardware key seperti yubikey, menurut saya MFA itu tidak layak dipakai
Saya menerima email notifikasi permintaan reset kata sandi akun Microsoft empat kali sehari
Email itu berisi angka 6 digit, yang bisa dipakai untuk pemulihan akun
Artinya, penyerang dapat mencoba membajak akun saya empat kali sehari dengan peluang 1 banding 1.000.000 setiap kali
Jika ini dicoba ke ribuan akun, mereka bisa menembus sebagian akun secara gratis setiap hari
Saya bahkan sudah melaporkan ini sebagai laporan keamanan, tapi ditolak karena katanya pembuktian kelemahan secara matematis belum cukup
Satu-satunya pilihan yang tersisa adalah pasrah menerima spam sambil berharap akun saya tidak dibobol
Saya menyelesaikannya dengan menambahkan alias login
Saat login, email akun lama saya yang sudah publik diblokir, dan sekarang hanya bisa login dengan alias berupa string acak privat
Sejak itu tidak pernah ada lagi upaya login dari luar
[Cara setel: account.microsoft.com > Info Anda > preferensi masuk > tambah email > tambah alias lalu jadikan default > di preferensi masuk pilih hanya izinkan alias]
Saya juga mengalami hal yang sama
Mungkin ini efek sisa dari waktu saya harus memakai Microsoft Teams
Jika penyerang memakai cara ini terhadap 125.000 akun, mereka bisa berhasil mengenai satu akun per hari
Jika tidak menarget akun tertentu dan menyerang semua akun secara luas, efisiensinya lumayan bagus dibanding waktu yang dibutuhkan
Untuk mengatasi ini, batas tetap 4 kali percobaan harus diganti dengan exponential backoff yang menambah waktu tunggu setiap kali gagal
Saya juga terus menerima pesan serupa pada akun Instagram lama
“Kesulitan login? Klik di sini untuk mengganti kata sandi Anda!”
Hal yang sama juga terjadi pada akun lama yang tidak berguna
Saat saya cek alamat IP percobaan login itu, asalnya dari berbagai ISP di seluruh dunia, dan kebanyakan berada di jaringan /16 yang berbeda-beda
Kalau sampai akun “tidak berguna” seperti ini pun diserang memakai botnet, saya jadi khawatir betapa jauh lebih parahnya situasi bagi orang-orang yang benar-benar terekspos ancaman
Setelah menambahkan 2FA, masalahnya langsung selesai total
Saya masih tidak tahu bagaimana mereka pertama kali menemukan alur login yang memakai kode 6 digit ini (karena setiap kali saya hanya memasukkan kata sandi lalu langsung login)
Tapi setelah menambahkan 2FA, saya tidak pernah lagi melihat percobaan tambahan
Kode 2FA saya juga disimpan di password manager
Saya senang mereka tidak bisa lagi menyerang “kata sandi” 6 digit otomatis buatan Microsoft itu (bahkan bukan huruf, cuma angka!)
Yang paling buruk adalah skema autentikasi seperti ini membuat kebiasaan dan ekspektasi pengguna jadi lebih jelek
Kalau memakai password manager modern seperti 1password, itu jauh lebih mudah, aman, dan cepat dibanding model token email
Hanya perlu sedikit perhatian saat pengaturan awal dan verifikasi di beberapa perangkat
Sama seperti menggandakan kunci rumah setelah pindah ke tempat baru, menurut saya kita baru bisa tenang kalau sudah menyimpan di password manager dan memastikan sinkronisasinya berjalan di perangkat lain
Orang-orang sebenarnya mampu melakukan itu
Tanpa perlu paham enkripsi atau konsep 2FA, cukup klik “buat kata sandi baru” lalu gunakan kata sandi acak yang disimpan aplikasi
Hal yang sama berlaku untuk passkey, hanya saja penyimpanannya harus mempertimbangkan backup dan pemulihan, bukan cuma storage bawaan perangkat
Ironisnya, cara lama (memasukkan email dan kata sandi) justru bekerja lebih baik
Karena password manager langsung mengisi otomatis, praktiknya malah jauh lebih cepat
Passkey bahkan bisa lebih cepat lagi dari itu
Saya juga frustrasi, tetapi 80% orang di sekitar saya yang bukan pekerja IT benar-benar tidak paham soal keamanan dan seperti sudah menyerah
Satu-satunya contoh yang lumayan berhasil adalah menuliskan informasi akun di buku catatan kecil, lalu memastikan kata sandi setidaknya mengandung angka dan huruf
Saya paham masalah dalam alur ini
Dari pengalaman saya, metode kata sandi sekali pakai ini adalah bentuk autentikasi yang paling familier kedua bagi orang-orang non-IT di sekitar saya, setelah kata sandi biasa
Di kota kecil tempat saya tinggal, password manager atau passkey justru terasa lebih sulit, dan bahkan jika dijelaskan langsung di depan mata pun mereka tetap tidak akan paham
Model mentalnya terlalu asing, dan UX-nya terlalu rumit untuk dimengerti
Sampai muncul sesuatu yang bisa dipahami publik secara intuitif, saya rasa kata sandi dan model kode sekali pakai yang “bermasalah” ini akan tetap dominan karena kesederhanaannya
Bahkan jika Anda memakai kata sandi yang benar, cara pemulihan akun saat kata sandi “lupa” tetap memakai pola kode sekali pakai yang sama
Pada akhirnya, penyerang bisa bertindak seolah-olah “lupa” kata sandi dan masuk lewat alur pemulihan itu
Saya sendiri memakai login berbasis kode sekali pakai untuk layanan yang saya buat
Hanya saja itu bukan layanan sensitif, jadi tujuannya memang bukan autentikasi yang ketat
Saya bahkan menyebutnya ICGAFAS (“I Couldn't Give A Factor” Auth System), dengan sengaja menunjukkan bahwa saya memang tidak terlalu peduli soal keamanan
Autentikasi berbasis email juga menambah hal-hal yang harus diperhatikan dari sisi admin, seperti masalah pengiriman SMTP dan deliverability
Pada akhirnya, agar tidak masuk blacklist atau tersaring sebagai spam, kenyataannya kita harus memakai layanan relay pihak ketiga
Sangat menjengkelkan bahwa banyak layanan memaksa model kode sekali pakai ini alih-alih email+PW lama atau social login
Saya cuma ingin diizinkan memakai kata sandi 100 karakter saya
Anda bukan pengguna sasaran
Justru Anda termasuk minoritas yang sangat tidak umum
Dalam jangka panjang, kita perlu memikirkan solusi yang bisa terhubung dengan “mayoritas”
Menurut saya kata sandi panjang seperti 100 karakter tidak ada gunanya
Panjangnya akan dipotong sesuai key length yang benar-benar dipakai oleh kriptografi di bawahnya
Saya sempat memeriksa apakah model autentikasi ini benar-benar diizinkan secara resmi dalam dokumen NIST (NIST 800-63b section 5.1.2.1)
Jika dianggap sebagai “Look-up Secret Authenticator”, tampaknya tidak ada masalah khusus
Ini sebenarnya penyalahgunaan konsep yang awalnya dimaksudkan untuk kode autentikasi yang sudah dibagikan sebelumnya, seperti recovery code, menjadi kode yang dikirim real-time dan dipilih tunggal
Menurut saya metode ini memang lemah terhadap phishing, tetapi juga sulit untuk dengan tegas mengatakan bahwa ini lebih berbahaya daripada model username/password lama
Misalnya, jika pengguna diminta meminta kode 6 digit ke emailnya lalu memasukkannya, dia tidak bisa membedakan apakah kode itu untuk login yang sah atau yang palsu
Namun penyerang juga bisa menipu pengguna lewat halaman yang tampak meyakinkan, seperti akun Google palsu, untuk mencuri informasi
Pada akhirnya saya pikir hanya autentikasi yang tahan phishing yang benar-benar masa depan
Saya akhirnya harus menghapus akun gofundme karena hari ini tiba-tiba terjebak dalam siklus autentikasi seperti ini
Selama bertahun-tahun saya memakai akun itu dan juga berdonasi, tetapi sekarang mereka mewajibkan nomor ponsel dan kode MFA tanpa menyediakan opsi menolak
Akhirnya saya menjalani semua prosesnya lalu langsung menonaktifkan akun
Menurut saya autentikasi seperti ini tidak perlu dalam hidup, saya bisa hidup tanpa gofundme
Sekarang saya juga sedang mencari rumah, dan aplikasi Zillow juga sama saja: mewajibkan login, lalu meminta MFA setiap kali saya ingin membaca pesan yang masuk
Sesi berakhir hanya dalam satu jam
Saya benar-benar muak dengan model autentikasi seperti ini
Dunia ini benar-benar gila
Ticketmaster juga melakukan hal serupa
Nomor Google Voice tidak diterima, hanya nomor yang terhubung ke SIM yang diwajibkan
Nomor SIM saya sendiri hanyalah “detail implementasi” yang sering berubah, tetapi sekarang tanpa nomor itu saya tidak bisa login ke akun sama sekali
Akibatnya saya harus menyerah pada model pembelian tiket seperti ini, atau menerima risiko akun terkunci setiap kali ganti SIM
Google menyalakan 2FA di akun saya secara sepihak, dan karena nomor telepon yang terdaftar di akun itu adalah nomor lama, akun saya sekarang terkunci total
Ketika sebuah layanan mengubah kata sandi dan autentikasi sekunder tanpa peringatan apa pun, saat Anda sedang bepergian tanpa ponsel yang tertaut ke akun, akses bisa tertutup selamanya
Sebagian besar layanan menganggap autentikasi sekunder lebih aman daripada kata sandi acak 20 karakter saya yang disimpan di password manager lokal
Padahal metode autentikasi sekunder itu pada akhirnya cuma hal sepele seperti dikirim dalam teks biasa via SMS atau email
Saya membaca kalimat ini empat kali dan tetap tidak memahaminya
Penjelasannya kurang lebih seperti, “jika penyerang mengirim alamat email pengguna ke layanan sah dan meminta kode 6 digit, pengguna itu sendiri tidak tahu apakah kode tersebut benar-benar untuk login yang sah”