Bir parolayı hash’lemenin sizi gerçekte neyden koruduğu

Kısa versiyon

Bir parolayı hash’lemek, parola veritabanınız çalındığında kullanıcıları korur.

Asıl işi budur. Tek ayrıntı bu değildir, güvenlik modelinin tamamı da değildir; ancak parolaları doğrudan saklamak yerine hash’lememizin temel nedeni budur.

Doğru şekilde hash’lenmiş bir parolanın geri döndürülmesi zordur. Bir saldırgan kullanıcı tablonuzun bir kopyasını ele geçirirse, Alice’in parolasının Spring2026! olduğunu hemen öğrenmemelidir. Bunun yerine, tahminlere karşı test edilmesi zaman, para ve donanım gerektiren saklanmış bir hash elde eder.

Bu ayrım önemlidir. Parola hash’leme, tek başına oturum açmayı güvenli hale getirmek için tasarlanmamıştır. Phishing’i durdurmaz. Birinin sızdırılmış parolaları oturum açma formunuzda denemesini engellemez. Oturum açıldıktan sonra bir session cookie’yi korumaz. Çok belirli bir arızadan sonra zaman kazandırır ve zararı azaltır: parola doğrulayıcı depolamanız açığa çıkar.

Bu sınırı anlarsanız algoritmalar, iş faktörleri, sıfırlamalar, loglama ve olay müdahalesi hakkında daha iyi kararlar verirsiniz.

Parola hash’i nedir

Parola hash’i, genellikle benzersiz bir salt ve bilinçli olarak yavaş bir parola hash’leme algoritmasıyla birlikte, bir parolaya uygulanan tek yönlü bir fonksiyonun çıktısıdır.

Bir kullanıcı hesap oluşturduğunda sistem kabaca şunu yapmalıdır:

1. Parolayı HTTPS üzerinden alır.
2. Rastgele, benzersiz bir salt üretir.
3. Parola ve salt’ı Argon2id, bcrypt, scrypt veya PBKDF2 gibi bir parola hash’leme fonksiyonundan geçirir.
4. Algoritma adını, parametreleri, salt’ı ve ortaya çıkan hash’i saklar.
5. Orijinal parolayı atar.

Kullanıcı daha sonra oturum açtığında sistem, gönderilen parola ve saklanan parametrelerle aynı hash’leme sürecini tekrarlar. Ortaya çıkan hash saklanan hash ile eşleşirse oturum açma başarılı olur.

Önemli nokta şudur: uygulamanın orijinal parolayı bilmesi gerekmez. Yalnızca gönderilen parolanın beklenen sonucu üretip üretmediğini doğrulaması gerekir.

Parolaları geri döndürülebilir şifreleme ile saklamanın genellikle yanlış model olmasının nedeni budur. Uygulamanız her parolanın şifresini çözebiliyorsa, şifre çözme anahtarını çalan herkes de aynısını yapabilir. Parolalar normalde yalnızca gizlenmiş değil, geriye doğru doğrulanamaz olmalıdır.

Hash’leme sizi neyden korur

1. Veritabanı ihlalinden sonra parolaların anında açığa çıkması

Bir saldırgan düz metin parolalar içeren bir veritabanı çalarsa, zarar anında oluşur. Her parola açığa çıkar. Kullanıcılar yalnızca sizin sitenizde değil, aynı parolayı yeniden kullandıkları her yerde risk altındadır.

Veritabanı iyi hash’lenmiş parolalar içeriyorsa, saldırganın yapması gereken daha fazla iş vardır. Aday parolaları tahmin etmeli, her tahmini doğru salt ve parametrelerle hash’lemeli ve sonucu karşılaştırmalıdır.

Zayıf parolalar için bu hâlâ hızlı olabilir. Güçlü ve benzersiz parolalar için ise pratik olmayabilir.

Hash’leme, yıkıcı bir ifşayı bir yarışa dönüştürür: saldırganlar parolaların çoğunu kırmadan önce kullanıcılar parolalarını sıfırlayabilir mi ve siz olayı kontrol altına alabilir misiniz?

Bu mükemmel değildir. Hâlâ bir ihlaldir. Ancak çok daha iyi bir arıza biçimidir.

2. Tüm kullanıcı tabanınıza yönelik toplu saldırılar

Salt’lar, saldırganların önceden hesaplanmış tablolarla çok sayıda kullanıcıya verimli biçimde saldırmasını engellediği için parola saklamanın temel bir parçasıdır.

Salt gizli değildir. Hash’in yanında saklanır. Görevi benzersizlik sağlamaktır.

İki kullanıcı aynı parolayı seçerse, benzersiz salt’lar saklanan hash’lerinin farklı olmasını sağlar. Bu, saldırganların birçok kullanıcının aynı parolayı paylaştığını bir bakışta görmesini engeller. Ayrıca saldırganların parola-hash eşlemelerinden oluşan dev önceden hesaplanmış listeler kullandığı klasik rainbow table saldırılarını da önler.

Salt olmadan, kırılmış tek bir hash aynı parolaya sahip her kullanıcıyı açığa çıkarabilir. Salt ile her parola tahmini her kullanıcı için ayrı ayrı test edilmelidir.

3. Hızlı çevrimdışı tahmin

Saldırganlar bir parola veritabanını ele geçirdiğinde çevrimdışı tahmin yapabilir. Bu, oturum açma hız sınırlarınızın, CAPTCHA’nın, IP engellemenin ve izlemenin artık önemi kalmadığı anlamına gelir. Saldırgan tahminleri kendi donanımında test edebilir.

Algoritma seçiminin önemli olduğu yer burasıdır.

SHA-256 ve SHA-512 gibi genel amaçlı hash’ler hızlı olacak şekilde tasarlanmıştır. Bu, dosya bütünlüğü ve dijital imzalar için iyidir. Parola saklama için kötüdür.

Parola hash’leme algoritmaları yavaş, ayarlanabilir ve bazen bellek-zor olacak şekilde tasarlanmıştır. Argon2id, bcrypt, scrypt ve PBKDF2, her tahminin anlamlı bir zaman alması için maliyet parametrelerini ayarlamanıza olanak tanır.

Argon2id, hem CPU zamanı hem de bellek gerektirecek şekilde yapılandırılabildiği için yeni sistemlerde yaygın olarak önerilir; bu da büyük ölçekli GPU ile kırmayı daha pahalı hale getirir. bcrypt iyi yapılandırıldığında yaygın ve kabul edilebilir olmaya devam eder; ancak parola uzunluğu işleme gibi sınırlamaları vardır. PBKDF2, özellikle FIPS doğrulamalı bileşenlerin gerekli olduğu bazı uyumluluk odaklı ortamlarda hâlâ kullanılır.

İlke basittir: meşru oturum açmaları kabul edilebilir ölçüde hızlı tutarken, milyarlarca tahmini pahalı hale getirin.

Hash’leme sizi neyden korumaz

1. Phishing

Bir kullanıcı parolasını sahte bir oturum açma sayfasına yazarsa, sunucunuzdaki hash’leme yardımcı olmaz. Saldırgan parolayı sisteminiz onu hiç görmeden önce alır.

Buradaki savunmalar farklıdır: çok faktörlü kimlik doğrulama, passkey’ler, kullanıcı eğitimi, alan adı hijyeni, phishing’e dayanıklı kimlik doğrulama ve dikkatli parola sıfırlama akışları.

Parola hash’leme, saklanan sırlar için bir son savunma hattıdır. Kullanıcıların bu sırları vermeleri için kandırılmasına karşı bir savunma değildir.

2. Credential stuffing

Credential stuffing, saldırganların bir hizmetten sızdırılmış kullanıcı adı ve parola çiftlerini alıp başka bir hizmette denemesiyle gerçekleşir.

Parola hash’leriniz mükemmel olabilir; kullanıcılar parolaları yeniden kullanıyorsa credential stuffing yine de işe yarayabilir.

Bu, veritabanınıza yönelik çevrimdışı bir saldırı değil, oturum açma formunuza yönelik çevrimiçi bir saldırıdır. Hız sınırlama, anomali tespiti, ihlal edilmiş parola kontrolleri, MFA ve kolay hizmet engelleme fırsatları yaratmayan makul kilitleme politikalarına ihtiyacınız vardır.

Aynı pratik düşünce, açığa açık her form için geçerlidir. Kimlik doğrulama yüzeyinizi gözden geçiriyorsanız iletişim formunuzun neden en büyük spam yükümlülüğünüz olduğu hakkında okumaya değer; mekanikler farklıdır, ancak ders benzerdir: herkese açık girdiler yalnızca temiz backend koduna değil, kötüye kullanım kontrollerine ihtiyaç duyar.

3. Loglarda veya analitikte yakalanan parolalar

Hash’leme yalnızca düz metin parola hızla atılır ve başka bir yere asla kopyalanmazsa yardımcı olur.

Yaygın hatalar şunlardır:

• Başarısız oturum açma denemelerinde tam request body’lerini loglamak.
• Parolaları hata izleme araçlarına göndermek.
• Session replay ürünlerinde parola alanlarını yakalamak.
• Kötü tasarlanmış sıfırlama veya geçiş akışlarında kimlik bilgilerini URL’lere dahil etmek.
• İçe aktarmalar sırasında geçici düz metin parolaları saklamak.

Bu hatalar parola hash’lemeyi tamamen devre dışı bırakır. Düz metin loglara, yedeklere, veri ambarlarına veya üçüncü taraf araçlara düşerse hash fonksiyonunuzun önemi kalmaz.

Parola alanlarını toksik veri olarak ele alın. Loglamadan önce maskeleyin. Analitikten hariç tutun. URL’lerin dışında tutun. Üretim trace’lerine kimlerin erişebileceğini sınırlayın.

4. Kötü oturum güvenliği

Oturum açıldıktan sonra kullanıcının tarayıcısı genellikle bir session cookie veya token alır. Bu token çalınırsa saldırganın parolaya hiç ihtiyacı olmayabilir.

Parola hash’leme; cross-site scripting, güvensiz cookie’ler, session fixation, zayıf token üretimi veya aşırı uzun oturum ömürlerine karşı koruma sağlamaz.

Session cookie’leri kendi başına incelenmeyi hak eder: HttpOnly, Secure, uygun SameSite, kısa ömürlü yüksek riskli oturumlar ve parola değişikliklerinde sunucu tarafı geçersiz kılma. Daha geniş gizlilik ve tarayıcı ortamı da değişmeye devam ediyor; bu konu 2026’da cookie’ler için ne değişti yazısında ele alınıyor.

5. Zayıf parola sıfırlama ve hesap kurtarma

Birçok hesap ele geçirme parolayla başlamaz. Sıfırlama akışıyla başlar.

Sıfırlama token’ları tahmin edilebilirse, uzun ömürlüyse, referrer header’ları üzerinden sızıyorsa veya ele geçirilmiş e-posta hesaplarına gönderiliyorsa parola hash’leme sizi kurtarmaz.

Yüksek entropili sıfırlama token’ları, kısa sona erme pencereleri, tek kullanımlık kullanım ve açık kullanıcı bildirimleri kullanın. E-posta çoğu zaman kurtarma kanalı olduğundan, temel alan adı kimlik doğrulaması da önemlidir. Ekibiniz DNS kayıtlarını gizemli bir tören gibi görüyorsa MX, SPF, DKIM ve DMARC için geliştirici dostu bir tur ile başlayın.

Algoritma seçimi: şimdi ne kullanmalı

Yeni uygulamalar için platformunuz iyi destekliyorsa Argon2id kullanın. Password Hashing Competition’ın kazananıdır ve GPU ağırlıklı kırmaya karşı direnç dahil olmak üzere parola saklama için tasarlanmıştır.

Makul bir modern hiyerarşi şöyle görünür:

1. Mevcut olduğu yeni sistemlerde Argon2id.
2. Argon2id pratik değilse ve bcrypt desteği olgunsa bcrypt.
3. Bellek-zor yapılandırma iyi destekleniyorsa scrypt.
4. Platform veya uyumluluk kısıtları gerektiriyorsa PBKDF2.

Düz SHA-256, SHA-512, MD5 veya sha256(password + salt) gibi ev yapımı bir kombinasyondan kaçının. Hızlı hash’ler parola saklama fonksiyonları değildir. Akıllıca görünen özel kurgular çoğu zaman sıkıcı standart olanlardan daha kötüdür.

Algoritma ayrıntıları etrafında kendi parola politikanızı icat etmekten de kaçının. Kullanıcıları öngörülebilir kalıplara itiyorsa 12 kurallı bir parola bileşimi kontrol listesi onlara fayda sağlamaz. Daha uzun benzersiz parolalar, password manager’lar, ihlal edilmiş parola taraması ve MFA genellikle daha önemlidir.

Maliyet faktörleri bir kez ayarlanıp unutulmaz

Parola hash’lemenin parametreleri vardır. Argon2id’de bellek, iterasyonlar ve paralellik bulunur. bcrypt’in bir maliyet faktörü vardır. PBKDF2’nin bir iterasyon sayısı vardır.

Bu değerler üretim ortamınıza göre seçilmelidir. Çok düşük olursa saldırganlar ucuza tahmin yapar. Çok yüksek olursa oturum açma sisteminiz yavaşlar veya hizmet engelleme saldırılarına açık hale gelir.

Pratik bir hedef, trafiğe ve riske bağlı olarak çoğu zaman gerçek sunucularınızda parola doğrulaması başına onlarca milisaniye ile birkaç yüz milisaniye aralığındadır. Yüksek güvenlikli sistemler daha fazlasını seçebilir. Tüketici ölçeğindeki sistemler dikkatli kapasite planlamasına ihtiyaç duyabilir.

Beş yıl önceki bir blog yazısından maliyet faktörü kopyalamayın. Donanım değişir. Kütüphaneler değişir. Trafiğiniz değişir.

Parametreleri düzenli olarak gözden geçirin ve yeniden hash’leme için plan yapın. Yaygın bir kalıp, algoritmayı ve parametreleri her hash ile birlikte saklamaktır. Başarılı oturum açmada, saklanan parametreler güncelliğini yitirmişse gönderilen parolayı daha yeni yapılandırmayla yeniden hash’leyin ve kaydı güncelleyin.

Pepper’lar: yararlıdır, ama yerine geçmez

Pepper, parola hash’leme sürecine eklenen ve veritabanından ayrı olarak, çoğu zaman bir secrets manager’da veya hardware security module’de saklanan gizli bir değerdir.

Salt’ın aksine, pepper gizli kalmalıdır.

Pepper’lar, veritabanı sızar ancak uygulama sırları sızmazsa zararı azaltabilir. İyi anahtar yönetimine sahip olgun ortamlarda en yararlıdırlar. Aynı saldırgan hem veritabanını hem de uygulama yapılandırmasını çalabiliyorsa daha az yararlıdırlar.

Pepper kullanıyorsanız rotasyonu dikkatle planlayın. Tasarıma bağlı olarak rotasyon, kullanıcıların yeniden oturum açmasını veya parolalarını sıfırlamasını gerektirebilir. Pepper ek bir katmandır; temel hash ayarlarını zayıflatmak için bir neden değildir.

Operasyonel kontrol listesi

Gerçek bir sistemden sorumluysanız pratik kontrol listesi kısadır:

• Parolaları yalnızca standart bir parola hash’leme algoritmasıyla saklayın.
• Her parola için benzersiz rastgele salt kullanın.
• Yeni kurulumlarda Argon2id’yi tercih edin.
• Maliyet parametrelerini üretime benzer donanımda ayarlayın.
• Algoritmayı ve parametreleri her hash ile birlikte saklayın.
• Parametreler güncelliğini yitirdiğinde oturum açma sırasında yeniden hash’leyin.
• Parolaları asla loglamayın veya analitik araçlarına göndermeyin.
• Kimlik bilgilerinin gönderildiği her yerde TLS kullanın.
• Riskin gerektirdiği yerlerde MFA veya passkey’ler ekleyin.
• Sıfırlama akışlarını oturum açma akışları kadar ciddiye alarak koruyun.
• Zorunlu sıfırlamalar ve kullanıcı bildirimi için bir olay planınız olsun.

Parola hash’leme gösterişli değildir. Bir tesisat işidir. Ama bir ihlalin acı verici bir olay mı yoksa tüm kullanıcıları etkileyen bir felaket mi olacağını belirleyen türden bir tesisattır.

<!-- tool-cta:start -->

💡 Bunu deneyin: Aynı girdinin Hash Generator ile farklı algoritmalara nasıl eşlendiğini görün; bu, hızlı hashler ile parola düzeyindeki hashler arasındaki farkı somutlaştırır.

<!-- tool-cta:end -->

Dürüst zihinsel model

Parola hash’lemeyi düşünmenin en iyi yolu şudur:

Hash’leme, kullanıcı parolayı yazarken parolayı korumaz. Kullanıcı oturum açtıktan sonra hesabı korumaz. Web genelinde parolaları yeniden kullanan kullanıcıları korumaz.

Saklanan doğrulayıcıyı korur.

Bu dar gelebilir, ancak son derece önemlidir. Veritabanları sızar. Yedekler sızar. Staging sistemleri kopyalanır. Tedarikçiler sahip olmamaları gereken erişimleri elde eder. Eski dışa aktarımlar, kimsenin hatırladığından daha uzun süre object storage’da kalır.

Bu olduğunda, parola saklama tasarımınız saldırganların parolaları alması ile pahalı bir tahmin problemi alması arasındaki fark haline gelir.

Bir parolayı hash’lemek sizi gerçekte bundan korur.