Cacat Microsoft Authenticator menimpa akun MFA, membuat pengguna terkunci

• Di tengah meningkatnya penggunaan MFA, Microsoft Authenticator dapat menimpa akun lama karena akun TOTP baru yang ditambahkan lewat kode QR, sehingga pengguna bisa terkunci
• Inti konflik ada pada desain yang hanya memakai label untuk membedakan akun, tidak seperti Google Authenticator, Okta, dan lainnya yang menggunakan issuer dan label bersama-sama
• Karena penimpaan tidak langsung terlihat, pengguna mungkin baru mengalami tidak bisa mengakses saat mencoba masuk ke akun lama beberapa minggu atau bulan kemudian
• Solusi sementara adalah memakai aplikasi autentikasi lain atau memasukkan Secret Key secara manual, tetapi ini kurang praktis bagi pengguna umum di lingkungan perusahaan
• Microsoft menyatakan ini adalah perilaku yang disengaja dan menyediakan pesan peringatan, lalu belakangan menyebut sebagian issuer tidak disertakan oleh penerbit dan hanya menyisakan kemungkinan perbaikan di masa depan

---

Cara pemindaian QR menimpa akun MFA yang sudah ada

• Microsoft Authenticator dapat menimpa akun yang sudah ada dengan nama pengguna yang sama saat menambahkan akun baru melalui pemindaian QR
• Karena nama pengguna sering berupa alamat email, situasi di mana akun MFA dari beberapa layanan berbagi label yang sama cukup umum terjadi
• Google Authenticator dan sebagian besar aplikasi autentikasi lain memakai nama issuer seperti bank atau perusahaan otomotif untuk menghindari benturan
• Microsoft Authenticator tidak memakai issuer bersama-sama dan mengidentifikasi akun hanya berdasarkan nama pengguna
• Setelah penimpaan terjadi, masalah autentikasi dapat muncul baik pada akun baru yang dibuat maupun akun lama yang tertimpa

Sulitnya menyadari lockout yang penyebabnya tidak jelas

• Saat lockout terjadi, pengguna bisa salah mengira bahwa masalahnya ada pada perusahaan penyedia autentikasi, bukan pada Microsoft Authenticator
• Akibatnya, helpdesk perusahaan menghabiskan waktu untuk menangani situasi yang bukan disebabkan oleh sistem mereka sendiri
• Sulit untuk dengan mudah memastikan akun mana yang telah tertimpa
• Fakta bahwa akun lama hilang mungkin tidak akan terlihat sampai pengguna mencoba memakai akun itu lagi
  • Momen ini bisa terjadi beberapa minggu atau beberapa bulan kemudian

Solusi sementara dan keluhan lama

• Solusi sementara paling mudah adalah memakai aplikasi autentikasi lain alih-alih Microsoft Authenticator
• Masalah ini bisa dihindari dengan memasukkan Secret Key secara manual tanpa memakai pemindaian kode QR
• Pada akun autentikasi yang termasuk dalam akun Microsoft, masalah ini tampaknya tidak muncul
• CSO Online menemukan keluhan tentang masalah ini sejak 2020, dan masalahnya sendiri tampaknya sudah ada sejak Microsoft Authenticator dirilis pada Juni 2016
• Pada 2020, seorang pengguna menyebut solusi sementara dengan memasukkan Secret Key dari Identity Provider secara manual, tetapi menilai pendekatan menangani string acak seperti itu tidak membantu bagi rata-rata pengguna akhir di lingkungan perusahaan

Penimpaan yang direproduksi di lapangan

• Konsultan TI Australia Brett Randall mengalami situasi dalam sesi pelatihan vendor ketika peserta memindai kode QR MFA dengan Microsoft Authenticator lalu menimpa kunci TOTP milik aplikasi lain
• Menurut Randall, kode QR MFA membentuk string yang berisi beberapa nilai, dan aplikasi lain menggabungkan label dan issuer untuk membuat ID unik bagi kunci tersebut
• Alih-alih mengikuti perilaku standar ini, Microsoft Authenticator hanya memakai label, dan label itu biasanya adalah alamat email
• Kunci TOTP terakhir yang memakai alamat email yang sama dapat tertimpa oleh kunci baru
• Randall menggambarkan bahwa hampir mustahil membuat Microsoft menyadari masalah ini dan mengambil tindakan

Respons para pakar keamanan dan TI

• CSO Online meminta beberapa pakar keamanan dan TI untuk mereproduksi masalah ini, dan semuanya berhasil melakukannya
• Fractional CTO IllumineX, Gary Longsine, menganggap ini sebagai cacat desain dan mengatakan ia tidak akan merekomendasikan Microsoft Authenticator
• VP produk Wallarm Tim Erlin mengatakan bahwa benturan terjadi ketika menambahkan entri kedua yang memakai alamat email yang sama, dan setelah tertimpa, tidak ada cara mengetahui akun mana yang telah ditimpa
• Erlin menyebut kemungkinan masalah ini kurang dikenal daripada kenyataannya karena pengguna mungkin tidak mengetahui penyebabnya
• Chief product officer Netography David Meltzer menilai ini sebagai bug yang jelas setelah mereproduksinya sendiri, dan menurutnya ini masalah yang relatif sederhana untuk diperbaiki Microsoft
• Juru bicara Google Kimberly Samra mengatakan Google Authenticator tidak menimpa kode, dan itu adalah keputusan yang disengaja

Posisi Microsoft dan teks peringatan

• Microsoft mengonfirmasi masalah ini, tetapi menyatakan bahwa itu bukan bug melainkan perilaku yang disengaja
• Dalam pernyataan tertulis pertama, Microsoft menjelaskan bahwa saat pengguna memindai kode QR, mereka menerima pesan konfirmasi sebelum tindakan yang dapat menimpa pengaturan akun
• Teks peringatan sebenarnya adalah “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
• Pesan ini mengarahkan pengguna untuk melanjutkan jika tindakan tersebut memang dimulai sendiri dan berasal dari sumber tepercaya
  • Jika pengguna sendiri memulai pemindaian QR dari layanan normal seperti bank atau hotel, kedua syarat itu dalam banyak kasus terpenuhi
  • Jika mengikuti instruksi itu, penimpaan akun dapat terjadi
• Jendela peringatan tidak memberikan cara untuk menghindari penimpaan selain membatalkan upaya autentikasi

Saling lempar tanggung jawab soal issuer yang hilang

• Dalam pernyataan kedua yang lebih panjang, Microsoft kemudian menjelaskan bahwa beberapa situs atau vendor tidak menyertakan issuer dalam label, yaitu nama situs atau nama Identity Provider
• Jika sudah ada akun lama dengan label yang sama, aplikasi dapat mencoba menimpa akun lama itu dengan akun TOTP yang baru dipindai
• Microsoft menyatakan bahwa dalam situasi seperti ini pengguna selalu menerima pesan konfirmasi penimpaan dan dapat memilih apakah akan melanjutkan
• Kalimat “kami terus melakukan peningkatan produk dan akan mempertimbangkan hal ini untuk perbaikan di masa mendatang” adalah satu-satunya bagian yang mengisyaratkan kemungkinan Microsoft akan memperbaiki masalah ini

Perbandingan dengan aplikasi autentikasi lain

• Randall menilai ada dua cara untuk mencegah pengguna akhir tidak sengaja menimpa kunci milik aplikasi lain
  • Mengaudit otpauth semua aplikasi dan meyakinkan tiap perusahaan untuk memperbaiki implementasi yang salah
  • Microsoft memperbaikinya sekali sehingga setelah itu tidak perlu lagi mengkhawatirkan hal yang sama
• Randall mengatakan ia menguji perilaku benturan yang sama pada 14 aplikasi autentikasi lain, tetapi tidak menemukan perilaku seperti Microsoft Authenticator
• Aplikasi yang diuji mencakup Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth, dan Authenticator 2FA Sentinel

[GN⁺]

Opini Hacker News

• Ini benar-benar terasa sebagai contoh kecil yang menunjukkan masalah besar dari keamanan tanpa kegunaan
  Coba pikirkan berbagai hal tidak masuk akal yang kita alami atas nama “keamanan”. Perubahan kata sandi berkala yang dipaksakan, aturan kata sandi yang gila, persyaratan tak terdokumentasi yang harus ditemukan lewat coba-coba, pesan kesalahan rumit penuh jargon keamanan, “pertanyaan rahasia” yang jawabannya tidak kita ingat, dan semacamnya
  Namun keamanan sistem-sistem itu sendiri justru bolong-bolong seperti saringan. Kebocoran data dan tereksposnya informasi hampir setiap hari masuk berita, dan sering kali saya bertanya-tanya bagaimana semua ini terus dibiarkan berlalu

  • Capital One suatu saat memperkenalkan “nama pengguna” dan merusak login dengan alamat email, tetapi tidak mendokumentasikannya dan juga tidak mencegah alamat email dipakai sebagai nama pengguna
    Selama berbulan-bulan, setiap kali login saya harus memakai “temukan akun saya”, dan setiap kali saya menyetel kembali nama pengguna menjadi alamat email. Wajar saja, karena selama hampir 10 tahun itulah kredensial login saya
    Batasan bahwa nama pengguna tidak boleh memakai @ atau . sama sekali tidak pernah ditegakkan sampai saat login, dan akhirnya baru setelah beberapa bulan saya tahu bahwa saya harus menggantinya dengan nilai lain
    Akun aslinya adalah ING Direct, lalu menjadi Capital One 360, kemudian sepenuhnya digabungkan ke dalam kekacauan Capital One lainnya, dan saya rasa masalah nama pengguna ini juga berkaitan dengan itu
  • Kemarin saya mengalami contoh yang bagus
    Situs web: “Pilih kata sandi kompleks minimal 8 karakter, termasuk karakter khusus dan angka”
    Saya membuka pengelola kata sandi dan dengan bangga membuat kata sandi acak 128 karakter
    Pada kunjungan berikutnya, situs web: “Masukkan karakter ke-31, ke-98, dan ke-102 dari kata sandi Anda”
    Itu situs KPR di Inggris
    Setelah dipikir-pikir, agar bisa melakukan ini berarti mereka menyimpan kata sandi dalam teks polos, atau setidaknya menyimpannya dengan enkripsi yang bisa didekripsi kapan saja, bukan hash
  • Pola yang paling saya benci adalah saat saya tahu punya akun di situs web yang sudah lama tidak dipakai, lalu masuk dan mengetik kata sandi yang benar, dibuat secara algoritmik dari email dan URL situs, tetapi gagal
    Saya mencoba lagi karena mengira mungkin itu kata sandi dari algoritma versi lama, tetapi tetap gagal. Akhirnya saya menekan reset kata sandi, menerima email, mengeklik tautan, lalu memasukkan kata sandi yang dibuat algoritmik sebagai kata sandi baru, dan muncul “karakter khusus itu tidak boleh digunakan”
    Ketika, sesuai aturan saya, saya mengganti karakter khusus itu dengan karakter berikutnya, kali ini muncul “tidak dapat mereset ke kata sandi saat ini”
  • Sejauh ini yang terburuk yang pernah saya lihat adalah https://studentaid.gov/. Saya tidak ingin memasukkan informasi palsu, dan juga tidak bisa membuat duplikat akun hanya untuk memeriksa ulang persyaratannya
    Seingat saya ada “kata dilarang”, “tidak boleh menggunakan kembali 24 kata sandi terakhir”, “beberapa karakter khusus dikecualikan”, “5 pertanyaan keamanan”, dan berbagai persyaratan kata sandi lainnya
    Tidak ada yang tahu apakah pertanyaan keamanan peka huruf besar-kecil
    Bahkan ada pernyataan bahwa informasi pembuatan akun harus benar dan memang milik diri sendiri, serta jika memberikan informasi palsu atau menyesatkan, Anda dapat dikenai denda, hukuman penjara, atau keduanya
  • Kabar baiknya, hal-hal yang disebutkan itu dikenal sebagai ide buruk baik oleh pengguna akhir maupun orang yang memahami keamanan. Sayangnya, kebanyakan orang yang mengimplementasikan kebijakan keamanan tidak termasuk keduanya
    Dengan memakai 4 kata kamus atau lebih, Anda bisa mendapatkan keamanan kata sandi yang sangat baik, dan pendekatan yang sama bisa dipakai untuk jawaban pertanyaan keamanan. Ada banyak pengelola kata sandi gratis maupun berbayar yang menyelesaikan masalah harus mengingat semua nilai rahasia. Itu juga bagus untuk mencadangkan secret autentikasi dua langkah
    Jika “pesan kesalahan rumit” adalah kesalahan yang diharapkan bisa diperbaiki sendiri oleh pengguna, lebih baik kembalikan saja kesalahan umum dengan ID unik dan minta mereka menghubungi tim dukungan. Hujan jargon memang menyebalkan, tetapi ini tampak lebih seperti ketidakmampuan manusia yang umum dalam menjelaskan kesalahan, bukan masalah khas keamanan
    Sebagian besar organisasi, meskipun bisnisnya secara keseluruhan sukses, sekaligus merusak banyak hal, dan keamanan adalah salah satunya. Dalam organisasi yang cukup besar, menurut saya sulit menghindari orang tidak kompeten melakukan hal-hal tidak kompeten

• Ini tidak masuk akal di banyak lapisan. Apakah artinya Microsoft Authenticator menyimpan entri hanya berdasarkan label? Tidak membuat semacam kunci internal juga?
  Lalu mereka mengklaim masalahnya adalah situs web menaruh penerbit di kolom issuer yang memang seharusnya, bukan di label?
  Saya jadi bertanya-tanya apakah di Microsoft benar-benar tidak ada orang yang memakai Authenticator mereka sendiri. Kalau saya tidak melewatkan sesuatu, begitu sebuah email dipakai di satu situs, email itu tidak bisa ditambahkan untuk situs lain, jadi rasanya tidak bisa dipakai di hampir semua aplikasi

  • Mirip dengan itu, Google yang raksasa pencarian meluncurkan Google Authenticator versi Android tanpa kotak pencarian, dan meski ada banyak permintaan fitur, mereka sengaja terus tidak menambahkannya
    Namun versi iOS punya kotak pencarian. Entah kenapa
    Di dalam repositori Piper yang sangat besar, rasanya sudah ada pustaka pencarian lokal yang bisa disisipkan lewat satu daftar perubahan, meskipun memang itu bukan model bahasa besar
  • Menurut artikelnya, Microsoft tidak berniat memperbaikinya karena itu produk gratis dan tidak menghasilkan pendapatan
  • Jika karyawan Microsoft memakai Authenticator mereka sendiri, paling-paling mereka memakainya hanya untuk akun kerja perusahaan, tempat Microsoft menjadi satu-satunya penerbit
    Dan saya rasa sangat banyak orang bahkan tidak memakainya sama sekali
  • Ada sesuatu yang tidak cocok di sini. Saya punya beberapa akun dengan email yang sama, dan saya membandingkan kode dari Authenticator, aplikasi TOTP cadangan saya, dengan kode yang benar, dan hasilnya cocok
    Namun saya menemukan masalah UI yang bisa membuat pengguna melihat kode yang salah. Kode untuk beberapa akun pertama yang terlihat di layar diperbarui setiap 30 detik, tetapi kode yang berada di luar layar tidak diperbarui
    Jika menggulir untuk membawa kode yang sebelumnya di luar layar, yang terlihat adalah kode lama, dan dalam satu kasus muncul kode yang tertinggal 4 putaran dari kode yang benar
  • Mungkin besar kemungkinan hanya dipakai untuk satu akun MS kerja yang diwajibkan oleh perusahaan. Sepertinya tidak akan dipakai di tempat lain, karena mereka tahu itu kurang bagus

• Anehnya, saya menerima email dari Microsoft yang terlihat seperti phishing tetapi sepertinya bukan
  Isinya “Tindakan diperlukan: aktifkan autentikasi multifaktor untuk tenant Anda paling lambat 15 Oktober 2024”, dan katanya saya menerimanya karena saya adalah “administrator global”, tetapi hanya ada UUID tanpa nama organisasi
  Pemberitahuannya mengatakan bahwa mulai 15 Oktober 2024, MFA akan diwajibkan untuk login ke portal Azure, pusat admin Microsoft Entra, dan pusat admin Intune, jadi aktifkan MFA sebelum itu. Jika tidak bisa, diminta mengajukan penundaan tanggal penerapan
  Masalahnya, saya tidak mengelola organisasi apa pun di Microsoft. Saya hanya punya semacam akun pribadi Office365 Family, dan akun itu sudah saya atur dengan autentikasi 2 langkah
  Di email tidak ada nama saya maupun nama organisasi yang seharusnya, hanya ID, jadi saya sama sekali tidak mengerti maksudnya. Meski begitu, email itu memang berasal dari Microsoft

  • Kalau login ke portal Azure, kemungkinan akan terlihat pesan serupa dan bisa masuk ke resource terkait

• Setelah membuat akun Gmail, saya kehilangan beberapa akun ketika pindah negara dan mengganti komputer. Saat mencoba login, Google mengatakan kata sandinya benar, tetapi perangkat dan IP-nya tidak dikenal
  Saya tidak ingat persis mengapa pemulihan lewat alamat pemulihan tidak berhasil, tetapi meskipun saya masih bisa mengakses alamat email pemulihan, prosesnya tetap gagal. Mungkin Google meminta saya menyebutkan apa alamat email pemulihannya, dan saya mungkin memakai sufiks + acak pada alamat pemulihan itu
  Dulu saya memakai Google Authenticator untuk akun Gmail, tetapi saya mematikannya karena takut menambah satu lagi titik kegagalan, sementara Google tidak memberi jalan keluar yang berarti
  Kata sandinya memiliki entropi sekitar lebih dari 96 bit; saya mengambil 256 bit dari /dev/urandom, menjadikannya integer multipresisi, lalu dengan divmod mengambil masing-masing satu dari angka, huruf kecil, huruf besar, dan simbol, sisanya diambil dari seluruh alfabet, lalu dengan entropi yang tersisa menjalankan Fisher-Yates shuffle agar karakter pertama tidak selalu angka
  Itu kata sandi per situs, dan disimpan di pengelola kata sandi berbasis gpg yang saya buat sendiri pada awal 2000-an
  Autentikasi multifaktor memang membantu terhadap sebagian kompromi aktif yang sedang berlangsung, tetapi tidak membantu terhadap dump hash kata sandi akibat pembobolan basis data. Sangat menyiksa ketika pemulihan lewat alamat email pemulihan tidak bisa dilakukan padahal kata sandinya diketahui
  Jika saya tidak login dari mana pun selama beberapa bulan dan memiliki kata sandi yang benar, setidaknya jangan minta saya menyebutkan alamat pemulihan; kirim saja tautan verifikasi atau kode ke alamat pemulihan itu. Tidak perlu memberi tahu ke mana dikirim, tetapi menjadikan alamat pemulihan sebagai kata sandi lain yang harus dihafal itu benar-benar menjengkelkan

  • Saya tidak tahu soal ini. Untuk memperbesar risiko, saya telah menyetel alamat pemulihan ke akun Gmail tidak aktif lainnya
    Saya sekarang tidak lagi memercayai Google lebih dari data yang sudah saya berikan dan data yang memang harus saya berikan
    Karena ada rencana migrasi internasional, saya harus mempercepat pemindahan kehidupan email saya ke Proton Mail, akun berbayar yang sedang saya uji, sebelum terjadi masalah serius
    Pada masa ketika Gmail masih terlihat polos, saat administrasi mulai beralih online, saya mulai memberikan Gmail sebagai kontak untuk pajak, layanan kesehatan, dan lembaga publik. Itu berjalan baik, sehingga melalui beberapa kali perpindahan internasional, Gmail menjadi alat administrasi yang penting
    Ada juga akun-akun tidak aktif di sana-sini, tetapi masih ada urusan penting yang mungkin suatu saat dibutuhkan. Misalnya izin perjalanan Australia yang berlaku beberapa tahun
    Bahkan setelah pengawasan massal makin cepat, Gmail masih terlihat cukup tidak berbahaya, dan selain fakta bahwa saya berurusan dengan lembaga tertentu, hampir tidak ada rahasia nyata atau kisah pribadi yang mendalam
    Namun sekarang administrasi online praktis wajib, dan jalur lain tinggal minimal, Gmail berada di posisi yang terlalu sentral sampai terasa tidak nyaman. Karena hal-hal mengkhawatirkan yang dilakukan bot otomatis terhadap pengguna yang tidak dicurigai tanpa belas kasihan maupun mekanisme banding, saya terpaksa mulai pindah
    Karena sudah tersebar terlalu luas, tidak ada cukup waktu untuk menelusuri semuanya, dan akun yang terlupakan terasa seperti penyiksaan karena harus menggali ingatan samar. Namun tetap harus dilakukan
    Saya tidak ingin putri kembar saya, ketika sudah cukup umur untuk membutuhkan email dalam urusan resmi, diserahkan pada belas kasihan bot Google
  • Saat menambahkan email pemulihan, seharusnya Anda menerima email notifikasi di akun tersebut. Jika menemukan email itu di inbox, mungkin Anda bisa mengetahui sufiks acaknya dari field to
  • Saya pernah mengalami hal serupa. Saya ditambahkan ke domain Google milik sebuah proyek open source dan mendapat alamat email, tetapi Google meminta nomor telepon sehingga saya tidak bisa login
    Mungkin saya bisa meminta admin untuk meresetnya, tetapi cukup tidak menyenangkan ketika akun pada dasarnya disandera sampai kita menyerahkan informasi pribadi
  • Karena tidak ada siapa pun yang bisa diajak bicara, kalau komputer mengatakan tidak bisa, maka selesai sudah

• Saya sudah memakai punya Microsoft karena akun kerja. Toh sudah sangat terintegrasi dengan Office365, jadi tidak ada alasan untuk tidak memakainya
  Saya belum pernah melihat dialog seperti itu, dan akun yang saya tambahkan juga tidak bermasalah. Karena ini akun kerja, 99% saya membagikan email perusahaan saya sebagai nama akun
  Jadi apakah itu berarti saya beruntung karena situs-situs yang saya pakai menyediakan label yang cukup unik? Rasanya saya belum sepenuhnya memahami apa persisnya masalahnya

  • Saya ingin memakai kunci hardware sebagai autentikasi dua langkah, tetapi tidak semua sistem mendukungnya, dan dukungannya pun tidak benar-benar baik. Kalau maksimal kunci yang bisa didaftarkan cuma 1, sebenarnya maunya apa?
    Pada akhirnya waktu terus berjalan, dan ini bukan pekerjaan yang memberi nafkah keluarga, melainkan sekadar kerepotan menggali cara apa yang harus dilakukan agar bisa login, jadi saya memutuskan memakai punya MS yang diwajibkan di tempat kerja sebelumnya
    Saya sudah membuang terlalu banyak waktu mengutak-atik hal seperti ini untuk memakai akun online, alih-alih melakukan sesuatu yang bermakna
    Seluruh verifikasi identitas online sangat tidak dapat diandalkan dan penuh lubang besar serta risiko yang lebih besar, tetapi kita membangun seluruh hidup kita di atasnya
    Selama puluhan tahun sudah ada kerusakan serius akibat kelemahan password, tetapi kita masih memakai password dan mencoba menambalnya dengan plester atau cat
    Hampir setiap minggu ada sistem online yang membocorkan data pribadi dalam jumlah besar yang mudah disalahgunakan, tetapi kita tetap duduk seperti meme anjing yang minum kopi di tengah ruangan terbakar sambil berkata, “tidak apa-apa, tidak apa-apa”
    Kita percaya semuanya akan baik-baik saja sambil berkata bahwa kita akan aman kalau memakai password berbeda sepanjang minimal 8 karakter untuk setiap sistem
  • Bug ini tampaknya hanya terjadi saat memindai kode QR di aplikasi iOS
  • Saya juga sama. Tiga akun pribadi memakai alamat email yang sama, dua di antaranya FAANG, dan hampir 10 tahun ini berjalan tanpa masalah
  • Kalau membaca jawaban Microsoft, Microsoft menyalahkan perusahaan penerbit MFA karena “tidak memasukkan issuer ke label”. MSFT mengharapkan issuer memang ada di sana
    Kalau ekspektasinya begitu, produk Microsoft sendiri tentu akan memasukkan issuer ke label, jadi tidak akan bermasalah
    Masalah muncul ketika memakai penyedia lain yang menggunakan email yang sama sebagai identifier, tetapi memasukkan issuer ke field issuer yang memang disediakan untuk menyimpan issuer. Seolah-olah itu tindakan yang aneh

• Safari juga punya bug serupa, yang menimpa passkey tanpa peringatan apa pun hingga membuat saya benar-benar terkunci dari akun. Itu sudah diperbaiki kemudian, tetapi gara-gara ini saya kehilangan akses ke GitHub
  https://bugs.webkit.org/show_bug.cgi?id=270553
  Safari masih punya bug yang tidak bisa membedakan website yang di-host di subdomain berbeda selain lewat pengecualian hardcoded, dan menimpa password satu subdomain dengan milik subdomain lain. Saya mengalaminya setiap bulan

  • Salah satu alasan saya memakai password manager pihak ketiga yang bisa menambahkan beberapa situs secara manual ke satu entri adalah karena Keychain memperingatkan bahwa password dipakai ulang di subdomain StackOverflow dan StackExchange
    Tapi saya tidak tahu kebodohan seperti ini berlanjut lebih dalam lagi

• Inilah alasan autentikasi multifaktor via SMS tetap populer di kalangan pengguna meski punya kelemahan keamanan
  Biasanya cukup baik selama tidak menjadi target serangan SIM swap. Kebanyakan orang memang bukan target, tetapi kemungkinan mengalami masalah kehilangan kunci autentikasi multifaktor cukup tinggi

  • Benar. Sederhana dan hampir semua orang memahaminya. Sama seperti password itu sendiri
    Ini juga alasan metode yang lebih aman seperti YubiKey tidak bisa menyebar ke masyarakat umum. Merepotkan dan membingungkan
  • Saya pernah mengaktifkannya dua kali. Pertama, ponsel saya rusak total tepat setelah diaktifkan, dan kedua, ponselnya dicuri
    Sekarang saya hanya mengandalkan password yang dibuat acak
  • Menurut saya jalan ke depan hanya FIDO dan kunci kartu NFC yang sangat murah
    Kalau perlu login ke suatu tempat, caranya tinggal mengeluarkan kartu dari dompet lalu menempelkannya ke ponsel atau laptop
    Untuk perusahaan yang punya pelanggan berbayar, biayanya harus cukup murah sampai lebih masuk akal mengirimkan kartu secara fisik lewat pos saat pelanggan tidak punya kartu, daripada mendukung metode autentikasi alternatif
    Sebagian besar layanan mungkin bahkan tidak membutuhkan lapisan autentikasi kedua. Kalau seseorang mencuri dompet, apakah mereka benar-benar akan peduli dengan akun Reddit juga?

• Saya mencobanya, dan tidak ada konflik di antara beberapa akun yang memakai nama akun/email yang sama
  Ikon issuer juga muncul dengan benar untuk tiap entri, dan issuer terdaftar di masing-masing entri
  Saya sudah memakai MS Authenticator selama beberapa tahun dan belum pernah mengalami masalah seperti ini, dan tentu saja saya selalu memakai email yang sama sebagai nama akun atau username
  Saya hanya menuliskan hasil pengujian. Ini sepertinya tidak akan mengubah pandangan tentang Authenticator atau Microsoft, tetapi begitulah

  • Saya penasaran platformnya apa. Saya dengar masalah itu, atau “fitur” itu, terbatas pada versi iOS

• Hal ini juga terjadi pada saya ketika saya memperbarui MS Authenticator setelah lama tidak memperbaruinya
  Semua data terhapus, dan saya terkunci dari semua akun. MS Authenticator bukan produk yang dibuat dengan hati-hati

• Sekitar setahun lalu hal serupa terjadi ketika aplikasi Google Authenticator otomatis diperbarui ke versi baru
  Dalam proses pembaruan, semua akun saya hilang, dan jelas saya mendapat beberapa pelajaran

  • Karena mimpi buruk ini, saya selalu mencadangkan kode QR MFA, lalu menambahkannya ke aplikasi open-source yang bisa dipakai untuk mencadangkan data itu juga ke tempat lain