E-posta adresi, hesabın 'kalıcı' tanımlayıcısı olarak uygun değil

E-posta adresleri hesapların 'kalıcı' tanımlayıcısı olarak uygun değil

• E-posta adreslerini hesapların kalıcı iç tanımlayıcısı olarak kullanmak sorunludur. İnsanların e-posta adresleri, bunun nedenleri ad veya giriş bilgilerinin değişmesiyle benzer olsa bile, kurum içinde dahi değişebilir.
• Kurumların kişilere atanmış e-posta adreslerini değiştirmemesi veya yeniden ayarlamaması hukuken sürdürülebilir olmayabilir.
• E-posta adresleri yeniden kullanılabilir veya belirli bir kişiye yeniden atanabilir; bu da güvenlik sorunlarına yol açabilir.

İç tanımlayıcılar anlamsız olmalı

• Hesap kurtarma için e-posta adresini hatırlamak gerekse bile, iç hesap tanımlayıcısı anlamsız olmalıdır. Bu, uzun vadede sistem yönetimini sadeleştirir.
• OIDC gibi kimlik doğrulama sistemlerinde e-posta adresi yerine benzersiz ve kalıcı bir iç ID kullanılmalıdır.
• E-posta adresine gereğinden fazla anlam yüklemek güvenlik sorunlarına neden olabilir.

GN⁺ görüşü

• Bu yazıdaki en önemli nokta, e-posta adresini kalıcı hesap tanımlayıcısı olarak kullanmanın çeşitli sorunlara yol açabilmesidir.
• Bu konunun ilginç olmasının nedeni, birçok sistemin kullanıcı kimlik doğrulaması için e-posta adreslerini kullanmasına rağmen, bu yazının böyle bir uygulamanın potansiyel güvenlik riskleri ve yönetimsel sorunlar yaratabileceğine işaret etmesidir.
• Bu yazı, yazılım mühendislerinin iç sistem tasarımında dikkate alması gereken önemli güvenlik ve yönetim boyutlarına dair farkındalığı artırmaya yardımcı olabilir.

[GN⁺]

Hacker News görüşü

• E-posta ve kullanıcı adlarının sınırlılıkları

  • E-posta adresleri değişebilir ve insanlar eski e-postalarına erişimi kaybedebilir.
  • Kullanıcı adlarından memnuniyetsizlik var; insanlar user53267 gibi adlar yerine benzersiz olmayan isimler seçmek istiyor.
  • Cihaz kaybetme durumu da var; çerezlerde saklanan gizli UUID’ler ya da yalnızca cihazdaki passkey’ler yeterli değil.
  • E-postası ya da kullanıcı adı istikrarlı olan insanlar var, ancak aynı birincil cihazı yıllarca kullanan insan neredeyse yok.
  • Kurumsal e-posta hesapları ([e-mail]) ve satıcı yazılımlarının "Google ile giriş yap" kullanma biçimi sık sık sorun çıkarıyor.
  • İnsanlar evleniyor, boşanıyor, cinsiyet geçişi yapıyor, kültür değiştiriyor ve yeni isimler seçiyor. İsimler ve e-posta adresleri değişiyor.
  • OIDC gibi şeyler, kullanıcı adı ve e-posta adreslerinin değiştirilebilmesi için standart bir API’ye ihtiyaç duyabilir.

• Kişisel başa çıkma yöntemleri

  • Gmail, yapay zeka algoritmaları tarafından keyfi olarak kilitlenebilir ve bir sorun çıktığında çözüm bulmak zor olabilir.
  • Yahoo, eski bir e-posta ile doğrulama isteyebilir ve bu da erişim kaybına yol açabilir.
  • Yahoo/AOL/Tutanota/Protonmail gibi servisler, sık giriş yapılmazsa hesabı otomatik olarak silebilir.
  • Self-hosting, başlangıçta bir e-posta gerektirir; bu kaybedilirse hosting hesabına erişim de kaybedilebilir.
  • Duo push, telefon bozulduğunda sorun yaratabilir.
  • SMS doğrulaması; telefon arızası, tarifeye erişim kaybı ya da çalışan kaynaklı güvenlik sorunları nedeniyle riskli olabilir.
  • Şimdilik en iyi yöntem üniversite Gmail adresi kullanmak gibi görünüyor. Bir sorun olduğunda üniversitenin destek merkezinden yardım istenebilir.

• E-posta ve telefon numarasının sorunları

  • E-posta kalıcı bir tanımlayıcı olarak iyi değil; telefon numarasını kimliğin bir parçası olarak kullanmak ise daha da kötü.
  • Kendi alan adı üzerinden neredeyse 20 yıldır aynı e-postayı kullanıyor olsa da, aynı sürede neredeyse 12 telefon numarası değiştirmiş.
  • Yurt dışında yaşarken bile ABD numarasını korumak için AT&T’ye ayda yaklaşık $150 ödüyor.

• Açık anahtar e-posta adresi önerisi

  • Açık anahtar e-posta adreslerini (<[e-mail]>) destekleme fikri öne sürülüyor.
  • Google ya da Hotmail hizmeti kapatsa bile, başka bir serviste özel anahtarla doğrulanıp aynı hesaba erişilebilecek.
  • E-posta istemcilerinin bu adresleri eşleştirebilmesi ya da açık anahtar üzerinden takip edebilmesi sağlanabilir.
  • Bu fikir geniş çaplı destek gerektiriyor, ancak düşünmeye değer.

• UUID kullanımı

  • Rastgele UUID’nin en iyi seçenek olduğu görüşü var.
  • Kullanıcının ilk e-postasını hash’lemek, yalnızca salting ile yeterince güvenli olmayabilir.

• Birden fazla e-posta adresi bağlama

  • Hesaba birden fazla e-posta adresi bağlanabilmesi için e-posta sistemi değiştiriliyor.
  • Öğrenci indirimi sunmak için eğitim e-postasını doğrulamak en kolay yol, ancak çoğu insan o e-postayla kayıt olmak istemiyor.
  • Birden fazla e-postaya izin vererek iki dünyanın da avantajı elde edilebilir.

• E-posta adresi ile fiziksel adresi bağlama sorunu

  • Bir enerji sağlayıcısının, tek bir e-posta adresinin birden fazla fiziksel adreste kullanılmasına izin vermemesi örneği.
  • Online hesap oluştururken aynı e-posta adresi kullanılamadığı için sorun çıkıyor.

• İstemci taraflı çözümler

  • Alan adı için ödeme yaparak e-posta alias’larını %100 kontrol etmek mümkün.
  • Mevcut sağlayıcıda (Google) sorun çıksa bile, kendi sunucusunda e-postayı barındırarak hesapları kurtarmak ve alias sahipliğini korumak mümkün olabilir.

• Kimlik belirleme ve kimlik doğrulama sorunu

  • Kimlik belirleme ile kimlik doğrulamayı birbirine karıştırarak tartışma hatası yapılıyor.
  • Kimlik belirleme sorunu; isim, e-posta, kimlik belgesi gibi insanla bağlantılı benzersiz string’ler veya numaralarla fiilen çözülmüş durumda.
  • Kimlik doğrulama sorunu ise gerçekten o kişi olup olmadığını teyit etmek ve modern teknolojinin karşı karşıya olduğu en büyük sorunlardan biri.
  • Parola, coğrafi konum, IP adresi, e-posta, telefon numarası, güvenlik token’ları ve sertifikaların birleşimi kullanılıyor; ancak bu sistemler düzenli olarak ihlal ediliyor ve güvenlik artırıldıkça meşru kullanıcılar olumsuz etkileniyor.

• Backend sorunu

  • Kullanıcı için e-posta bir ID olabilir, ancak sistem verilerinde e-posta birincil anahtar olarak kullanılmamalı.
  • Bu, veritabanı tasarımının temel bir meselesi: e-posta gibi tanımlayıcıları doğrudan kullanmak yerine, benzersiz bir ID’ye (UUID veya sequence’dan otomatik artan değer) eşleyen bir lookup tablosu kullanılmalı.
  • Makale bu ayrımı netleştirmediği için, kullanıcıların bu soyutlamanın farkında olması gerekiyormuş gibi okunabiliyor.