Parola Sıfırlama ve Hesap Kurtarma: Girişin Zayıf Halkasını Güçlendirmek

Kurtarma isteği hesabı değiştirmesin

Kullanıcı e-posta adresini yazdığında bu yalnızca bir talep olmalıdır. Geçerli doğrulama tamamlanmadan parola, çok faktörlü giriş veya hesap durumu değiştirilmemelidir. OWASP, var olan ve olmayan hesaplarda tutarlı mesaj ve yanıt davranışı; rastgele, süreli ve tek kullanımlık kurtarma belirteçleri önerir. [1]

Arayüzde “bu hesap yok” gibi ayrıntılar göstermek yerine süreci açıklayan dengeli bir mesaj kullanılabilir. Ancak kullanıcıya yardımcı olmak adına gereksiz hesap bilgisi sızdırılmamalıdır. Mesaj dilini, kötüye kullanım sınırlamalarını ve destek yolunu birlikte tasarlayın. Uygun koruma, gerçek kullanıcıyı tamamen erişimsiz bırakmamalıdır.

Bağlantının yetkisini tek işle sınırlayın

Parola sıfırlama bağlantısı genel bir oturum anahtarı gibi kullanılmamalıdır. Önerilen testte bağlantıyla yalnızca izin verilen kurtarma işlemi yapılabilsin. Başka profil bilgileri değiştirilmesin ve başka hesaba geçilemesin. Kullanıldıktan veya süresi dolduktan sonra aynı bağlantının davranışı açık olsun.

OWASP, sıfırlama bağlantılarının güvenilir alan adlarıyla oluşturulmasını ve belirteçlerin gereksiz yere sızmamasını ele alır. [1] Projede bağlantının üretilmesi, gönderilmesi ve açıldığı sayfadaki üçüncü taraf kaynaklar birlikte incelenmelidir. Tam belirteci log veya analitik olayına kopyalamayın.

Kullanıcıya işlem sonucunu açık bildirin

Varsayımsal bir kurumsal portalda kullanıcı parolasını başarıyla yenilesin. Sonraki adım normal giriş mi, ek doğrulama mı? Mevcut oturumlar ne olacak? OWASP, işlem sonrası bilgilendirme ve oturumların geçersizleştirilmesini değerlendirmeyi önerir; yeni parola mesajda gönderilmemelidir. [1]

Ürün tasarımında parola değişikliğiyle e-posta değişikliğini aynı adıma sıkıştırmayın. E-posta hesabına erişemeyen kullanıcı için başka bir kurtarma süreci gerekebilir. Bu süreç destek personelinin yalnızca isim veya kolay bulunabilen bilgilerle bütün korumaları kaldırmasına dayanmamalıdır. Yetki ve kanıt gereksinimi risk düzeyine göre belirlenmelidir.

Örnek kurtarma kabul tablosu

Bu tablo tam güvenlik denetiminin yerine geçmez. Uygulamanın kimlik altyapısı ve riskleriyle genişletilmelidir. Test verilerinde gerçek kullanıcılara e-posta veya SMS gönderilmesin. Başarılı teknik testin güvenlik sertifikası anlamına gelmediği teslim raporunda açık olsun.

Destek ekibinin yetkisini de sınayın

Kurtarma işlemini yönetici başlatabiliyorsa kimin, hangi gerekçeyle ve hangi kapsamda yaptığı kayıtlı olsun. Destek görevlisinin kullanıcının yeni parolasını görmesi gerekmemelidir. İşlem kaydı, gerekli incelemeyi destekleyecek kadar bilgi taşısın; gizli belirtecin kendisini içermesin.

Yayın öncesinde kayıp bağlantı, gecikmiş mesaj, birden fazla talep ve hesap erişimi olmayan kullanıcı senaryolarını tamamlayın. Kullanıcı metinleri ile sunucunun gerçek davranışı uyuşsun. Kurtarma yolu, girişten ayrı ve unutulan bir ekran değil, kimlik sisteminin düzenli test edilen parçası olsun.

Sık sorulan sorular

Güvenlik soruları tek başına yeterli mi?

OWASP bunların tek kurtarma yöntemi olmasını önermiyor. [1] Tahmin edilebilir veya bulunabilir bilgiler hesabın güvenliğini zayıflatabilir; uygun kimlik doğrulama akışı tasarlanmalıdır.

Parola değişince her oturum kapanmalı mı?

Risk ve ürün politikasına göre değerlendirilmelidir. Seçilen davranış kullanıcıya açıklanmalı ve farklı cihazlarda gerçekten çalıştığı test edilmelidir.