Hani, Bakın şimdi… Kayıt formu deyince çoğu kişinin aklına tasarım geliyor. Birkaç input, bir buton, belki küçük bir “şifre en az 8 karakter olmalı” uyarısı. Ama işin aslı şu ki, o minik alan bazen tüm sistemin en zayıf halkası oluyor — hem de kimse farkında olmadan. Geçen ay Kadıköy’de bir ürün toplantısında tam da bunu konuştuk; ekip “kural koyduk ya, tamamdır” havasındaydı, herkes rahat görünüyordu. Ben de masada şunu sordum: Peki bu kurallar gerçekten saldırganı mı durduruyor, yoksa sadece kullanıcıya göz boyama mı yapıyor?
Size bir şey söyleyeyim, Kısa cevap: çoğu zaman ikinci seçenek. Geleneksel şifre kuralları kötü niyetle yazılmadı tabii ki — ama odağı yanlış yere kaydırdılar. Kullanıcıya “büyük harf koy, sembol ekle, rakam serpiştir” dedikçe daha kuvvetli şifre üretildiğini sandık. Oysa makineler için önemli olan şey görünüş değil; tahmin edilme ihtimali. Yani “kuvvetli görünen” şifre ile gerçekten zor kırılan şifre… aynı şey değil bunlar.
Neden eski şifre kuralları tökezliyor?
Eskiden mantık basitti. Şifre kısa olmasın, içine biraz karmaşa katalım, tamam. Bu yaklaşımın hâlâ küçük bir faydası var elbette; en azından “123456” gibi komik örnekleri biraz törpülüyor, bunu yadsımıyorum. Ama saldırganlar da boş durmuyor — artık brute force araçları sadece rastgele kombinasyon denemiyor, sızmış parola listelerini, popüler kalıpları. İlginç, değil mi? Kullanıcıların birbirine şaşırtıcı biçimde benzeyen seçimlerini tek tek tarıyor.
Peki neden?
Geçen yıl Şişli’de çalışan bir arkadaşım bana kendi startup’larında yaşadıkları olayı anlattı. Kullanıcılar çok düzgün formatta ama berbat içerikte parolalar seçiyormuş: “P@ssword1”, “Admin123!”, “Qwerty!23″… Form teknik olarak başarılı görünüyormuş. Güvenlik açısından durum iç açıcı değilmiş. Hatta bazı hesaplar daha ilk haftada ele geçirilmiş. Yani kural var diye güven var sanmayın; bazen kural sadece dekor oluyor.
Hani, İşin can sıkıcı tarafı şu: insanlar kısa ve hatırlaması kolay şeylere yöneliyor. Bunu suçlamak da kolay değil hani. Her yerde ayrı parola isteyen sistemler yüzünden herkes köşe bucak çözüm arıyor, doğal bu. Sonra ortaya öyle tahmin edilebilir kombinasyonlar çıkıyor ki… saldırgan için adeta açık büfe.
Sorun görünüşte değil, tahmin edilebilirlikte
Bir şifrenin içinde sembol olması tek başına pek bir şey ifade etmiyor. Mesela P@ssword1 dışarıdan bakınca kural uyumlu duruyor — ama gerçek dünyada neredeyse ilk denenecek adaylardan biri bu, çünkü insan zihni kalıp sever. Saldırgan araçları da tam olarak bunu biliyor, üstüne üstlük bu listeler sürekli güncelleniyor.
Bunu biraz açayım.
NIST’in yıllar önce güncellediği öneriler tam burada devreye giriyor: daha uzun minimum uzunluklar ve bilinen, beklenen ya da sızmış parolaların engellenmesi. Kâğıt üstünde basit gibi görünüyor. Pratikte baya işe yarıyor. En azından kullanıcıyı sahte güven hissinden çıkarıyor — ki bu bile başlı başına önemli.
Asıl hedefiniz şifrenin “güzel görünmesi” değil, saldırganın onu tahmin etmesini zorlaştırmak olmalı.
zxcvbn neden klasik kontrollerden daha iyi?
Bir ara ben de kendi projelerimde klasik doğrulama kullandım; hani minimum 8 karakter, büyük harf şartı falan… 2023’te Ankara’da yaptığım bir yan projede bunu test ederken fark ettim ki kullanıcıların çoğu gereksiz yere sinirleniyor. Güvenlik seviyesi beklediğim kadar artmıyor. Sonra zxcvbn’ye geçtim. Tablo değişti.
Peki neden?
zxcvbn’nin güzel tarafı şu: şifreyi tek tek kurallara göre yargılamıyor, onun yerine kalıp tanıyor. “Bu bir tarih mi?”, “Bu klavye dizilimi mi?”, “Burada meşhur bir kelime ters çevrilmiş mi?” gibi sorular soruyor — ve bu sorular aslında saldırganın da sorduğu sorular, tam olarak. Böylece kaba kuvvetle ne kadar sürede kırılabileceğine dair çok daha gerçekçi bir fikir ortaya çıkıyor. Daha fazla bilgi için Geliştiriciler İçin En İyi Clipboard Manager: 2026 Rehberi yazımıza bakabilirsiniz.
Bastion demo tarzı araçlarda gördüğüm şey de hep aynı oldu: İnsanların çok beğendiği bazı parolalar aslında dakikalar içinde kırılabiliyor… hatta bazen saniyeler içinde bile düşebiliyorlar! Öte yandan uzun ve alışılmadık ifadeler — mesela correct-horse-battery-staple benzeri yapılar — çok daha dirençli çıkıyor. Şaşırdım açıkçası ilk gördüğümde.
zxcvbn neye bakıyor?
- En yaygın parolalar ve isimler
- Klavye desenleri:
qwerty,123456, hatta sıra dışı ama tekrar eden diziler - Sembol dönüşümleri:
@ilea,3ilee— bunu es geçmeyin - Ters çevrilmiş ya da tekrarlayan karakter kümeleri
- Sızmış parola havuzlarında görülmüş örnekler
Kayıt formunda neyi değiştirmelisiniz?
Lafı gevelemeden söyleyeyim: yalnızca “karmaşıklık kuralı” koymak yetmiyor. Öncelikle minimum uzunluğu anlamlı seviyeye çekmek lazım. Sekiz karakter bugün birçok senaryoda idare eder seviyede bile sayılmıyor artık; özellikle kamuya açık servislerde veya müşteri hesabı tutan uygulamalarda, yani tam da çoğumuzun üzerine çalıştığı alanlarda, daha temkinli olmak gerekiyor.
E tabi iş sadece uzunluk da değil. Sızmış veya çok yaygın parolaları kara listeyle engellemek ciddi fark yaratır. Kullanıcının seçtiği şey zaten internette milyon kez görülmüşse, o hesabın kapısı aralık demektir. Bu kadar basit. Daha fazla bilgi için Ateşkes Piyasayı Nasıl Vurdu: 427 Milyonluk Kısa Sıkışma yazımıza bakabilirsiniz.
| Yaklaşım | Artısı | Eksisi |
|---|---|---|
| Klasik kurallar (büyük harf + rakam + sembol) |
Kolay uygulanır | Görünüşe odaklanır, gerçek gücü ölçmez |
| Uzunluk + kara liste + zxcvbn | Daha gerçekçi risk ölçer | Biraz daha fazla entegrasyon ister |
| Parola yöneticisi teşvik etmek | Kullanıcı yükünü azaltır | Her kullanıcı hemen benimsemeyebilir |
Küçük bir startup için bu işi sade tutmak mantıklı olabilir; önce kuvvetli varsayılanlar koyarsınız, sonra zxcvbn ile anlık geri bildirim verirsiniz, biter gider. Kurumsal tarafta ise hikâye farklılaşıyor — burada kimlik sağlayıcı entegrasyonu, MFA zorunluluğu. Merkezi politika yönetimi devreye girer, iş biraz daha karmaşıklaşır. Daha fazla bilgi için Yapay Zekâ Kodlamada Neden Adım Adım Kazanıyor? yazımıza bakabilirsiniz.
Kod tarafında nasıl düşünmeli?
Aşağıdaki yapı kaba ama iş görür bir mantığı gösteriyor:
// Basit yaklaşım fikri
if (password.length < minLength) {
return "Şifre biraz kısa kaldı.";
}
if (isCommonPassword(password)) {
return "Bu şifre çok tahmin edilebilir.";
}
const result = zxcvbn(password);
if (result.score < threshold) {
return result.feedback.warning || "Daha kuvvetli bir parola deneyin.";
}Açık konuşayım: bunun üstüne rate limiting ve hesap kilitleme politikası eklemezseniz resim eksik kalır. Çünkü sağlam parola tek başına mucize yaratmaz; giriş denemelerini sınırlamazsanız saldırgan yine yorulana kadar dener. Hatta yorulmaz, script yorulur mu ki?
Sadece parola yetmez mi? Yetmez.
Bence en büyük hayal kırıklığı tam burada yaşanıyor. İnsanlar sanki sağlam parola koyunca mesele bitiyormuş gibi davranıyor —. Günümüz tehdit ortamında bu yeterli değil, maalesef. Siz hiç denediniz mi? Hele bir de de phishing kampanyaları yüzünden iyi parolanın değeri bile düşebiliyor, çünkü kullanıcı zaten gönüllü şekilde bilgiyi teslim ediyor; parolanın ne kadar sağlam olduğunun hiçbir önemi kalmıyor o noktada.
Bunun için MFA hâlâ çok değerli ama onu da doğru kurgulamak gerekiyor. SMS tabanlı doğrulama bazı senaryolarda iş görür fakat her ortamda ideal değildir — özellikle yüksek riskli hesaplarda. Uygulama tabanlı kodlar veya passkey çözümleri daha temiz duruyor (yanlış duymadınız). Denediniz mi hiç passkey’i? Alışınca baya rahat aslında.
Kullanıcı deneyimini bozmayın
Şunu söyleyeyim, Bazı ekipler güvenliği artıracağız diye kayıt ekranını ceza tahtasına çeviriyor. Bu da başka uçta hata demek oluyor zaten (buna dikkat edin). Kullanıcıya her adımda bağırırsanız o kişi ya formu terk eder ya da yine kolay yolu bulur —. Genellikle ikincisini tercih ediyor, tecrübeden söylüyorum. Honor Win 2 Sızdı: Batarya ve Ekranda Büyük Oyun yazımızda da bu konuya değinmiştik. RAG Neden Gerekli? LLM’lerin Kör Noktası yazımızda da bu konuya değinmiştik.
Daha iyi yöntem şu olabilir:
- Anlık geri bildirim verin;
- Zayıf parolanın neden kötü olduğunu söyleyin;
- Mümkünse parola yöneticisini teşvik edin;
- MFA’yı nazikçe ama net biçimde zorunlu hale getirin.
Küçük ekipler ve büyük kurumlar için fark nerede?
Küçük ekiplerde hız baskısı var. Biliyorum, çünkü iki ayrı startup’ta ürün çıkarırken aynı paniği yaşadık — “şimdi bununla mı uğraşacağız” bakışlarını gördüm. Burada yapılacak en mantıklı şey düşük maliyetle yüksek etki almak; yani doğrudan kompleks politika yazmak yerine sağlam varsayılanlarla başlamak çok daha akıllıca olur, sonra üstüne koyarsın.
Büyük kurumlarda ise risk profili değişir. Tek sorun bireysel hesap çalınması değildir; veri sızıntısı, itibar kaybı ve uyumluluk cezası da masada. Bu yüzden raporlama katmanı olan sistemler tercih edilir. Kim hangi parolayı seçti? Kaçı kara listeye takıldı? Kaçı MFA açtı? Bunların hepsi görünür olmalı — hem iç denetim hem de dışarıya hesap verebilmek için.
Neyse, uzatmayalım. Özet şu: küçük takımda basit ama doğru; kurumsalda ise katmanlı ve ölçümlenebilir yaklaşım gerekir. İkisi de aynı temel prensibe dayanıyor aslında — kullanıcının seçtiği metnin görünüşüne değil, saldırı karşısındaki direncine bakmak. Hep bu.
Sıkça Sorulan Sorular
Klasik şifre kuralları neden yetersiz kalıyor?
Bilmem anlatabiliyor muyum, Çünkü çoğu zaman yalnızca biçime bakıyorlar. Büyük harf veya sembol eklemek şifreyi otomatik olarak kuvvetli yapmaz. Saldırganlar kalıp tanıyabildiği için asıl mesele tahmin edilme ihtimalidir.
Zxcvbn gerçekten gerekli mi?
Zorunlu değil ama baya işe yarar.
Burada, hele bir de de de de de kayıt formlarında kullanıcıya anlamlı geri bildirim vermek istiyorsanız güzel bir seçenek.
Basit kurallardan daha gerçekçi sonuç verir.
MFA varsa güçlü parola hâlâ önemli mi?
Açık konuşayım, Evet.
MFA riski ciddi biçimde azaltır ama tek başına her şeyi çözmez.
Güçlü parola hâlâ ilk savunma hattıdır; ikisi birlikte çok daha iyi çalışır.
Sızmış parolaları nasıl engelleyebilirim?
Garip gelecek ama, Kara liste kullanabilirsiniz.
Hazır veri kümeleri veya hizmet tabanlı kontrol mekanizmalarıyla sık görülen parolaları reddetmek mümkün.
Bu yöntem özellikle yeniden kullanılan zayıf parolaları keser.
p>NIST Digital Identity Guidelines
OWASP Authentication Cheat Sheet
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
