4 poin oleh GN⁺ 2024-01-01 | 1 komentar | Bagikan ke WhatsApp

Alamat email tidak cocok sebagai pengenal akun yang 'permanen'

  • Menggunakan alamat email sebagai pengenal internal permanen untuk akun menimbulkan masalah. Alamat email seseorang bisa berubah bahkan di dalam organisasi, karena berbagai alasan yang mirip dengan perubahan nama atau informasi login.
  • Organisasi yang tidak mengubah atau mengatur ulang alamat email yang diberikan kepada orang mungkin tidak berkelanjutan secara hukum.
  • Alamat email dapat digunakan ulang atau dialihkan kembali kepada orang tertentu, dan hal ini dapat menimbulkan masalah keamanan.

Pengenal internal seharusnya tidak bermakna

  • Meskipun alamat email perlu diingat untuk pemulihan akun, pengenal akun internal seharusnya tidak memiliki makna. Ini menyederhanakan pengelolaan sistem dalam jangka panjang.
  • Dalam sistem autentikasi seperti OIDC, sebaiknya gunakan ID internal yang unik dan permanen alih-alih alamat email.
  • Memberi terlalu banyak makna pada alamat email dapat menyebabkan masalah keamanan.

Opini GN⁺

  • Poin terpenting dari tulisan ini adalah bahwa menggunakan alamat email sebagai pengenal akun permanen dapat menimbulkan berbagai masalah.
  • Topik ini menarik karena banyak sistem menggunakan alamat email untuk autentikasi pengguna, tetapi tulisan ini menunjukkan bahwa praktik tersebut dapat menimbulkan risiko keamanan potensial dan masalah pengelolaan.
  • Tulisan ini dapat membantu meningkatkan kesadaran para software engineer tentang aspek keamanan dan pengelolaan penting yang perlu dipertimbangkan saat merancang sistem internal.

1 komentar

 
GN⁺ 2024-01-01
Komentar Hacker News
  • Keterbatasan email dan nama pengguna

    • Alamat email bisa berubah, dan orang bisa kehilangan akses ke email lama mereka.
    • Ada ketidakpuasan terhadap nama pengguna, dan orang ingin memilih nama yang tidak harus unik. Misalnya, alih-alih nama seperti user53267.
    • Orang juga bisa kehilangan perangkat, sehingga UUID rahasia yang disimpan di cookie atau passkey pada perangkat saja tidak cukup.
    • Ada orang yang email atau nama penggunanya stabil, tetapi hampir tidak ada yang memakai perangkat utama yang sama selama bertahun-tahun.
    • Sering muncul masalah dengan akun email kerja (first.last@company.com) dan cara perangkat lunak vendor menggunakan 'Masuk dengan Google'.
    • Orang menikah, bercerai, berganti gender, berpindah budaya, dan memilih nama baru. Nama dan alamat email berubah.
    • Hal seperti OIDC mungkin memerlukan API standar yang memungkinkan perubahan nama pengguna dan alamat email.
  • Cara mengatasinya secara pribadi

    • Gmail bisa dikunci secara sewenang-wenang oleh algoritme AI, dan sulit mendapatkan pemulihan saat terjadi masalah.
    • Yahoo bisa meminta verifikasi dengan email lama, sehingga akses dapat hilang.
    • Yahoo/AOL/Tutanota/Protonmail dan lainnya dapat menghapus akun secara otomatis jika tidak sering login.
    • Self-hosting tetap memerlukan email awal, dan jika itu hilang maka akses ke akun hosting juga bisa hilang.
    • Duo push bisa menjadi masalah saat ponsel rusak.
    • Verifikasi SMS bisa berisiko karena ponsel rusak, kehilangan akses ke paket layanan, atau masalah keamanan dari staf.
    • Menggunakan alamat Gmail universitas tampaknya menjadi cara terbaik untuk saat ini. Jika ada masalah, Anda bisa meminta bantuan pusat dukungan universitas.
  • Masalah email dan nomor telepon

    • Email bukan pengenal permanen yang baik, dan menggunakan nomor telepon sebagai bagian dari identifikasi bahkan lebih buruk.
    • Saya telah memakai email yang sama selama hampir 20 tahun lewat domain sendiri, tetapi dalam periode yang sama saya sudah berganti hampir 12 nomor telepon.
    • Saya membayar sekitar $150 per bulan ke AT&T untuk mempertahankan nomor AS saat tinggal di luar negeri.
  • Usulan alamat email berbasis kunci publik

    • Ada ide untuk mendukung alamat email kunci publik (<pk-12345@gmail.com>).
    • Bahkan jika Google atau Hotmail menghentikan layanannya, pengguna tetap bisa mengakses akun yang sama di layanan lain dengan autentikasi memakai kunci pribadi.
    • Klien email dapat memetakan alamat semacam ini atau melacaknya melalui kunci publik.
    • Ide ini memerlukan dukungan skala besar, tetapi layak dipertimbangkan.
  • Penggunaan UUID

    • Ada pendapat bahwa UUID acak adalah pilihan terbaik.
    • Melakukan hash terhadap email awal pengguna mungkin tidak cukup aman hanya dengan salting.
  • Menghubungkan banyak alamat email

    • Sistem email sedang diubah agar beberapa alamat email bisa dihubungkan ke satu akun.
    • Untuk memberikan diskon pelajar, cara termudah adalah memverifikasi email pendidikan, tetapi kebanyakan orang tidak ingin mendaftar dengan email itu.
    • Dengan mengizinkan beberapa email, kita bisa mendapatkan keunggulan dari kedua sisi.
  • Masalah menghubungkan alamat email dengan alamat fisik

    • Contoh pemasok energi yang tidak mengizinkan satu alamat email dipakai untuk beberapa alamat fisik.
    • Ini menimbulkan masalah karena saat menyiapkan akun online, alamat email yang sama tidak bisa digunakan.
  • Solusi sisi klien

    • Anda bisa membayar domain untuk mengendalikan alias email 100%.
    • Bahkan jika penyedia saat ini (Google) bermasalah, Anda tetap bisa meng-host email di server sendiri, mencari akun, dan mempertahankan kepemilikan alias.
  • Masalah identifikasi dan autentikasi

    • Ada masalah karena identifikasi dan autentikasi dibahas seolah-olah sama.
    • Masalah identifikasi pada dasarnya diselesaikan dengan string atau angka unik yang terhubung ke manusia, seperti nama, email, atau kartu identitas.
    • Masalah autentikasi adalah memastikan siapa seseorang sebenarnya, dan ini merupakan salah satu masalah terbesar yang dihadapi teknologi modern.
    • Kita memakai kombinasi kata sandi, lokasi geografis, alamat IP, email, nomor telepon, token keamanan, dan sertifikat, tetapi sistem-sistem ini secara berkala tetap ditembus, dan memperketat keamanan justru berdampak negatif pada pengguna yang sah.
  • Masalah backend

    • Bagi pengguna, email memang terlihat sebagai ID, tetapi di dalam data sistem, email tidak boleh dipakai sebagai primary key.
    • Ini adalah masalah dasar dalam desain basis data: gunakan tabel lookup yang memetakan pengenal seperti email ke ID unik (UUID atau angka auto-increment dari sequence), bukan memakai email itu sendiri.
    • Artikel tersebut tidak menjelaskan pembedaan ini dengan jelas, sehingga bisa terbaca seolah-olah pengguna perlu menyadari abstraksi tersebut.