--- title: "Parola Saklama ve Oturum Güvenliği: Hash, Tuz ve Token Ömrü" url: "https://cilginyazilim.com/blog/parola-saklama-ve-oturum-guvenligi" description: "Parolalar nasıl saklanmalı? Modern hash algoritmaları, tuzlama, oturum çerezleri, token ömrü, çıkış yapma ve parola sıfırlama akışında yapılan hatalar." published: "2026-08-10T13:00:00+03:00" modified: "2026-08-10T13:01:01+03:00" author: "superadmin" category: "Siber Güvenlik" tags: ["jwt", "siber güvenlik", "kimlik doğrulama", "parola saklama", "hash", "bcrypt", "argon2", "oturum yönetimi", "çerez güvenliği", "iki adımlı doğrulama", "parola sıfırlama", "token", "veri sızıntısı"] site: "CılgınYazılım" language: "tr" --- # Parola Saklama ve Oturum Güvenliği: Hash, Tuz ve Token Ömrü Veritabanı sızdığında zararın büyüklüğünü belirleyen tek şey, parolaları nasıl sakladığınızdır. **Parola saklama**, güvenlikte sonucu en net olan konudur: veritabanınız sızdığında kullanıcılarınızın başına ne geleceğini doğrudan bu karar belirler. Doğru yapıldığında sızıntı ciddi ama yönetilebilir bir olaydır; yanlış yapıldığında ise milyonlarca hesap dakikalar içinde ele geçirilir — üstelik aynı parolayı başka sitelerde kullanan kullanıcılar için zincirleme bir felakete dönüşür. ![Parola ve oturum güvenliği kuralları](https://cilginyazilim.com/uploads/blog/2026/08/parola-saklama-ve-oturum-guvenligi-ozet.png) *Şifreleme geri döndürülebilir; parolalar için istediğiniz şey tam tersidir.* ## Şifreleme değil, hash En temel ayrım budur. Şifreleme geri döndürülebilir: anahtara sahip olan orijinal parolayı elde eder. Hash ise tek yönlüdür. Parolalar için istediğiniz şey tam olarak budur — sizin bile kullanıcının parolasını bilmemeniz gerekir. İkinci ayrım hızdır. `md5` ve `sha1` gibi algoritmalar hızlı olacak şekilde tasarlanmıştır ve bu, parola için bir kusurdur: saldırgan saniyede milyarlarca deneme yapabilir. Parola hash'leme için kasıtlı olarak *yavaş* ve bellek maliyeti yüksek algoritmalar kullanılır. Günümüzde bcrypt makul bir taban, argon2 ise tercih edilen seçenektir. Tuz (salt), aynı parolanın farklı kullanıcılarda farklı hash üretmesini sağlar ve hazır tablolarla toplu kırmayı engeller. İyi haber: modern hash fonksiyonları tuzu kendileri üretip sonucun içine gömer — elle tuz yönetmeye çalışmak genellikle hata kaynağıdır. ## Maliyet parametresi ve yükseltme Hash algoritmalarının bir maliyet ayarı vardır; donanım hızlandıkça bu değerin yükseltilmesi gerekir. Pratik yaklaşım, kullanıcı her giriş yaptığında saklanan hash'in güncel parametrelerle üretilip üretilmediğini kontrol etmek ve gerekirse sessizce yeniden hash'lemektir. Böylece kullanıcıya hiçbir şey yaptırmadan tüm veritabanı zamanla güçlenir. ## Parola kuralları: eski alışkanlıkları bırakmak Uzun yıllar savunulan "en az bir büyük harf, bir rakam, bir sembol ve 90 günde bir değiştir" kuralları bugün önerilmiyor. Sebebi ölçülmüş bir davranıştır: karmaşık kurallar ve zorunlu değişim, kullanıcıları tahmin edilebilir kalıplara (`Parola2026!`) ve parolayı bir yere yazmaya yönlendirir. Güncel öneri daha basittir: uzunluğa öncelik verin (12+ karakter), bilinen sızıntı listelerindeki parolaları reddedin, zorunlu periyodik değişimi kaldırın ve iki adımlı doğrulamayı teşvik edin. İkinci faktör, parola gücünden çok daha belirleyicidir. Kaba kuvvet denemelerine karşı katmanlı savunma için [ilgili yazımıza](https://cilginyazilim.com/blog/kaba-kuvvet-saldirilarina-katmanli-savunma) bakabilirsiniz. ## Oturum yönetimi: giriş bittikten sonra başlayan iş Doğru hash'lenmiş parola, zayıf bir oturum yönetimiyle birlikte anlamını yitirir. Kritik noktalar şunlardır: - **HTTPS zorunludur.** Sertifikanın süresi sessizce dolduğunda oturum güvenliği de anlamını yitirir; [sertifika yenileme otomasyonu](https://cilginyazilim.com/blog/ssl-sertifikasi-yenileme-otomasyonu) bu yüzden güvenlik işidir. - **Çerez bayrakları:** Oturum çerezi `HttpOnly` (JavaScript okuyamaz), `Secure` (yalnızca HTTPS) ve uygun bir `SameSite` değeriyle işaretlenmelidir. - **Giriş sonrası kimlik yenileme:** Başarılı girişte oturum kimliği yeniden üretilmelidir; aksi halde oturum sabitleme saldırısı mümkün olur. - **Gerçek çıkış:** Çıkış yalnızca tarayıcıdaki çerezi silmemeli, sunucu tarafındaki oturumu da geçersiz kılmalıdır. - **Hassas işlemde yeniden doğrulama:** Parola değiştirme, e-posta güncelleme ve ödeme bilgisi işlemlerinde mevcut parola yeniden istenmelidir. ## Token tabanlı kimlik doğrulama ve iptal sorunu API'ler için yaygın olan imzalı token yaklaşımının bilinmesi gereken bir kısıtı vardır: token kendi kendini doğruladığı için, süresi dolana kadar iptal edilmesi kolay değildir. Kullanıcı çıkış yaptığında veya hesap askıya alındığında token teknik olarak geçerli kalmaya devam eder. Pratik çözüm iki katmanlıdır: erişim token'ının ömrünü kısa tutmak (dakikalar) ve yenileme token'ını sunucu tarafında saklayıp iptal edilebilir kılmak. "Tüm cihazlardan çıkış yap" özelliği ancak bu ikinci katman varsa gerçekten çalışır. API tarafındaki genel tasarım kararları için [REST API tasarımı](https://cilginyazilim.com/blog/rest-api-tasarimi-iyi-bir-api-nasil-olur) yazımıza bakabilirsiniz. ## Parola sıfırlama: en çok istismar edilen akış Saldırganlar genellikle giriş ekranını değil, sıfırlama akışını hedefler. Güvenli bir akışın özellikleri şunlardır: bağlantıda kriptografik olarak rastgele ve yeterince uzun bir belirteç bulunur, belirteç veritabanında hash'lenmiş olarak saklanır, kısa süre içinde (tipik olarak bir saat) geçersizleşir ve bir kez kullanıldığında iptal edilir. Sık yapılan bir hata da bilgi sızdırmaktır: "Bu e-posta kayıtlı değil" mesajı, saldırgana hangi hesapların var olduğunu söyler. Her durumda aynı nötr mesajı göstermek doğru davranıştır. Parola değiştiğinde kullanıcıya bilgilendirme e-postası göndermek ve diğer oturumları sonlandırmak da standart olmalıdır. ## Sızıntı sonrası: ne yapılmalı? Veritabanı sızdıysa parolalar iyi hash'lenmiş olsa bile yapılması gerekenler bellidir: tüm oturumları geçersiz kılın, kullanıcıları bilgilendirin, zayıf algoritmayla saklanan hash'ler varsa parola sıfırlamayı zorunlu kılın ve API anahtarlarını değiştirin. Sırların hızlı iptal edilebilir olması bu anda belirleyicidir — bunun altyapısı için [sır yönetimi](https://cilginyazilim.com/blog/sirlarin-yonetimi-env-dosyasindan-sir-kasasina) yazımıza bakabilirsiniz. Tedarik zinciri üzerinden gelen risklerin de aynı olay planına dahil edilmesi gerekir; [bağımlılık zinciri saldırıları](https://cilginyazilim.com/blog/bagimlilik-zinciri-saldirilari-paketleri-guvenle-kullanmak) yazımız bu boyutu ele alıyor. Kimlik doğrulama konusundaki güncel öneriler ve yaygın hatalar için [OWASP Top Ten](https://owasp.org/www-project-top-ten/) düzenli olarak takip edilmelidir. ## Sonuç Parola saklamada doğru karar sadedir: parolayı şifrelemeyin, modern ve yavaş bir algoritmayla hash'leyin, maliyet parametresini zamanla yükseltin ve karmaşıklık kuralları yerine uzunluk ile ikinci faktöre yatırım yapın. Ancak iş burada bitmez — oturum çerezlerinin bayrakları, gerçek çıkış, token iptali ve sıfırlama akışının sıkılığı en az hash algoritması kadar belirleyicidir. Bugün üç kontrol yapın: oturum çerezinizde HttpOnly bayrağı var mı, çıkış sunucu tarafında oturumu gerçekten siliyor mu, sıfırlama bağlantınız tek kullanımlık mı? Üçünden birine "hayır" diyorsanız, en yüksek öncelikli işiniz bulundu demektir. ## Sıkça Sorulan Sorular ### md5 ile hash almak neden yeterli değil? Çünkü çok hızlıdır. Parola hash'lemede istenen şey yavaşlıktır; hızlı algoritmalar saldırganın saniyede milyarlarca deneme yapmasına izin verir. Bu amaç için tasarlanmış bcrypt veya argon2 kullanılmalıdır. ### Tuzu ayrı bir sütunda saklamalı mıyım? Modern hash fonksiyonları tuzu kendileri üretir ve sonucun içine gömer; ayrı sütun gerekmez. Elle tuz yönetmeye çalışmak çoğu zaman hata kaynağı olur. ### Kullanıcılara parolalarını periyodik olarak değiştirtmeli miyim? Güncel öneri hayır yönündedir. Zorunlu periyodik değişim, tahmin edilebilir kalıplara yol açar. Değişim, sızıntı şüphesi veya şüpheli erişim durumunda istenmelidir. ### JWT kullanırken çıkış yapma nasıl çalışır? İmzalı token süresi dolana kadar geçerli kalır; bu yüzden erişim token'ı kısa ömürlü tutulur ve yenileme token'ı sunucu tarafında saklanıp iptal edilebilir yapılır. Gerçek çıkış, ikinci katman olmadan sağlanamaz. --- Kaynak: [Parola Saklama ve Oturum Güvenliği: Hash, Tuz ve Token Ömrü](https://cilginyazilim.com/blog/parola-saklama-ve-oturum-guvenligi)