Şifre sıfırlama, şifreyi atlayan bir girişten başka bir şey değildir. Bu yüzden giriş formundaki her kontrolün sıfırlama akışında ya aynen karşılanması ya da bilinçli olarak başka bir kontrolle değiştirilmesi gerekir. Sıfırlama yolu giriş yolundan zayıfsa saldırgan o yolu kullanır. OWASP Forgot Password Cheat Sheet bu işlevi "zafiyetlerin yaygın bir kaynağı" olarak tanımlar ve en bilinen örnek olarak kullanıcı numaralandırmayı (user enumeration) gösterir.
Sıfırlama akışı neden zayıf halka
Başarılı bir giriş bir oturum üretir. OWASP oturum yönetimi rehberine göre kimliği doğrulanmış bir oturum ID'si, uygulamanın kullandığı en güçlü kimlik doğrulama yöntemine geçici olarak eşdeğerdir. Sonunda oturum açan ya da saldırganın seçtiği bir şifreyle biten bir sıfırlama akışı, aynı yetkiyi saldırganın eline verir.
NIST SP 800-63B-4, AAL2 seviyesinde iki farklı kimlik doğrulama faktörünün sahipliğinin ve kontrolünün kanıtlanmasını şart koşar. Giriş iki faktör istiyorsa, yalnızca e-postayla gelen tek bir token isteyen sıfırlama, bu korumayı tek faktörle aşmanın yoludur. Dayandığımız alıntı kurtarma (recovery) konusunu kapsamaz; tam belgede authenticator event management başlıklı bir bölüm vardır.
Bizim kuralımız şudur: ikinci faktörü tanımlı bir hesapta, yeni şifre kabul edilmeden önce o faktör ya da kayıtlı bir kurtarma kodu istenmeli, sıfırlama ise faktörü hiçbir koşulda kaldırmamalı veya değiştirmemelidir.
İstek adımı
Hesap var da olsa yok da olsa aynı yanıtı verin. "Bu adres kayıtlıysa size bir e-posta gönderdik" ifadesi yeterlidir.
Zamanlama da bilgi sızdırır. Bilinmeyen adresler için erken çıkan, bilinen adreslere ise e-posta gönderen bir işleyici, mesaj ne olursa olsun aradaki farkı ele verir. Her istek için aynı mantığı çalıştırın ya da e-postanın gönderimini asenkron bir işe devredin.
Hesap bazında rate limiting, CAPTCHA ya da benzer bir kontrol ekleyin. Bu olmadan saldırgan tek bir hesaba saatte binlerce sıfırlama isteği göndererek kurbanın e-posta veya SMS kutusunu boğabilir. İstek geldi diye hesabı kilitlemeyin ya da değiştirmeyin.
Token
OWASP, bir token veya koddan dört şey bekler:
- kriptografik olarak güvenli bir rastgele algoritmayla üretilmesi,
- kaba kuvvet saldırısını boşa çıkaracak uzunlukta olması,
- güvenli biçimde saklanması,
- tek kullanımlık olması ve uygun bir süre sonunda geçerliliğini yitirmesi.
Rehber uzunluk veya ömür için rakam vermez. Kaynaklardaki en yakın sayı oturum rehberindedir: en az 128 bit entropiye sahip bir CSPRNG, tercihen 160 bit veya daha fazlası. Bu değer oturum token'ları için yazılmıştır; biz sıfırlama token'larına da uyguluyoruz. Ömür için kısa bir değer seçin, yazılı hale getirin ve ona karşı test edin.
"Güvenli saklama" ifadesi katı biçimde yorumlanabilir. Tehdit modelinize token deposunun salt okunur ifşası da giriyorsa, oturum rehberi bir tanımlayıcı ve gizli doğrulayıcı ayrımını anlatır. Sunucu, herkese açık arama tanımlayıcısını ve doğrulayıcının tam SHA-256 hash'ini saklar, hash'leri sabit zamanlı (constant time) karşılaştırır. Tanımlayıcı tek başına asla kanıt sayılmamalıdır. Bunu sıfırlama token'larına uygulamak bizim önerimizdir.
Token'ı e-posta veya SMS gibi bir yan kanaldan iletin, tarayıcıya verilen yanıtta asla döndürmeyin. Token'ı URL içinde taşımak en basit tasarımdır, ancak oturum rehberi URL'deki ID'lerin bağlantılar ve loglar, tarayıcı geçmişi ve yer imleri, Referer header'ı ve arama motorları yoluyla sızabileceği konusunda uyarır. Sıfırlama sayfasında üçüncü taraf içerik ve dışarıya giden bağlantı bulundurmamak yalnızca Referer sızıntısını kapatır. Gerisi için, ilk istekte token'ı kısa ömürlü sunucu tarafı duruma çevirin, temiz bir URL'ye yönlendirin ve o ilk sorgu dizesini erişim loglarına yazmayın.
Sıfırlama adımı
- Kullanıcıya yeni şifreyi iki kez yazdırın ve kayıttaki parola politikasıyla aynı politikaya göre kontrol edin.
- Şifreyi diğer tüm şifrelerle aynı kod yolundan geçirerek hash'leyin.
- Şifre veya e-posta adresi değiştiğinde hesaba ait bekleyen tüm sıfırlama token'larını geçersiz kılın. Aksi halde bir gelen kutusunda duran eski bir e-posta hesabı yeniden sıfırlayabilir.
- Kullanıcıya şifresinin değiştiğini bildiren bir e-posta gönderin. Şifreyi mesaja asla koymayın.
- Kullanıcıyı oturum açmış hale getirmek yerine normal giriş sayfasına yönlendirin. Otomatik giriş, oturum yönetimi kodunu ve dolayısıyla yeni zafiyet ihtimalini artırır.
- Mevcut oturumları sonlandırın ya da en azından bunu önerin.
Hesabın ele geçirildiğinden şüphelenilen durumlarda, siz sonlandırmadıkça saldırganın canlı oturumu şifre değişikliğinden sonra da sürer. Biz sonlandırmayı varsayılan yapardık.
MFA ve ele geçirilmiş hesaplar
Tek başına bir şifre sıfırlama, hesabın kontrolünü geri vermeyebilir. Saldırganın hâlâ aktif bir oturumu olabilir ya da kurtarma bilgilerini veya MFA yöntemlerini değiştirmiş olabilir.
OWASP, yakın zamanda eklenen veya değiştirilen kurtarma bilgilerine tek başına güvenilmemesini söyler. Bunun yerine, hesabın güvence gereksinimlerini karşılayan bir kombinasyonda, daha önce oluşturulmuş bağımsız kanıtlar kullanın; örneğin kaydedilmiş kurtarma kodları. MFA'nın sıfırlanması, OWASP'ın Multifactor Authentication Cheat Sheet belgesinde ayrı bir bölümde ele alınır; bu süreci şifre akışından ayrı tutun.
OWASP Authentication Cheat Sheet kayıtlı e-posta adresinin değiştirilmesini de kapsar. Bu önemlidir, çünkü değiştirilen bir adres gelecekteki tüm sıfırlamaları yönlendirir.
Akışı test etme
| Test | Başarılı sonuç nasıl görünür |
|---|---|
| Gerçek ve var olmayan adres | Aynı mesaj ve durum kodu |
| Adres başına betikle gönderilen istek grubu | Ortanca yanıt süreleri eşleşir |
| Tek hesap için tekrarlanan istekler | Rate limit veya CAPTCHA devreye girer |
| Sıfırlama iste, ardından giriş yap | Hesap kilitlenmez veya değiştirilmez |
| Token iki kez veya süresi dolduktan sonra kullanılır | Deneme başarısız olur |
| Şifre veya e-posta değişikliğinden sonra eski token | Deneme başarısız olur |
| Token'ı URL'de taşıyan sıfırlama sayfası | Üçüncü taraf istek ve dışarı giden bağlantı yok |
| Eski oturum açıkken sıfırlama | Eski oturum sonlandırılır |
| Tanımlı ikinci faktör, yalnızca e-postayla gelen token (kendi kuralımız) | Sıfırlama reddedilir |
| Son yanıt ve e-posta | Otomatik giriş yok, e-postada şifre yok |
Zamanlama satırı için, çok sayıda çalıştırmada ortancaları ve dağılımı karşılaştırın. Bu kontrol, kimlik doğrulama akışına yönelik her sızma testinin kapsamında olmalıdır.
Nereden başlamalı
- Var olan ve var olmayan bir hesap için ayrı ayrı çok sayıda sıfırlama isteği gönderin. Mesajı, durum kodunu ve yanıt süresini karşılaştırın.
- Token üreticisini inceleyin. CSPRNG kullandığını doğrulayın, token'ları tek kullanımlık yapın ve dakika cinsinden söyleyebileceğiniz bir ömür belirleyin.
- İstek uç noktasına hesap bazında rate limiting veya CAPTCHA ekleyin ve bir isteğin hesabı asla kilitlemediğini ya da değiştirmediğini doğrulayın.
- Sıfırlamanın diğer oturumları sonlandırmasını, bekleyen token'ları geçersiz kılmasını ve şifre içermeyen bir bildirim e-postası göndermesini sağlayın. Sıfırlama sayfasının üçüncü taraflardan hiçbir şey yüklemediğini kontrol edin.
- MFA tanımlı bir test hesabı alın ve yalnızca e-postayla gelen token ile sıfırlamayı deneyin. Sıfırlamanın reddedildiğini doğrulayın.
- İkinci faktörü kimin sıfırlayabildiğini veya kaldırabildiğini, hangi kanıtı sunması gerektiğini ve kurtarma sürecinin yakın zamanda değişen bilgileri güvenilmez sayıp saymadığını kontrol edin.
