Bir kullanıcı desteğe mesaj atar: "Parolanızın süresi doldu, değiştirmeniz gerekiyor" ve kullanıcı yeni parolasını Company@1403 olarak belirler. Üç ay sonra aynı parola, sadece sonundaki sayı değişmiş. Bu kalıp size tanıdık geliyorsa, sorun kullanıcıda değil; sizin yazdığınız parola politikasındadır. Yıllarca altın standart sayılan zorunlu düzenli parola değişimi, bugün NIST SP 800-63B belgesinde açıkça önerilmemektedir. Nedeni basit: İnsanlar baskı altında parolayı güçlendirmez, sadece daha tahmin edilebilir hale getirir.
Düzenli parola politikası gerçekte neyi bozar
Her 60 veya 90 günde bir zorunlu değişim uyguladığınızda, öngörülebilir üç şey olur. Birincisi, artan kalıp: Summer1403! şuna dönüşür: Summer1403!!. İkincisi, kullanıcının telefonunda veya not defterinde tuttuğu iki ya da üç eski parola arasında gidip gelme. Üçüncüsü, saldırı kanalını kendisi açan bir yığın "parolamı unuttum" talebi.
Ölçümler de bunu gösteriyor. Sızdırılmış parola kümelerinin analizinde, aktif parolaların önemli bir kısmı tam olarak eski parolalarla sonuna eklenmiş tek bir karakterden oluşuyordu. Eski parolanızı bir kez sızdırılmış bir veritabanından ele geçiren saldırgan, basit bir betikle onlarca varyantı dener. Başarı oranı yüksektir, çünkü sizin politikanız ona yardım etmiştir.
Daha az söylenen bir nokta: Zorunlu değişimin operasyonel maliyeti de vardır. Dahili servislerde her parola döndürmesi, .env dosyalarının, CI sırlarının, veritabanı bağlantılarının ve API token'larının güncellenmesi anlamına gelir. Bu iş yarım yapılırsa, eski parola bir yerde kalır ve siz değiştirdiğinizi sanırsınız.
NIST tam olarak ne söylüyor
SP 800-63B belgesi, birçok İran panelinin yaygın uygulamasıyla çelişen üç net öneri içeriyor:
- Düzenli parola değişimini zorunlu kılmayın. Değişim yalnızca sızıntı kanıtı olduğunda gereklidir.
- Karmaşık bileşim yerine uzunluğu tercih edin. 20 karakterlik bir parola ifadesi,
P@ssw0rd!'dan daha güçlüdür. - Parolayı basit bir "büyük harf + sayı + sembol" kalıbına karşı değil, sızdırılmış ve sık kullanılan parola listelerine karşı kontrol edin.
Bunun pratik çevirisi şudur: Her üç ayda bir kullanıcının önüne bir engel koymak yerine, kayıt anında bir kez kötü parolayı engelleyin. Bu hem daha ucuz hem de daha etkilidir.
Pratik alternatif: Kodda ne uygulamalıyız
Sızdırılmış parola kara listesi
En basit uygulama, girilen parolayı Have I Been Pwned gibi listelere karşı kontrol etmektir. Bu API k-anonymity ile çalışır: Parolanın SHA-1 hash'inin yalnızca ilk beş karakterini gönderirsiniz ve karşılaştırmanın geri kalanı kendi tarafınızda yapılır. Tam parola asla sunucudan çıkmaz.
# Manuel test için curl örneği
echo -n "password123" | sha1sum | cut -c1-5
# Örnek çıktı: 482c8
curl -s https://api.pwnedpasswords.com/range/482C8 | grep -i "hash'in geri kalanı"Parola listede varsa, kaydı reddedin ve şu mesajı verin: "Bu parola önceki sızıntılarda görülmüş." Kullanıcı sinirlenmez, çünkü nedenini anlar.
Minimum uzunluk ve bileşim kurallarının kaldırılması
En az 12 karakter koyun, maksimumu 64 veya daha fazla olarak belirleyin (16 değil; kısa sınırlama kullanıcıyı daha kısa parolalara iter). Boşluk ve Unicode karakterlere izin verin. Ve daha önemlisi: Parolayı hash'lemeden önce asla trim() veya Unicode normalizasyonu ile değiştirmeyin, yoksa kullanıcı doğru parolayla bile giriş yapamaz.
Parola döndürme yerine iki faktörlü kimlik doğrulama
Parola sızıntısından endişeleniyorsanız, doğru cevap zorunlu değişim değil, TOTP veya donanım anahtarıdır. 2FA ile sızdırılmış bir parola bile tek başına işe yaramaz. Sunucu yöneticisi erişimi için, genel anahtar kombinasyonu ve parola ile girişin devre dışı bırakılması SSH güvenliği; port değiştirmekten fail2ban ve genel anahtara adlı yazımızda adım adım açıklanmıştır.
Burada hata yapıyorlar
Gerçekten gördüğüm yaygın hata: Ekip, katı parola politikasını kullanıcı paneline uyguluyor, ancak veritabanı parolasını ve API anahtarlarını web sunucusunun kök dizinindeki bir config.php dosyasında bırakıyor. İşareti de açık; erişim logunda GET /config.php veya GET /.env istekleri 200 koduyla kaydediliyor. Yani saldırgan kullanıcı parolalarına hiç yönelmiyor. Arka kapı açıkken giriş kapısına konulan katı parola politikası sadece maliyet getirir.
İkinci hata: Güvenli kurtarma için hiçbir yol olmadan parola değişimini zorunlu kılmak. Sonuç, kullanıcıların parolayı ekip sohbetine göndermesidir. Bu kalıp size tanıdık geliyorsa, Ekiplerde parola yönetimi; sohbette paylaşım neden yasak? yazısını okuyun ve gerçek bir parola yöneticisi kurun.
İki yaklaşımın karşılaştırması
| Kriter | Zorunlu düzenli değişim | Uzunluk + sızıntı kontrolü + 2FA |
|---|---|---|
| Güvenliğe gerçek etkisi | Az, hatta olumsuz | Yüksek |
| Destek üzerindeki yük | Fazla (parola kurtarma) | Az |
| Kullanıcı tepkisi | Politikayı atlatma | Mantıklı kabul |
| Uygulama maliyeti | Neredeyse sıfır | Bir kerelik kodlama |
Seçmek zorunda kalsam, ikinci yaklaşımı seçerim. Birincisini savunulabilir kılan tek koşul, parolanın gerçekten sızmış olması veya hesabın üst düzey erişime sahip olması ve henüz 2FA'yı devreye almamış olmanızdır. O da bir kez, her 90 günde bir değil.
Parola sızdığında ne yapmalıyız
Süreçsiz politika yarımdır. Doğru yol şudur:
- O kullanıcının tüm aktif oturumlarını geçersiz kılın, sadece parolayı değiştirmeyin. JWT token'ları ve veritabanı session'ları ayrı ayrı geçersiz kılınır.
- Denetim logunda sızıntı anından itibaren ne olduğunu araştırın. Denetim logunuz yoksa veya değiştirilebilirse, Denetim logu nedir ve nasıl bozulmadan koruruz? başlangıç noktasıdır.
- API anahtarlarını ve servis token'larını da döndürün. Parola, giriş yollarından yalnızca biridir.
- Kullanıcıya ne olduğunu söyleyin. Gizleme, bir sonraki sefer parolayı güvenli bir yerde tutmamasına neden olur.
Çalışanların dışarıdan erişimi için, veritabanı portunu internete açmak yerine tünel kullanın; Çalışanların güvenli erişimi için kapsamlı kurumsal VPN rehberi tam da bu senaryoyu kapsıyor.
Unutulan şeyler
Parolayı MD5 veya düz SHA-1 ile hash'leme hâlâ bazı eski projelerde görülüyor. Veritabanınız sızarsa, bu hash'ler birkaç saat içinde GPU ile kırılır. Uygun maliyetle Argon2id veya bcrypt kullanın ve parametreleri kodda sabit tutmayın ki sonradan artırılabilsinler.
Hız sınırlaması da ciddidir. Giriş endpoint'inde rate limit olmadan parola kara listesi işe yaramaz, çünkü saldırgan binlerce tahmin yapabilir. Her IP ve her hesap için 15 dakikada 10 deneme gibi basit bir sınırlama, otomatik saldırıların çoğunu durdurur. Saldırı trafiği sınırı aşarsa, DDoS koruması bir sonraki katmandır.
Ve operasyonel bir not: Parola politikasındaki her değişikliği yalnızca e-postada değil, kendi dokümantasyon ve bilgi tabanınızda yazın. Altı ay sonra, politikayı uygulaması gereken kişi aynı dokümantasyonu okuyacaktır.
Özel veya bulut sunucuda çalışıyorsanız ve kimlik doğrulama ile izleme katmanlarını tek seferde ve karmaşa olmadan kurmak istiyorsanız, ServerNet sunucu güvenlik hizmetleri tam da bu yolu kapsıyor. Ama her şeyden önce, zorunlu değişim kuralını kullanıcı panelinizden kaldırın. Bugün uygulayabileceğiniz ve güvenliği artıracak tek değişiklik budur.
Sık sorulan sorular
Düzenli parola değişimi tamamen yasak mı?
Hayır yasak değil, ancak varsayılan politika olarak önerilmez. NIST, 2017'den beri SP 800-63B'de zorunlu değişimin yalnızca sızıntı kanıtı varsa uygulanması gerektiğini söylüyor. Kuruluşunuzun düzenleyici bir zorunluluğu varsa, en azından aralığı uzatın ve aynı zamanda 2FA'yı zorunlu kılın.
Minimum parola uzunluğu ne olmalı?
Normal hesaplar için 12 karakter, yönetici hesapları için 16 karakter veya daha fazla. Sayıdan daha önemlisi, uzun parola ifadelerine izin vermek ve parolayı sızıntı listelerine karşı kontrol etmektir. Maksimum uzunluk sınırını da 64 karakterin altına koymayın.
Kullanıcılarımın parolasının sızdığını nasıl anlarım?
Giriş veya kayıt anında sızdırılmış parola listesi API'si ile kontrol edin ve denetim logunda bilinmeyen IP'lerden gelen başarılı girişleri arayın. Logları değiştirilebilir tutuyorsanız, bu tespit neredeyse işe yaramaz.
Ekip parola yöneticisi parola politikasının yerini alır mı?
Onun tamamlayıcısıdır, alternatifi değil. Parola yöneticisi sohbette parola paylaşımını engeller ve servis parolalarının döndürülmesini kolaylaştırır, ancak uzunluk, 2FA ve sızıntıya müdahale konusundaki karar hâlâ sizin sorumluluğunuzdadır.
Yorumlar 0
Henüz yorum yok — ilk siz olun!