bcrypt vs Argon2: parola hash ayarlarını seçmek

Parola hashlemenin çözdüğü problem

Parola hashleme, bir backend'in parolayı kendisi saklamadan parola saklamasını sağlar. Birisi kaydolduğunda sunucu parolayı tek yönlü bir fonksiyondan geçirir ve sonucu (hash'i) kaydeder. Girişte kullanıcı parolasını hashleyip depolananla karşılaştırırsınız.

Hash şifreleme değildir. Geriye döndürülemez. Bu tek yönlü özellik tam da parolalar için hash kullanmanın sebebidir.

Peki neden normal, hızlı bir hash (ör. SHA-256) kullanmayalım? Çünkü hızlı olmak saldırganların istediğidir. Bir veritabanı çalındığında saldırganlar parolaları tek tek denemezler; çalıntı hash listesi üzerinde çevrimdışı tahminler yaparlar ve donanımlarının izin verdiği hızda deneme iterasyonlarını çalıştırırlar. GPU'larla hızlı hash'ler devasa ölçeklerde test edilebilir. Benzersiz salt olsa bile hızlı bir hash kaba kuvvetle çabucak aşılabilir.

Gerçekçi başarısızlık senaryosu şöyledir: küçük bir web uygulaması kullanıcı tablosunu bir ihlal sonucu kaybeder. Saldırgan e-posta adresleri ve parola hash'lerini elde eder. Eğer bu hash'ler hızlı bir fonksiyonla oluşturulduysa, yaygın parolalar ve küçük varyasyonlar hızla kırılır. Ardından saldırgan aynı parolayı diğer sitelerde dener (credential stuffing) veya uygulamanız içindeki ayrıcalıklı özelliklere erişmek için kullanır.

İyi bir parola hash'i tahmin etmeyi pahalı kılar. Hedef "kırılamaz" değil; hedef "çok yavaş ve maliyetli olduğu için değmez" olmalıdır.

Bir parola hashleme kurulumu şu özelliklerde olmalıdır:

• Tek yönlü (doğrula, tersine çevirme değil)
• Her tahmin başına yavaş
• Paralel donanım (özellikle GPU) için pahalı
• Gerçek girişlerin normal hissetmesi için yeterince hızlı
• Zamanla maliyeti yükseltebilmek için ayarlanabilir

bcrypt ve Argon2, bir dakikada

bcrypt ile Argon2'yi karşılaştırırken, veritabanı sızıntısı sonrası parola tahminini nasıl yavaşlatmak istediğinizi seçiyorsunuz.

bcrypt daha eski ve geniş destekli bir seçenektir. CPU üzerinde maliyetli olacak şekilde tasarlanmıştır ve ana ayar düğümü cost factor'tur. Ayrıca "sıkıcı" olacak şekilde iyi: kütüphanelerde kolay bulunur, dağıtımı kolaydır ve tahmin edilebilirdir.

Argon2 daha yenidir ve hafıza-ağırlıklı olacak şekilde tasarlanmıştır. Her parola tahmininin anlamlı miktarda RAM kullanmasını zorlayabilir, sadece CPU değil. Bu önemlidir çünkü saldırganlar genellikle GPU veya özel donanımlarda büyük sayıda paralel tahmin çalıştırarak avantaj elde eder. Hafıza, o düzeyde paralellikte ölçeklendirmesi daha zor ve pahalıdır.

Argon2'nin üç varyantı vardır:

• Argon2i: bazı yan kanal saldırılarına karşı direnç vurgular
• Argon2d: GPU'ya karşı direnç vurgular, yan kanal göz önünde bulundurur
• Argon2id: her ikisinin pratik bir karışımıdır ve parola hashleme için yaygın varsayılandır

Eğer stack'iniz Argon2id'i destekliyorsa ve hafızayı güvenle ayarlayabiliyorsanız, genellikle en iyi modern varsayılandır. Eski sistemlerde maksimum uyumluluk gerekiyorsa, bcrypt yeterince yüksek bir cost factor ile hâlâ sağlam bir seçenektir.

Önemli güvenlik özellikleri

Temel soru basittir: bir saldırgan parola veritabanını çalarsa, ölçekli tahmin yapmak ne kadar pahalı olur?

bcrypt ile maliyeti (work factor) kontrol edersiniz. Daha yüksek maliyet her tahmini daha uzun yapar. Bu hem saldırganları yavaşlatır hem de kendi giriş doğrulamalarınızı yavaşlatır, bu yüzden kullanıcılar için kabul edilebilir bir noktaya ayarlarsınız.

Argon2id ile zaman maliyetinin üzerine hafıza-ağırlığı ekleyebilirsiniz. Her tahmin CPU zamanı ve belirli bir desenle erişilen RAM gerektirir. GPU'lar hesaplama açısından çok hızlı olabilir, ancak her paralel tahmin ciddi miktarda hafıza gerektirdiğinde avantajlarını büyük ölçüde kaybederler.

Salt vazgeçilmezdir. Her parola için benzersiz, rastgele bir salt:

• önceden hesaplanmış tabloların veritabanınız üzerindeki yeniden kullanımını engeller
• aynı parolaların farklı kullanıcılar için aynı hash'i üretmesini önler

Saltler zayıf parolaları güçlü yapmaz; esas amaç veritabanı sızıntısı sonrası saldırganın her kullanıcı için gerçek iş yapmasını sağlamaktır.

bcrypt'in güçlü ve sınırlı yönleri

bcrypt hâlâ yaygın olarak kullanılıyor çünkü her yerde dağıtımı kolaydır. Geniş uyumluluk gerektiğinde, kripto seçenekleri sınırlı bir stack'te veya tek bir basit ayar kolu istediğinizde iyi bir uyum sağlar.

En büyük "tuzağı" 72 baytlık parola limitidir. bcrypt parolanın ilk 72 baytını kullanır ve geri kalanını yok sayar. Bu uzun parola ifadeleri veya parola yöneticileri kullananları şaşırtabilir.

bcrypt seçerseniz parola uzunluğu davranışını açıkça belirtin. Ya maksimum uzunluk uygulayın (bayt cinsinden, karakter değil) ya da uzun girdileri tüm servislerde tutarlı biçimde işleyin. Temel amaç, kullanıcının düşündüğü parolanın sessizce kırpılmasını önlemektir.

bcrypt modern paralel kırma donanımına karşı hafıza-ağırlıklı seçenekler kadar dirençli değildir. Savunması hâlâ geçerli, ancak her tahmini pahalı kılma sorumluluğu büyük ölçüde doğru cost factor seçimine dayanır.

Yeni bir sistem kuruyorsanız veya yüksek değerli hesaplarınız (ücretli planlar, admin roller) varsa, yeni hash'leri Argon2id'e geçirmek ve mevcut bcrypt hash'lerini kullanıcı giriş yapana kadar kabul etmeye devam etmek yaygın ve düşük riskli bir yaklaşımdır.

Argon2'in güçlü ve ödünleri

Argon2 parola hashleme için üretildi. Argon2id, ekiplerin çoğunun tercih ettiği varyanttır çünkü GPU direncini yan kanal korumasıyla dengeler.

Argon2id size üç parametre verir:

• Memory (m): her hash çalışması sırasında kullanılan RAM miktarı
• Time/iterations (t): belleğin üzerinden kaç geçiş yapılacağı
• Parallelism (p): kaç lane kullanılacağı (çok çekirdekli CPU'larda yardımcı olur)

Hafıza ana avantajdır. Her tahmin anlamlı miktarda RAM gerektirdiğinde, saldırganlar aynı anda daha az tahmin çalıştırabilir veya hafıza kapasitesi ve bant genişliği için yüksek maliyet ödemek zorunda kalır.

Dezavantajı operasyoneldir: her hash için daha fazla hafıza daha az eşzamanlı giriş demektir. Hafızayı çok yüksek ayarlarsanız giriş patlamaları kuyruğa, zaman aşımına veya hatta OOM (out-of-memory) hatalarına yol açabilir. Kötüye kullanım (abuse) senaryolarını da düşünmelisiniz: çok sayıda eşzamanlı giriş denemesi kaynak problemi yaratabilir.

Argon2id'i güvenli ve kullanılabilir tutmak için onu bir performans özelliği gibi ayarlayın:

• üretime benzer donanımda benchmark yapın
• eşzamanlı hashing işini sınırlayın (worker limitleri, kuyruklar)
• giriş denemelerini rate-limitleyin ve tekrarlayan başarısızlıklarda kilitleme uygulayın
• zayıf bir uç noktanın hedef haline gelmemesi için ayarları servisler arasında tutarlı tutun

Gerçek web backend'lerinde performans maliyetleri

Parola hashlemeyle ilgili olarak "daha hızlı daha iyi" genelde yanlış hedeftir. Amaç, her tahmini saldırganlar için pahalı kılarken gerçek kullanıcıların girişlerinin hızlı hissetmesini sağlamaktır.

Pratik bir yöntem, doğrulama başına üretim benzeri donanımda bir zaman bütçesi belirlemektir. Birçok ekip kontrol başına 100 ila 300 ms arasında hedefler, ama doğru sayı trafiğinize ve sunucularınıza bağlıdır. bcrypt ve Argon2 arasındaki fark harcadığınız kaynak türündedir: bcrypt çoğunlukla CPU zamanı harcar, Argon2 ise aynı zamanda hafızayı da rezerve edebilir.

Bir hedef zaman seçin, sonra ölçün

Bir hedef hash süresi seçin ve bunu üretime benzeyen koşullarda test edin. Hem kayıt/parola değişikliği hashing'ini hem de giriş doğrulamayı ölçün; giriş sıcak yol (hot path) olarak daha önceliklidir.

Basit bir ölçüm planı:

• 1, 10 ve 50 eşzamanlı giriş kontrolünü test edin ve p50 ile p95 gecikmeleri kaydedin
• Önbellekleme ve CPU boost etkilerinden gürültüyü azaltmak için testleri tekrarlayın
• Hashlemenin gerçek maliyetini bilmek için veritabanı çağrısını ayrı ölçün
• Aynı konteyner ve CPU limitleriyle test edin ki dağıtmaya yakın sonuç alın

Sıçramalar ortalamalardan daha çok önemlidir

Çoğu sistem zirvelerde başarısız olur. Bir pazarlama e-postası kullanıcılardan bir dalga yarattığında hashing ayarlarınız sistemin yanıt verip vermeyeceğini belirler.

Eğer bir doğrulama 250 ms sürüyorsa ve sunucunuz kuyruğa girene kadar paralel olarak 40 işlemi kaldırabiliyorsa, 500 girişlik bir patlama çok saniyeli beklemelere dönüşebilir. Bu durumda maliyeti küçük miktarda azaltmak ve güçlü rate limitler uygulamak, parametreleri öylesine zorlamak yerine gerçek güvenliği iyileştirebilir.

Etkileşimli girişleri öngörülebilir tutun

Her parola operasyonunun aynı aciliyete ihtiyacı yoktur. Etkileşimli giriş maliyetini sabit tutun, sonra ağır işleri kritik yolun dışında yapın. Yaygın bir desen rehash-on-login'dir (başarılı girişten hemen sonra kullanıcının hash'ini güncelleme) veya geçişler ve içe aktarmalar için arka plan işleri kullanmak.

Adım adım parametre seçimi

Parametre ayarlama, saldırgan başına maliyeti yükseltirken oturumları yavaşlatmamak veya sunucuları kararsız hale getirmemekle ilgilidir.

1. Stack'inizin iyi desteklediği bir algoritma seçin. Argon2id mevcut ve iyi destekleniyorsa genelde varsayılan seçimdir. Geniş uyumluluk gerekiyorsa bcrypt yeterlidir.

2. Üretime benzer donanımda hash başına hedef süre belirleyin. Pik yükler sırasında girişleri akıcı tutacak bir değer seçin.

3. Bu süreyi yakalayacak şekilde ayarları yapın. bcrypt'te cost factor'ı ayarlayın. Argon2id'de hafıza, iterasyon ve paralelleşmeyi dengeleyin. Hafıza, saldırgan ekonomisini en çok değiştiren düğümdür.

4. Hash ile algoritma ve ayarları saklayın. Çoğu standart hash formatı bu detayları gömebilir. Ayrıca veritabanı alanınızın hash'lerin asla kesilmemesi için yeterince uzun olduğundan emin olun.

5. Yükseltmeler için plan yapın ve rehash-on-login kullanın. Bir kullanıcı giriş yaptığında, eğer depolanan hash mevcut politikanızdan zayıfsa yeniden hashleyip kaydedin.

Pratik bir başlangıç noktası

Ölçmeden önce bir başlangıç noktası gerekiyorsa temkinli başlayın ve zaman içinde ayarlayın.

• bcrypt için pek çok ekip başlangıç olarak cost 12 civarını önerir ve gerçek ölçümlere göre ayarlar.
• Argon2id için yaygın bir başlangıç: onlarca ila birkaç yüz MB arası hafıza, zaman maliyeti 2–4 arası, paralelleşme 1–2.

Bunları kurallar değil, başlangıç noktaları olarak görün. Doğru ayarlar trafiğiniz, donanımınız ve giriş patlamalarınıza uyanlardır.

Parola depolamayı zayıflatan yaygın hatalar

Çoğu parola depolama hatası yanlış kurulumdan kaynaklanır, algoritmanın kırılmasından değil.

Salt hataları büyük bir etken. Her parola kendi benzersiz salt'ine ihtiyaç duyar ve bu salt hash ile saklanmalıdır. Salt'ların yeniden kullanılması veya her kullanıcı için tek bir global salt kullanılması, saldırganların işi kolaylaştırır.

Maliyet ihmali başka bir sorun. Ekipler genelde düşük bir maliyetle yayına alır çünkü giriş daha hızlı gelir, sonra bir daha gözden geçirmez. Donanım gelişir, saldırganlar ölçeklenir ve bir zamanlar kabul edilebilir olan ayarlar ucuz hale gelir.

Argon2 aşırı-ayarları de yaygındır. Hafızayı aşırı yüksek ayarlamak kağıt üzerinde iyi görünse de gerçek dalgalanmalarda girişlerin yavaşlamasına, istek kuyruklanmasına veya OOM hatalarına neden olabilir.

Parola uzunluğu işleme önemlidir, özellikle bcrypt'in 72 bayt davranışıyla. Uzun parolalara izin verip bunları sessizce kırparsanız kafa karışıklığı ve güvenlik azalması yaşarsınız.

Bunların çoğunu önleyecek pratik alışkanlıklar:

• her parola için benzersiz salt kullanın (kütüphanenin üretmesine izin verin)
• yük testleri yapın ve ayarları düzenli aralıklarla gözden geçirin
• Argon2 hafızasını tek giriş testleri değil, pik trafik için ayarlayın
• parola uzunluğu limitlerini açık ve tutarlı yapın
• giriş uç noktasına eşzamanlılık limitleri ve izleme koyun

Daha güvenli bir kurulum için kısa kontrol listesi

Bu kısa listeyi dağıtıma çıkarken ve altyapı değiştirirken yanınızda tutun:

• Her parola için benzersiz salt, rastgele üretilmiş ve hash ile saklanmış
• Pik trafiği atlatacak bir hashing maliyeti, üretime benzer donanımda load test ile doğrulanmış
• Parametrelerin hash ile saklanması, böylece eski hesapları doğrulayabilir ve sonradan maliyeti artırabilirsiniz
• Çevrimiçi saldırı kontrolleri, rate limitler ve tekrarlayan başarısızlıklar için kısa kilitler dahil
• Yükseltme yolu, genelde rehash-on-login

Basit bir kontrol: staging ortamında başarılı ve başarısız girişlerden oluşan bir patlamayı çalıştırın ve uçtan uca gecikme ile CPU ve RAM kullanımını izleyin. Giriş yolu zorlanıyorsa maliyeti düşürmek veya rate limitleri sıkılaştırmak yerine tuzak olarak saltleri kesmeyin.

Gerçekçi bir örnek: küçük bir web uygulaması için tuning

Birkaç bin kullanıcısı olan küçük bir SaaS uygulamasını hayal edin. Günün büyük bölümünde trafik sabit, ama bir haber bülteni veya iş başlangıcı gibi kısa giriş patlamaları görüyorsunuz. İşte seçim kapasite planlamasına dönüşür.

Argon2id'i seçerek çevrimdışı kırma maliyetini yükseltirsiniz. Gerçek sunucu donanımınızda hedef doğrulama zamanını seçin (örneğin 100–250 ms arası) ve parametreleri RAM kullanımını izleyerek buna göre ayarlayın; hafıza ayarları eşzamanlı oturum kapasitenizi sınırlayabilir.

Pratik tuning döngüsü şöyle görünür:

• mütevazı iterasyon ve paralelleşme ile başlayın
• eşzamanlılık rahatsız edici hale gelene kadar hafızayı artırın
• zaman maliyetini ince ayar için iterasyonları ayarlayın
• sadece tek istekteki testlerle değil, simüle edilmiş patlamalarla tekrar test edin

Zaten daha zayıf ayarlarda eski hash'leriniz varsa, onları doğrulamaya devam edin ama giriş sonrası sessizce yükseltin. Başarılı girişte kullanıcıların hash'i yeni ayarlarla yeniden kaydedilsin. Zamanla aktif kullanıcılar güçlü hash'lere taşınır, zorunlu sıfırlama gerekmez.

Yayın sonrası, girişleri diğer kritik uç noktalar gibi izleyin: tail latency (p95/p99), patlama sırasındaki CPU ve RAM, başarısız giriş artışları ve eski hash'lerin ne hızla değiştirildiği.

Sonraki adımlar: güvenli bir şekilde yayınlayın ve geliştirmeye devam edin

Politikanızı yazın ve onu yaşayan bir ayar olarak görün. Örneğin: “Argon2id X hafıza, Y iterasyon, Z paralelleşme” veya “bcrypt cost factor N”, ayrıca seçildiği tarih ve gözden geçirme aralığı (her 6–12 ay iyi bir başlangıç) olsun.

Yükseltme yolunu açık tutun ki eski hash'lerle takılı kalmayın. Rehash-on-login basit ve çoğu sistemde iyi çalışır.

Güçlü bir hash yardımcıdır, ancak çevrimiçi kötüye kullanım kontrollerinin yerini almaz. Rate limitler, kilitler ve dikkatli parola sıfırlama akışları gerçek dünya güvenliği için aynı derecede önemlidir.

Eğer backend'inizi AppMaster gibi bir no-code platformla inşa ediyorsanız, kimlik doğrulama modülünüzün varsayılan olarak güçlü parola hashleme kullanıp kullanmadığını ve hash maliyetinin dağıtacağınız altyapıyla aynı türde bir donanımda ayarlandığını kontrol etmek faydalıdır. Bu küçük ön test çoğu zaman “güvenli ve sorunsuz” ile “yük altında kullanılamaz ama güvenli” arasındaki farktır.