Parola Saklama ve Oturum Güvenliği: Hash, Tuz ve Token Ömrü

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.

Ş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 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 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ı 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 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ı yazımız bu boyutu ele alıyor.

Kimlik doğrulama konusundaki güncel öneriler ve yaygın hatalar için OWASP 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.