Şifre Sıfırlama ve Hesap Kurtarma Güvenliği

Kısa cevap

Hesap kurtarma, login’in daha zayıf bir yan yolu gibi tasarlanmamalıdır. Saldırgan parolayı bilmese bile e-posta/SMS doğrulama akışındaki hesap keşfi, tahmin edilebilir token, tekrar kullanım, destek ekibi bypass’ı veya oturum iptali eksikliğiyle hesabı ele geçirebilir. Güvenli test, talep oluşturulmasından yeni kimlik bilgisinin kullanımına kadar tüm durum geçişlerini izler.

Şifre reseti, e-posta değişimi ve MFA kaybı birbirinden farklı güvence seviyeleri gerektirir. Bu akışları aynı “forgot password” formunun farklı düğmeleri gibi görmek, bir faktörü sıfırlayan kişinin diğer faktörleri de sessizce kaldırmasına yol açabilir.

Hesap varlığını ve istek flood’unu sınırlandırın

Var olan ve olmayan e-posta adreslerine aynı HTTP yanıtını, benzer zamanlama ve aynı kullanıcı deneyimini verin. Yanıt gövdesi, status code, response length ve hız farklarını karşılaştırın. Bir isteğin e-posta gönderdiği mesajı kullanıcıya açıkça hesap bulunduğunu söylemeden iletmek gerekir. Rate limit IP’ye ek olarak hesap, cihaz veya risk sinyali bazında uygulanabilir; ancak saldırganın kurban hesabını kilitleyebildiği bir denial-of-service kontrolüne dönüşmemelidir.

Reset isteği kullanıcının hesabını değiştirmemeli, kilitlememeli veya oturumlarını düşürmemelidir. Değişiklik ancak sahiplik kanıtı ve geçerli reset token’ı sunulduğunda gerçekleşmelidir. Mesaj gönderim kuyruğu ve anti-abuse kontrolleri, hesabın durumunu dışarı sızdırmadan yoğun talepleri yönetmelidir.

Token, URL ve browser sınırları

Reset token’ı kriptografik olarak rastgele, yeterli entropide, tek kullanımlık, kullanıcıya bağlı ve sınırlı süreli olmalıdır. Veritabanında ham token yerine doğrulama için gerekli güvenli temsilini saklayın. Token kullanıldıktan, süresi dolduktan veya yeni token üretildikten sonra öncekinin davranışını test edin. Aynı token ile paralel iki reset isteği başarıya ulaşmamalıdır.

Reset URL’si Host header’ından türetilmemeli; güvenilen sabit origin’den oluşturulmalıdır. HTTPS kullanın. Token query string’deyse browser history, access log, analitik, üçüncü taraf görsel/script ve Referer üzerinden yayılmasını azaltın. Reset sayfasında no-referrer, sıkı CSP ve üçüncü taraf içeriğin kaldırılması değerlendirilebilir. Token ilk kez açıldığında tüketmek bazı e-posta tarayıcılarının linki önceden ziyaret etmesi nedeniyle kullanıcıyı kilitleyebilir; doğrulama adımı kullanıcı aksiyonuyla tamamlanmalıdır.

Reset sonrası oturum ve MFA kurtarma

Yeni parola belirlenince kullanıcıya reseti bildirin; yeni parolayı e-postayla göndermeyin. Eski parolanın ve ele geçirilmiş refresh/session token’larının ne zaman geçersizleştiğini netleştirin. Yüksek riskli hesaplarda tüm oturumları iptal etmek, aktif cihazları göstermek ve tekrar giriş istemek uygun olabilir. Bu karar ürünün riskine göre alınmalı ve kullanıcıya açıkça anlatılmalıdır.

MFA kurtarma, zayıf bir parola resetinden otomatik geçiş olmamalıdır. Backup code’ların tek kullanımlık olduğu, destek ekibinin kimlik doğrulama prosedürünün tutarlı olduğu, recovery email/phone değişiminin bekleme veya ek onay gerektirdiği incelenmelidir. Güvenlik soruları tek başına güçlü kimlik kanıtı değildir; herkese açık veya sosyal medyadan tahmin edilebilir cevaplar kullanmayın.

Test durumu	Güvenli beklenti
Kayıtlı ve kayıtlı olmayan email	Aynı dış yanıt ve benzer zamanlama
Geçerli token iki kez kullanıldı	İkinci kullanım reddedilir
Eski token yeni token sonrası kullanıldı	İptal edilmiş token çalışmaz
Reset sayfası üçüncü taraf içeriği yükler	Token referrer/analytics ile sızmaz
Reset sonrası eski oturum	Politika gereği iptal edilir veya kontrollü yeniden doğrulama ister
MFA kaybı/destek talebi	Belgeli, izlenebilir ve güçlü doğrulama gerekir

Test ve kanıt planı

Parola, e-posta, passkey ve MFA kurtarma akışlarını ayrı diyagramlayın.
Hesap keşfi, timing, flood, token expiry, replay ve eşzamanlı kullanımı test edin.
Link’in host, referrer, browser history, log ve analitik kanallarında sızıntısını inceleyin.
Reset sonrası eski parolayı, session’ı, refresh token’ı ve MFA faktörlerini deneyin.
Destek ekibi müdahalesini test ortamında rol, onay ve audit trail açısından izleyin.
Bulguyu hangi faktörün nasıl atlandığı ve hangi oturumun devam ettiğiyle raporlayın.

Destek, email değişimi ve yüksek riskli hesaplar

Müşteri desteği kurtarma bypass’ı olmamalıdır. Temsilcinin yalnızca e-posta erişimi veya arayanın verdiği kişisel bilgilerle MFA’yı kapatabildiği senaryoyu test edin. Yüksek etkili işlemlerde görev ayrılığı, ikinci onay, doğrulanmış callback kanalı ve değiştirilemez audit kaydı gerekebilir. Kimlik kanıtı sosyal mühendislikle kolayca elde edilebilecek bilgilere dayanmamalıdır.

E-posta adresi değişikliği de kimlik değişimidir. Eski adrese bildirim gönderin, yeni adrese sahiplik doğrulaması isteyin; kritik hesaplarda iki kanaldan onay veya bekleme süresini değerlendirin. Reset akışındaki email normalizasyonu login ve hesap bağlama politikasıyla tutarlı olmalı; farklı adresleri yanlışlıkla aynı hesaba eşlememelidir.

Başarısız ve terk edilmiş kurtarma girişleri

Kurtarma isteği oluşturulduktan sonra kullanıcı e-postadaki linki hiç açmazsa hesabın normal login’i çalışmaya devam etmelidir. Kullanıcı yeni bir reset isteği başlattığında önceki token’ın geçerliliği ürün kararıyla açıkça belirlenmeli ve kullanıcıya çelişkili yönlendirme verilmemelidir. Yanlış token denemeleri hem token brute force’unu sınırlamalı hem de hedef hesabı saldırganın kolayca kilitlemesine imkân vermemelidir. Destek/abuse ekipleri başarısızlıkları kullanıcı adı veya token değeri loglamadan olay hacmi üzerinden inceleyebilmelidir.

Kimlik ve oturum akışlarını daha geniş uygulama güvenliği kapsamına dahil etmek için uygulama güvenliği testimize bakabilirsiniz.