Sebagian Fungsi Google OAuth Mengalami Gangguan

• Pada layanan yang mengandalkan email claim Google OAuth untuk menentukan hak login, mantan karyawan dapat tetap mempertahankan akses ke aplikasi seperti Slack dan Zoom bahkan setelah dihapus dari organisasi Google perusahaan
• Akun Google dapat dibuat dengan email non-Gmail, dan dengan memanfaatkan alias serta penerusan alamat plus pada email perusahaan, akun Google yang tidak tergabung dalam organisasi dapat mengirim email claim dengan domain email perusahaan
• Akun non-Gmail ini tidak muncul di layar admin atau daftar pengguna organisasi Google perusahaan, tetapi banyak layanan mengizinkan login hanya dengan melihat domain di akhir email
• Organisasi dapat memitigasi dengan mematikan login Google dan menerapkan SAML secara ketat, tetapi sebagian layanan atau aplikasi internal mungkin tidak menyediakan opsi ini atau tidak mendukung SAML
• Laporan disampaikan ke Google pada 4 Agustus, imbalan $1337 dibayarkan pada 5 Oktober, dan kerentanan dipublikasikan 134 hari kemudian pada 16 Desember, tetapi hingga saat publikasi perubahan mitigasi dari Google belum diterapkan

---

Pengungkapan Kerentanan dan Linimasa

• Karena kerentanan Google OAuth, karyawan yang sudah di-offboarding dari perusahaan dan dihapus dari organisasi Google dapat mempertahankan akses ke aplikasi seperti Slack dan Zoom tanpa batas waktu
• Hingga saat publikasi, Google belum menerapkan perubahan untuk memitigasi risiko ini
• Linimasanya sebagai berikut
  • 4 Agustus: Melaporkan ke Google dan menyampaikan kemungkinan ratusan aplikasi terdampak
  • 7 Agustus: Isu ditriage
  • 5 Oktober: Google membayar $1337 untuk isu ini
  • 25 November: Melakukan pelaporan massal secara privat ke puluhan aplikasi terdampak, termasuk Zoom dan Slack
  • 16 Desember: Dipublikasikan 134 hari setelah pemberitahuan kepada Google

Risiko Menggunakan email claim sebagai Identitas

• Login Forager milik Truffle Security sebelumnya pernah terdampak oleh kerentanan Microsoft OAuth dari Descope
• Saat itu terkonfirmasi bahwa Email claim yang tidak dibuat atau diverifikasi langsung oleh Microsoft dapat dikirim, dan email claim secara umum bukan identitas yang dapat dipercaya
• Dokumentasi OIDC Google juga memperingatkan agar tidak menggunakan Email sebagai identitas utama
• Claim email_verified juga diperlakukan sebagai titik yang menarik, tetapi cara membuat email claim dari email yang belum diverifikasi tidak ditemukan
• Namun, contoh penyalahgunaan email claim itu sendiri sudah cukup terkonfirmasi

Akun Google Non-Gmail dan email claim Ganda

• Akun Google dapat dibuat dengan alamat email yang sudah ada meskipun bukan alamat Gmail
  • Misalnya, akun Google dapat dibuat dengan alamat email Yahoo
  • Akun ini dapat mengirim email claim dari email tersebut dalam kondisi email non-Gmail telah dikonfigurasi
• Salah satu alasan dokumentasi Google melarang penggunaan email sebagai identitas utama adalah karena dua akun Google yang berbeda dapat mengirim email claim yang sama
  • Setelah mengubah email non-Gmail di pengaturan
  • Jika akun baru dibuat dengan email sebelum perubahan, email claim yang sama dapat terjadi

Akun yang Tersisa di Luar Organisasi Google Perusahaan

• Celah utamanya adalah akun Google di luar organisasi dapat dibuat untuk email organisasi Google perusahaan dengan memanfaatkan alias email dan penerusan alamat plus
• Alamat plus pada email perusahaan dapat diteruskan ke kotak masuk pengguna asli
• Dengan alur ini, akun Google non-Gmail berbasis alamat plus yang menggunakan email organisasi Google perusahaan dapat dibuat, dan akun ini tidak dapat dihapus dari organisasi atau di-offboarding
• Banyak layanan mem-parsing email ini lalu menentukan apakah login diizinkan berdasarkan domain di bagian akhir
  • Akun ini dapat digunakan untuk mendaftar ke Zoom
  • Akun ini dapat digunakan untuk mendaftar ke Slack
• Karena akun Google non-Gmail seperti ini bukan anggota organisasi Google yang sebenarnya, akun tersebut tidak ditampilkan di pengaturan admin atau daftar pengguna Google

Mitigasi oleh Organisasi, Penyedia Layanan, dan Google

• Organisasi dapat memitigasi dengan menonaktifkan login Google dan mewajibkan SAML secara ketat
  • Cara ini berfungsi di sebagian besar penyedia layanan
  • Sebagian layanan tidak menyediakan opsi tersebut
  • Aplikasi yang dikembangkan secara internal dapat terdampak tetapi mungkin tidak mendukung SAML
• Penyedia layanan dapat menggunakan HD claim Google OAuth
  • HD claim mengirim domain organisasi Google yang terhubung dengan akun
  • Akun yang bukan anggota organisasi Google tidak menyertakan HD claim
  • Sebagian besar penyedia layanan yang diuji menggunakan email claim, bukan HD
• HD claim masih memiliki keterbatasan penting
  • HD bukan identitas unik, melainkan sekadar domain
  • Jika organisasi Google dihapus dan domainnya dibiarkan terlantar, orang lain dapat memperoleh domain tersebut dan membuat organisasi Google baru
  • Contohnya, perusahaan A diakuisisi oleh perusahaan B, lalu B menghentikan layanan A dan tidak memperpanjang domain lama
  • Jika seseorang di internet membeli domain perusahaan A, ia dapat login ke akun layanan lama milik perusahaan A
• Penyedia layanan dapat berhenti mengizinkan pembuatan akun JIT sebagai fitur umum dan beralih ke provisioning akun berbasis undangan saja atau grup LDAP
• Google dapat melakukan mitigasi luas dengan melarang akun Google yang dibuat menggunakan domain organisasi Google yang sudah ada
  • Google secara internal melarang akun google.com
  • Perlindungan yang sama dapat diperluas ke organisasi lain
• Mitigasi lain di sisi Google mencakup pelarangan pendaftaran akun Google dengan alamat plus, pelarangan pendaftaran dengan alias email Google, serta penyediaan pengaturan admin yang lebih baik agar organisasi dapat mengonfigurasi pengaturan terkait

Dampak Tambahan: Email Dukungan dan Alur magic link

• Secara teknis, akses ke Zoom dan Slack milik organisasi mungkin dapat dilakukan meskipun tidak memiliki akses awal
• Alur ini memanfaatkan riset kerentanan yang ditemukan peneliti lain pada magic link sign-in flows
• Beberapa sistem dukungan dan tiket seperti Zendesk dapat membuat tiket dukungan melalui email
  • Akun Google dapat dibuat dengan alamat email tiket dukungan
  • Ada kemungkinan isi tiket dapat dilihat untuk menyelesaikan pembuatan akun
  • Setelah itu, login OAuth dapat dicoba menggunakan alamat email dukungan tersebut
• Mempertahankan fitur email to support pada domain utama tidak aman, dan salah satu opsi adalah mengonfigurasi email dukungan Zendesk sebagai alamat email alternatif

Tujuan Pengungkapan dan Masalah yang Tersisa

• Masalah mantan karyawan yang tetap mempertahankan akses di platform seperti Slack dan Zoom berasal dari celah dalam sistem Google OAuth
• Google memiliki kemampuan untuk melakukan perbaikan berskala luas yang dapat memitigasi masalah ini
• Tujuan pengungkapan adalah mendorong perubahan nyata, bukan sekadar perubahan kecil pada dokumentasi
• Google men-triage isu ini dengan cepat, tetapi berbeda dari praktik perbaikan 90 hari miliknya, masalah ini dipublikasikan pada hari ke-134

[GN⁺]

Opini Hacker News

• Saya bekerja di bidang ini, dan selama 3–4 tahun terakhir sudah menangani lebih dari 20 variasi kerentanan ini di berbagai penyedia login dan perusahaan SaaS. Tulisan blog itu benar, tetapi menurut saya masalah intinya sudah terlalu jauh untuk diperbaiki. Autentikasi terdelegasi di seluruh internet benar-benar berantakan, dan karena saya juga sudah banyak berbicara dengan engineer Google dan Microsoft, saya yakin mereka sudah mengetahui kelompok masalah ini. Hanya saja, jika perilaku yang ada sekarang diubah, terlalu banyak layanan lama dan implementasi login korporat yang sudah berusia puluhan tahun akan rusak
  “Perbaikan” pada titik ini sederhana. Jika sebuah situs memakai “Sign in with XYZ”, jangan percaya alamat email yang dikirimkan oleh penyedia. Jangan memberi hak khusus hanya berdasarkan domain email, dan selalu kirim email verifikasi sendiri sebelum menandainya sebagai sudah terverifikasi di database. Para penyedia OAuth besar juga sudah memperbarui dokumentasi mereka agar menyatakan hal ini secara eksplisit, dan tulisan tersebut juga menyorotinya. Karena itu, fakta bahwa ada bounty justru mengejutkan

  • Rasanya ini akibat organisasi tidak benar-benar memahami betapa kompleksnya area ini dalam praktik. Kalau melihat proses adopsi OAuth2 + OIDC di berbagai perusahaan, pendekatannya selalu dijual sebagai fitur seperti “login dengan x”, bukan dari sudut pandang security-first. Bahkan ketika mencoba membuat alurnya lebih aman seperti dengan PKCE, kekacauan tiap platform dalam hal berbagi cookie atau penanganan redirect membuatnya seperti permainan whack-a-mole. Dasar 3-legged OAuth2 sebenarnya solid dan ada banyak preseden seperti CAS, tetapi OpenID Foundation layak mendapat kritik keras atas cara mereka memasarkan dan menjual OIDC
  • Bukankah pendekatan “jangan memberi hak khusus hanya berdasarkan domain email, dan selalu kirim email verifikasi sendiri sebelum menandainya sebagai sudah terverifikasi di database” akan gagal jika pengguna mendaftarkan akun di Google dengan alamat plus, lalu sebelum dikeluarkan ia login ke layanan dengan akun Google tersebut? Kecuali kalau email verifikasi dikirim setiap kali login
  • Dalam kasus spesifik ini, penyerang memang bisa menerima email verifikasi, jadi saya tidak paham apa gunanya proses verifikasi itu
  • “Selalu kirim email verifikasi sendiri sebelum menandainya sebagai sudah terverifikasi di database” dari sudut pandang pengguna membuat fitur login dengan x menjadi tidak berguna
  • Tidak bisakah Google mencegah pendaftaran menggunakan domain pelanggan Google Apps? Sepertinya itu tidak akan merusak apa pun

• Terkait hal ini, lebih banyak penyedia layanan seharusnya berhenti memakai email sebagai identifier utama, seperti rekomendasi dokumentasi Google. Ketika mengganti username di Google Apps, saya menghabiskan banyak waktu menangani masalah di Slack, Datadog, GoLinks, dan lainnya

  • Lalu penyedia harus memakai apa? Saya selalu mengira email adalah identifier global paling stabil untuk pengguna, tetapi tampaknya asumsi itu salah
  • Sulit untuk setuju. Pedoman seperti ini hanya melempar tanggung jawab ke developer aplikasi, dan sebagian besar kemungkinan tidak akan melakukan apa-apa atau mengimplementasikannya masing-masing dengan cara berbeda
    Arah yang benar di sini adalah menyediakan API yang sesuai dengan kebutuhan aplikasi yang akan menggunakannya dan meminimalkan tanggung jawab tambahan. Dalam kasus ini, menurut saya Google seharusnya mengatur email_verified menjadi false agar aplikasi atau IdP turunan bisa tahu bahwa verifikasi tambahan diperlukan

• Jika user@domain sudah ditangani oleh server email Google sehingga aturan routing plus diterapkan, saya tidak mengerti mengapa akun Google baru bisa dibuat dengan email seperti user+suffix@domain. Bahkan tanpa penyalahgunaan pun, ini tampak sangat mudah menciptakan konfigurasi email yang membingungkan

  • Domain bebas memindahkan server emailnya. Google menangani [e-mail] dengan cara tertentu, tetapi server lain belum tentu begitu. Pada akhirnya keduanya adalah alamat email unik yang berbeda, dan di seluruh internet juga seharusnya diperlakukan begitu
  • Fitur alias ini rasanya sudah menjadi terlalu rumit dibanding manfaatnya. Apalagi pada skala Google
  • Ini lebih buruk daripada user+suffix@domain. Setidaknya +XYZ memang disebutkan dalam RFC email. Google melangkah lebih jauh dengan menetapkan bahwa titik di dalam nama juga dianggap sebagai email kanonik. Misalnya [e-mail] sama dengan [e-mail], dan semua email dirutekan ke yang terakhir
  • Itu karena sistem autentikasi Google adalah legacy yang sangat tua. “Akun Google” hanyalah string

• Mengenai bagian “Saya terkejut mengetahui bahwa Microsoft mengirim klaim email yang tidak dibuat atau diverifikasi oleh Microsoft, dan bahwa secara umum klaim email tidak dianggap dapat dipercaya”, meskipun mungkin itu memang maksud awalnya, saya melihat bahwa fakta OIDC bisa lebih fleksibel sangat berguna. Misalnya, saya menjalankan penyedia login gratis[0], yang memverifikasi identitas melalui OIDC upstream atau email langsung dengan penyedia identitas (IdP) pihak keempat, dan membuat sekat privasi antara aplikasi dan IdP tersebut. Artinya, Google tidak bisa melacak semua aplikasi tempat pengguna login
  Bahwa Anda bisa membawa email sendiri ke Google berarti Anda bisa mendapatkan keamanan dan pengalaman pengguna Google OIDC bersama privasi email+kata sandi, tetapi dengan catatan besar bahwa kini Anda harus mempercayai LastLogin, bukan Google. Kami juga sedang mengerjakan protokol untuk mengurangi ketergantungan itu. Saya sama sekali tidak setuju dengan bagian “Dokumentasi Google sebenarnya memperingatkan agar tidak memakai email sebagai identifier”. Email adalah satu-satunya identitas federatif nyata yang benar-benar dipakai orang. Sampai alternatif yang lebih baik diterapkan secara luas, saya percaya alamat email harus diperlakukan sebagai identitas
  [0]: https://lastlogin.io

  • Saya tidak setuju dengan “alamat email harus diperlakukan sebagai identitas”. Ada dua alasan
    Di luar dunia Barat, ponsel lebih umum daripada komputer dan UI-nya biasanya lebih mudah, jadi nomor telepon lebih mungkin menjadi identitas. Selain itu, dengan begitu Anda sepenuhnya menyerahkan identitas kepada penyedia email. Organisasi tanpa wajah seperti Google bisa, dan memang sering, memblokir akses tanpa pemberitahuan atau proses banding, sehingga Anda bisa kehilangan semuanya. Sebagai latar belakang, saya meluncurkan produk OAuth dan OIDC Okta, membuat kursus terkait di LinkedIn, dan sekarang melakukannya lagi di Pangea Cyber
  • “Alamat email harus diperlakukan sebagai identitas”, maksudnya dengan asumsi tidak ada yang pernah berbagi alamat email dan email sangat aman?
    Kita bisa menunggu selamanya, atau mulai membuat solusi
  • Ada perbedaan penting antara identifier email di dalam sistem Anda sendiri dan email sebagai identifier untuk akun Google yang terhubung. Saya setuju bahwa di dalam sistem yang Anda kendalikan, email cukup bisa berfungsi sebagai identitas, tetapi saat menghubungkannya dengan sistem eksternal, seperti yang dikatakan Google, itu cara yang buruk. Sifatnya sementara, bisa terikat ke beberapa akun, dan tidak ada alasan memakainya ketika ada ID nyata yang bisa digunakan
  • Akan sangat bagus kalau ada perbandingan LastLogin dan Dex. Saya khususnya penasaran karena keduanya ditulis dalam Go. Saya juga penasaran apakah Dex pernah dievaluasi
    Saya pernah sedikit mencoba Portier dan Mozilla Persona dulu, tetapi pada akhirnya menangani masalah normalisasi email tampak seperti pertarungan yang pasti kalah atau terlalu sulit. Saya hampir menerima bahwa saya mungkin akan mati sebelum solusi yang bagus dirintis, lalu mengalihkan perhatian ke hal lain

• Apakah ini benar-benar masalah Google OAuth, atau kegagalan banyak penyedia layanan untuk memverifikasi klaim pada token OAuth dengan benar sebelum mengizinkan akses? Sepertinya yang kedua

  • Masalahnya terdengar seperti para penyedia layanan ini mengikuti aturan alias Google, tetapi mengabaikan fakta bahwa email tidak boleh dipakai sebagai identifier utama [1]. Menariknya, kalau mereka mengikuti spesifikasi dengan lebih baik, semuanya akan baik-baik saja; sebaliknya, kalau mereka kurang mengikuti spesifikasi dan memperlakukan alias sebagai email yang berbeda, setidaknya itu akan lebih aman
    [1] https://developers.google.com/identity/openid-connect/openid...
  • Menurut saya OAuth bekerja sesuai harapan. user@domain dan user+wildcard@domain tetap diverifikasi sebagai alamat email yang “dimiliki” pengguna, sehingga memberikan autentikasi dan identitas yang valid untuk alamat email tersebut
    Masalahnya ada di sisi situs organisasi Google. Admin tidak bisa mencabut kredensial untuk akun atau email yang tidak dapat mereka lihat. Bagian kuncinya adalah “akun Google non-Gmail ini sebenarnya bukan anggota organisasi Google, sehingga tidak muncul di pengaturan admin atau daftar pengguna Google”

• Kalau mengikuti alur ini, seseorang bisa membuat akun Google dengan alamat email tiket dukungan, berpotensi membaca isi tiket untuk menyelesaikan pembuatan akun, lalu login OAuth ke berbagai layanan memakai alamat email dukungan itu. Ini bisa berdampak pada banyak perusahaan kecil

• Kesimpulan terbesar dari sini adalah autentikasi web masih berupa kekacauan yang mengerikan

  • Karena orang tidak membaca dokumentasi, dan hanya berasumsi bahwa semuanya bekerja seperti yang mereka bayangkan
  • Kalau Anda bertanya mengapa orang-orang waras dan pragmatis masih memakai dan mewajibkan autentikasi kata sandi sederhana, jawabannya: karena kata sandi bekerja dengan benar

• Spesifikasi OIDC mengatakan email tidak boleh dipakai sebagai identifier unik. Untuk nama pengguna aplikasi, Anda harus memakai field iss dan sub
  Alasannya, pertama, jelas bahwa alamat email pengguna bisa digunakan ulang. Jika seorang kontraktor bekerja untuk Business A dan Business B, dan keduanya membuat akun pengguna orang itu di layanan autentikasi, dari sudut pandang platform SaaS, satu alamat email tidak bisa dipetakan ke satu pelanggan B2B. Kedua, alamat email berubah. Perusahaan diakuisisi, berganti nama, merger, dan nama orang juga berubah karena menikah, bercerai, atau pilihan pribadi. Mengimplementasikan SSO di startup awalnya benar-benar sulit. Sulit melakukannya dengan benar, dan sebelum memakainya Anda harus memahami konsep umum, OIDC, dan OAuth2 dengan baik. Auth0 punya buku yang bagus. Kalau Anda tidak memahami ini, besar kemungkinan Anda akan mengimplementasikan autentikasi password grant di sana-sini dan membuat aplikasi menjadi tidak aman

  • Kadang membaca tulisan seperti ini sedikit mengurangi impostor syndrome yang menumpuk. Saya jadi berpikir, “Kalau berintegrasi dengan sistem pihak ketiga untuk sesuatu yang mewakili aktor abstrak, tentu harus ada identifier tepercaya yang stabil dan tidak terlalu seperti string biasa.” Pada praktiknya spesifikasi juga sangat jelas soal ini, dan itu bahkan melampaui pertimbangan dasar saat membangun sistem yang sedikit saja ingin kokoh

• Seperti thumbnail kecil. Yang disebut OAuth2 sebenarnya tidak ada. OAuth2 hanyalah cara bagi perusahaan-perusahaan raksasa untuk mengimplementasikan sistem autentikasi mereka sendiri yang arbitrer dan tertutup. Ia bukan sistem autentikasi, melainkan kotak perkakas untuk membuat sistem autentikasi. Jadi OAuth2 tadinya akan menjadi standar, tetapi pada praktiknya kita berakhir di dunia tempat tiap perusahaan raksasa punya implementasi yang tidak saling kompatibel. Tentu orang-orang akan mengembangkan sesuai use case perusahaan raksasa, tetapi dengan begitu “standar” pada akhirnya menjadi semacam cara Google melakukannya
  Dan masing-masing punya bug-bug kecil seperti ini. Kita harus kembali ke OAuth1. Itu benar-benar standar, bukan kotak perkakas untuk membuat standar

  • Ini lebih mirip efek samping yang tidak menguntungkan dari gabungan beberapa komponen tertentu daripada bug. Ini hasil dari nama domain yang kepemilikannya bisa berubah, membawa email sendiri, email cadangan dan asal email, penerimaan alias plus yang longgar, serta implementor layanan yang tidak membaca dokumentasi. Para implementor mungkin menyalin solusi dari video atau contoh yang demi keringkasan menghilangkan detail
    Kalau Anda merancang rangkaian dengan beberapa komponen PCB dan harus memasukkan resistor serta transistor sesuai kebutuhan tegangan/arus, bukankah semestinya kita berharap Anda membaca datasheet? Jika hanya menebak-nebak dari contoh sederhana lalu memaksakannya, dalam banyak kasus rangkaiannya mungkin bisa bekerja, dan dengan sedikit bench test serta probing mungkin bisa jalan. Tetapi efisiensinya bisa buruk, atau komponen bisa korsleting sehingga mean time to failure turun dan pelanggan tidak senang. Dalam skenario terburuk, baterai bisa terbakar dan menimbulkan kerusakan nyata. Lalu apakah kegagalan dini perangkat itu salah produsen modul PCB, atau tanggung jawab produsen perangkat yang seharusnya membaca datasheet? Saya tidak mengharapkan standar seketat itu untuk semua perangkat lunak, tetapi kalau berurusan dengan autentikasi dan otorisasi, menurut saya pemilik layanan harus teliti. Artikel aslinya juga mengatakan bahwa jika mengikuti dokumentasi, masalah ini tidak ada. Alphabet membayar bug bounty, jadi mereka mengakui adanya kelemahan; mereka juga bisa menyediakan kontrol bagi admin perusahaan untuk mengelola allow/deny list atas alias plus atau peran yang tidak ada, atau membatasi agar email terkait Apps tidak berpindah menjadi klaim di luar organisasi. Mungkin mereka sedang mengukur dampaknya atau menentukan prioritas pengukurannya, tetapi karena ini masalah klien yang menganggap klaim email lebih otoritatif dan permanen daripada kenyataannya, prioritasnya mungkin rendah. Definisi “bug” sangat bergantung pada bagaimana “perilaku yang diharapkan” didefinisikan dan siapa yang mengharapkannya, tetapi setidaknya menurut saya ini bukan penyimpangan dari perilaku yang disengaja, dan juga bukan sesuatu yang tak terduga bagi orang yang memahami dokumentasinya dengan benar
  • Hmm... anggap saja begitu. Apakah kompatibilitas antar-penyedia ada hubungannya dengan tulisan ini tentang keamanan Google OAuth2?

• Apa yang saya lewatkan? Selain sistem dukungan/Zendesk dan metode domain lama yang terbengkalai yang disebutkan di artikel, saat membuat akun Google baru dengan [e-mail], saya diminta verifikasi. Jadi seberapa besar kemungkinan eksploitasi nyatanya?

  • Intinya adalah melakukan ini lebih dulu saat masih punya akses yang sah, lalu kemudian kehilangan akses tersebut
    Misalnya Anda secara sah punya akun Google [e-mail]. Anda bisa membuat akun Google baru dengan alamat email terverifikasi memakai alias seperti [e-mail], dan saat “Login dengan Google”, Google akan mengirim klaim email [e-mail]. Setelah itu, jika Anda dipecat dari mydomain.com, akun yang terhubung ke [e-mail] yang sebenarnya tidak bisa lagi dipakai login karena admin telah menonaktifkannya. Namun akun Google baru [e-mail] tidak terhubung ke organisasi, sehingga tetap bisa login. Hanya saja menurut saya ini menjadi masalah hanya ketika penyedia melakukan otorisasi hanya berdasarkan klaim email. Saya pernah memakai OIDC, dan Anda tidak boleh memberi hak akses ke resource dengan mem-parse teks klaim alamat email. Saya paham mengapa penulis merasa ini berlawanan dengan intuisi, tetapi artikelnya sendiri juga menulis bahwa dokumentasi memperingatkan agar tidak melakukan ini. Di artikel asli tertulis “sebagian besar penyedia layanan yang saya uji tidak memakai HD dan memakai klaim email”; baik, tetapi “memakai” itu untuk apa? Apakah trik ini benar-benar bekerja pada layanan nyata di dunia sebenarnya? Jika ya, seharusnya namanya dipublikasikan agar mendapat kritik. Bahkan jika nilai ini keliru diasumsikan unik dan tidak berubah, itu saja belum tentu memberikan hak akses apa pun