Alamat email tidak cocok sebagai pengenal akun 'permanen'

• Saat membuat ID akun jangka panjang di dalam sistem, hanya karena OIDC mengembalikan alamat email bukan berarti itu layak dipakai sebagai ID permanen; jika dipakai, masalah perubahan dan penggunaan ulang ikut terbawa
• Bahkan di dalam satu organisasi, alamat email bisa berubah seperti nama atau login, sehingga tidak cukup stabil untuk dijadikan nilai acuan akun
• Walaupun akses atau penerusan email ke alamat lama masih tersisa, tidak ada jaminan bahwa alamat itu akan terus berfungsi untuk penggunaan non-email seperti autentikasi OIDC
• Alamat email mungkin diperlukan untuk pemulihan akun, tetapi jika sistem autentikasi menyediakan ID terpisah yang unik dan permanen, nilai itulah yang harus dipakai sebagai ID internal
• Meskipun nilainya tidak terlihat oleh pengguna, pengenal internal akun sebaiknya berupa ID tanpa makna agar lebih sederhana dari sisi operasi jangka panjang dan keamanan

---

Mengapa alamat email terasa menggoda untuk dipakai sebagai ID permanen

• Saat membuat pengenal internal per akun, alamat email sering muncul sebagai kandidat karena sistem autentikasi seperti OIDC mengembalikan data yang mencakup alamat email
• Namun, jika alamat email dijadikan pengenal internal permanen akun, muncul dua masalah: dapat berubah dan dapat digunakan ulang

Alamat yang bisa berubah sulit dijadikan nilai acuan

• Masalah terbesar adalah bahwa alamat email bisa berubah
  • Bahkan dalam satu organisasi, alamat email seseorang bisa berubah
  • Alamat itu bisa berubah karena alasan yang sejenis dengan berubahnya nama yang dipakai sehari-hari atau login
  • Menolak perubahan atau penerbitan ulang alamat email yang diberikan organisasi bisa menjadi tindakan yang terlalu keras hingga secara hukum sulit dipertahankan di banyak tempat
• Walaupun alamat email lama tidak sepenuhnya hilang, itu tetap tidak cukup sebagai pengenal permanen
  • Akses ke alamat lama atau penerusannya mungkin masih ada
  • Meski begitu, alamat lama tersebut mungkin tidak terus berfungsi untuk penggunaan non-email seperti autentikasi OIDC
  • Pengguna ingin memakai alamat baru mereka saat ini, bukan alamat lama yang bisa terasa merepotkan

Penggunaan ulang dan email pemulihan harus ditangani secara terpisah

• Masalah yang lebih kecil adalah tidak ada jaminan bahwa organisasi tidak akan menggunakan ulang alamat email
  • Secara umum, alamat itu bisa saja digunakan ulang
  • Terutama alamat yang sangat diminati bisa dipakai ulang atau dialokasikan ulang sebagai pengecualian karena diinginkan oleh orang yang berpengaruh
• Jika pemulihan akun harus dilakukan melalui alamat email yang terdaftar, maka email itu mungkin memang perlu disimpan
  • Tetapi jika ada ID internal yang secara teori unik dan permanen seperti pada OIDC, maka yang harus dipakai adalah ID internal tersebut
• Bahkan jika email untuk pemulihan akun perlu disimpan, pengenal internal akun tetap harus berupa ID tanpa makna
  • Meskipun nilai ini tidak diekspos ke pengguna, pengoperasian jangka panjang menjadi lebih sederhana
• Memberi terlalu banyak makna pada alamat email juga bisa menyembunyikan masalah keamanan

[GN⁺]

Komentar Hacker News

• Tidak ada pengidentifikasi identitas yang baik
  Email bisa berubah, dan kita juga bisa kehilangan akses ke email lama
  Banyak orang juga tidak suka username, sehingga daripada nama unik yang tidak bermakna seperti user53267, mereka ingin memilih nama yang tidak harus unik
  Perangkat juga bisa hilang, jadi sekadar menyimpan UUID rahasia di cookie atau memakai passkey perangkat tidak menyelesaikan masalah
  Tidak ada solusi ideal, dan berbagai cara harus digabungkan. Bagi sebagian orang, email bertahan lama dan stabil sehingga bagus sebagai pengidentifikasi identitas, tetapi bagi yang lain username lebih stabil sehingga mereka lebih memilih itu. Namun saya hampir tidak pernah melihat orang memakai perangkat utama yang sama selama lebih dari beberapa tahun, apalagi puluhan tahun, jadi identifikasi berbasis perangkat mungkin tidak akan berjalan baik
  Ini terutama sering terlihat pada email kantor [e-mail]. Banyak software vendor memakai Sign in with Google, lalu menyimpan alamat email itu sebagai pengidentifikasi di dalam aplikasi vendor
  Nama bisa berubah karena menikah, bercerai, transisi, berpindah budaya, memilih nama baru, dan sebagainya, dan alamat email pun ikut berubah
  Mungkin sesuatu seperti OIDC memerlukan ekstensi baru, seperti API standar untuk perubahan username dan API standar untuk perubahan alamat email

  • Email tertua yang masih bisa saya akses sudah berusia lebih dari 20 tahun. Sekarang tidak saya pakai, tetapi umurnya lebih panjang daripada nomor telepon atau alamat fisik mana pun yang pernah saya miliki
    Selain pengidentifikasi resmi seperti kartu identitas resmi atau nomor jaminan sosial, tampaknya sulit membuat yang lebih baik daripada ini
  • Orang juga punya hak untuk kehilangan segalanya dan memulai hidup baru. Baru beberapa dekade lalu, hal seperti itu benar-benar mungkin dilakukan
  • OIDC sudah menangani masalah ini dengan mensyaratkan klaim sub tidak boleh dialokasikan ulang dan harus unik: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...
    Tentu saja, ini berarti alamat email tidak boleh dimasukkan ke sub pada ID token
  • Kasus perubahan email seperti ini yang paling “saya sukai” adalah masalah yang dibuat sendiri, seperti perubahan sufiks kontraktor
    Saya pernah mengalami perusahaan yang mengharuskan akun yang benar-benar baru dibuat saat seseorang beralih menjadi karyawan tetap. Karena tidak ada sistem izin yang sederhana dan terpadu, tepat setelah transisi butuh sekitar 3 minggu untuk mendapatkan kembali akses ke sistem yang masih bisa diakses sehari sebelumnya
    Yang lebih lucu, perusahaan itu banyak berbisnis menyediakan sistem akun yang kompleks untuk pelanggan, dan juga punya sistem identitas eksternal yang bisa menangani masalah seperti ini dengan mudah. Namun sistem identitas eksternal itu justru tidak diterapkan kepada karyawan internal yang memeliharanya
  • Saya menyukai cara lama Discord, yaitu struktur yang memisahkan email dan display name
    Karena semua orang memiliki angka, angka itu tidak terlalu berarti. Saat berubah menjadi ID akun unik, saya agak kecewa, dan sampai sekarang masih penasaran kenapa mereka mengubahnya

• Sebagai individu, pendekatan terbaik untuk menghadapi masalah ini apa?
  Gmail bisa tiba-tiba terkunci atau akunnya diblokir karena algoritma AI, dan jika ada yang salah tidak ada jalur pemulihan
  Yahoo baru-baru ini meminta saya melakukan verifikasi ke email nonaktif yang sudah 15 tahun tidak bisa saya akses saat login, sehingga saya kehilangan akses. Untungnya saya masih bisa mengakses email client, jadi saya bisa memindahkan akun-akun penting
  Yahoo/AOL/Tutanota/Protonmail/dan banyak lainnya akan menghapus akun secara otomatis jika Anda tidak cukup sering login. Protonmail belum melakukannya, tetapi ketentuannya mengizinkan hal itu
  Self-hosting pun pada dasarnya membutuhkan email untuk seluruh infrastrukturnya. Jika kehilangan akses ke email itu, Anda bisa melewatkan notifikasi pembayaran dan kehilangan akun hosting. Saya pernah hampir kehilangan domain karena notifikasi pembayaran masuk ke email yang hampir tidak pernah saya cek karena tidak mendukung IMAP. Jika Anda bukan administrator sistem profesional dan tidak punya cukup waktu pemeliharaan, risiko diretas juga lebih besar
  Push Duo tamat jika ponsel rusak, dan autentikasi SMS punya masalah seperti ponsel rusak, kehilangan akses ke paket seluler, atau kebocoran kode oleh orang dalam
  Pada akhirnya saya memutuskan memakai alamat Gmail kampus. Mereka berjanji alumni bisa tetap memilikinya, dan jika ada yang salah—mungkin kehilangan 2FA karena ponsel hilang—ada pusat dukungan alumni yang cukup baik
  Di suatu tempat, jalur dukungan manusia yang bisa diajak bicara mutlak diperlukan. Meski begitu saya belum yakin apakah ini yang terbaik, dan masih penasaran apakah risiko dari pihak Google tetap ada

  • Solusi terbaik yang terlewat adalah memakai domain sendiri dan email hosting seperti Gmail
    Seperti yang Anda katakan, jika terkunci, “cukup” ganti penyedia, dan paling banter hanya kehilangan email beberapa jam
  • Bagaimana dengan iCloud? Secara teori akun bisa saja diblokir, tetapi setidaknya Apple umumnya terasa punya jalur pemulihan dan memungkinkan kita berbicara dengan manusia

• Saya setuju bahwa email bukan identitas permanen yang baik. Namun, memakai nomor telepon sebagai bagian dari identifikasi lebih buruk lagi
  Saya sudah memakai email yang sama dengan domain sendiri selama hampir 20 tahun, tetapi dalam periode yang sama nomor telepon saya sudah berganti hampir sekitar 12 kali. Saya sering melihat kasus situs web mengaktifkan 2FA ke nomor lama, atau pengguna lupa bahwa sejak awal mereka mendaftarkan nomor lama di situs itu
  Bahkan saat tinggal di luar negeri, saya masih mempertahankan nomor AS dengan membayar sekitar pajak 150 dolar per bulan ke AT&T, karena masih ada situs-situs yang mengirim kode login ke nomor itu, dan saya takut kalau nomor itu dibuang saya akan kehilangan akses ke layanan penting karena lupa memperbaruinya atau karena layanan itu membutuhkan nomor AS

  • Kalau nomor itu dipindahkan ke penyedia VoIP seperti DIDww, bisa dipertahankan dengan 2,50 dolar per bulan, dan kalau mau SMS yang masuk juga bisa diteruskan ke inbox
    Nanti kalau ingin memakai nomor itu lagi di akun seluler, tinggal pindahkan lagi ke operator yang diinginkan
  • Tidak perlu membayar semahal itu untuk mempertahankan nomor AS demi dipakai dari luar negeri
    Untuk autentikasi dua faktor yang memungkinkan, pindahkan ke aplikasi seperti Google Authenticator, lalu pindahkan nomornya ke Google Voice agar bisa menerima SMS ke nomor lama secara gratis
    Jika sama sekali tidak ingin melibatkan Google, ada banyak aplikasi autentikasi berbasis waktu lain, dan untuk SMS juga bisa memakai www.tossabledigits.com
  • Saya tidak mengerti kenapa membayar semahal itu. Kalau nomornya dipindahkan ke penyedia VoIP, biayanya hanya beberapa dolar per bulan
    Bahkan untuk layanan ponsel biasa pun itu jumlah yang berlebihan. Saya membayar kurang dari 100 dolar per bulan untuk dua lini
  • Saya setuju untuk mencoba memindahkannya ke VoIP
    Dulu saat pindah rumah, nomor telepon kantor pribadi saya tidak diizinkan di wilayah baru, tetapi untungnya bisa dipindahkan ke akun VoIP
    Saat itu internet masih lambat, jadi selama beberapa waktu saya memakai adaptor telepon Ethernet, lalu setelah itu nomor tersebut hanya saya gunakan untuk menerima panggilan. Semua panggilan suara dan faks diteruskan ke email
    Sudah berfungsi dengan baik selama lebih dari 20 tahun. Karena tidak ada perangkat yang perlu dihubungkan, biaya tahunannya juga cukup rendah
    Suatu hari mungkin saya akan menghubungkan telepon dan memanfaatkan internet modern, tetapi saya suka cara yang sekarang dan menyukai fakta bahwa saya tidak terikat pada lokasi tertentu
  • Meski berganti operator, nomor telepon bisa dibawa. Alamat email tidak begitu

• Pengalaman saya juga sama. Secara pribadi, menurut saya UUID acak adalah yang terbaik
  Bahkan hash dari email pertama pengguna pun tidak ideal. Salting saja mungkin tidak cukup, dan orang lain bisa berasumsi bahwa email input apa pun aman untuk di-hash

  • Apakah ada kasus ketika sesuatu seperti natural key yang diajarkan di kelas basis data memang masuk akal?
    Dalam praktiknya, saya selalu memakai integer auto-increment atau string acak/UUID sebagai primary key
  • Satu-satunya cara menjamin identifier “permanen” adalah memilih sesuatu yang sama sekali tidak punya alasan untuk diubah orang
    Ia tidak boleh berhubungan dengan atribut dunia nyata yang dipedulikan orang, seperti nomor telepon, alamat email, ID nasional semacam nomor kependudukan, nama, atau sidik jari
    String acak sangat cocok dengan syarat ini. Integer berurutan juga boleh, tetapi mudah ditebak sehingga mungkin memerlukan langkah keamanan tambahan
  • Saya lebih suka UID berurutan daripada UUID, tetapi intinya tetap sama

• Bagaimana kalau mendukung alamat email public key? Misalnya memperlakukan sesuatu seperti . dan sesuatu seperti . sebagai setara
  Setelah mendaftar dengan salah satunya, pengguna bisa login atau memulihkan akun dengan yang lain. Jika Google melarang saya atau Hotmail bangkrut, saya bisa pergi ke layanan lain, mengautentikasi dengan private key, dan membuka akun yang sama
  Tentu saja perlu ada proses alias untuk memakai nama yang nyaman, tetapi sepertinya klien email harus memetakan alamat seperti itu atau setidaknya melacaknya bersama public key
  Ini juga bisa menjadi pintu masuk untuk email terenkripsi end-to-end. Hal ini hampir tidak pernah benar-benar mapan dalam skala besar
  Agar benar-benar berfungsi, para pemain besar harus mendukungnya, tetapi dari pemikiran singkat tampaknya cukup solid. Kecuali fakta bahwa belum ada yang mendukungnya

  • Saya terkejut Decentralized Identity Foundation belum muncul di thread ini: https://identity.foundation/
    Ada cara-cara baru untuk mengidentifikasi diri dan berkomunikasi di web, dengan memiliki identitas sendiri tanpa bergantung pada penyedia atau otoritas pusat

• Mantan penyedia energi saya, British Gas (milik Centrica), tidak mengizinkan satu alamat email dipakai untuk lebih dari satu alamat fisik
  Setelah pindah, ketika mencoba “menyiapkan” akun online, setiap kali melihat detail alamat saat ini saya mendapat HTTP 500
  Saat menghubungi lewat telepon, mereka mengatakan bahwa meski akun energi di alamat lama sudah ditutup, “alamat email yang sama tidak bisa dipakai untuk beberapa alamat pos”

  • Bisa memakai trik +whatever. Kalau Gmail, trik titik . juga bisa
  • Itu memang cara yang buruk, tetapi jika memakai domain sendiri untuk email, secara praktis bukan masalah

• Saat ini kami sedang mengubah sistem email agar satu akun bisa memiliki beberapa alamat email tertaut
  Salah satu alasan utamanya adalah karena kami menawarkan diskon pelajar. Cara termudah menerapkan diskon ke akun adalah memeriksa apakah emailnya adalah alamat institusi pendidikan. Seperti .edu, .ac.uk, dan semacamnya
  Namun kebanyakan orang tampaknya tidak ingin benar-benar mendaftar dengan email itu. Dengan mengizinkan beberapa email, kita bisa mendapatkan kelebihan dari kedua sisi
  Rasanya seandainya dari awal sudah dibuat seperti ini

  • Perlu diketahui bahwa di AS, banyak orang masih bisa mendapatkan alamat penerusan alumni .edu setelah lulus dari universitas
    Saya punya satu alamat yang cukup keren. Saya mendaftar lebih awal, jadi alamatnya hanya berisi nama saya
    Namun saya tidak banyak memakainya. Pada masa awal, penerusannya kadang tidak stabil, tetapi saya rasa sekarang sudah lebih baik
    Secara realistis, alamat Gmail saya sudah stabil selama hampir puluhan tahun dan sepertinya tidak akan berubah
    Bagaimanapun, alamat edu saya hanya saya beri tahu ke sangat sedikit orang

• Meski bukan yang paling elegan, ada solusi di sisi klien
  Jika membayar dan mempertahankan domain sendiri, Anda bisa mengontrol alias email 100%
  Bahkan jika penyedia saat ini, Google, bangkrut, Anda bisa meng-host email sendiri untuk memulihkan akun dan mempertahankan kepemilikan alias

  • Bagaimana kalau domainnya kedaluwarsa?

• Menurut saya ini masalah backend. ID yang terlihat oleh pengguna boleh saja berupa email, tetapi primary key di dalam data sistem tidak boleh berupa email
  Masih adakah tempat yang melakukan ini? Jangan gunakan hal seperti email sebagai identifier; memiliki tabel lookup yang memetakannya ke ID unik yang sesungguhnya (UUID atau nilai auto-increment berbasis sequence) adalah persoalan desain database yang paling mendasar
  Tulisan itu tidak benar-benar membedakan hal ini, sehingga bisa terbaca seolah-olah pengguna harus menyadari abstraksi ini

  • Benar. Ini seperti soal ujian kelas database tingkat SMA, tetapi ternyata cukup banyak developer dewasa yang tidak berhenti sejenak untuk memikirkan sisi database

• Tidak ada yang abadi. Bahkan hampir tidak ada yang stabil sepanjang umur manusia
  Penanda biometrik yang mudah dipindai pun tidak stabil secara unik pada populasi yang cukup besar
  Alamat email dipilih untuk kegunaan seperti ini karena cukup stabil dan unik dalam jangka waktu yang cukup panjang
  Nomor telepon juga sudah menjadi identifier yang lebih lengket dibanding dulu, dan kini mirip dengan email sebagai identifier yang berguna
  Email dan nomor telepon sama-sama sering hilang, dan sering kali hilang bersamaan
  Alamat email cadangan adalah jawabannya
  Menurut saya GitHub cukup baik dalam menangani identitas, tetapi masih memakai kata sandi. Kata sandi itu buruk