Şifreler Nasıl Saklanmalı? bcrypt, Argon2 ve Tuz (Salt)

Şifre hashleme nedir?

Bir site şifrenizi saklarken aslında şifrenin kendisini değil, ondan hesaplanmış bir özeti (hash) saklamalıdır. Giriş yaptığınızda yazdığınız şifre aynı yöntemle yeniden özetlenir ve kayıtlı değerle karşılaştırılır. Özet geri çevrilemez; veritabanı sızsa bile şifreler doğrudan okunamaz.

OWASP'ın Password Storage Cheat Sheet belgesi burada önemli bir ayrım yapar: hashleme tek yönlü, şifreleme iki yönlü bir işlemdir ve şifreler şifrelenmemeli, hashlenmelidir. Şifrelenmiş şifreler, anahtarı ele geçiren biri için açık metin gibidir. Hash ile şifreleme farkının temelini hash nedir yazısında anlatıyoruz.

Neden MD5 veya SHA-256 yetmez?

MD5 ve SHA-256 gibi genel amaçlı özetler hızlı olsun diye tasarlanmıştır. Bu, dosya doğrulamak için iyidir ama şifre için kötüdür: özetleri çalan saldırgan, ekran kartlarıyla saniyede çok sayıda tahmini deneyebilir. Şifre hashleme algoritmaları bu yüzden bilerek yavaştır ve bazıları ayrıca çok bellek ister. Tek bir girişte fark edilmeyen bu gecikme, milyarlarca tahmin deneyen biri için işi pahalı hâle getirir. Saldırı yöntemlerini şifre kırma ve şifre saldırıları yazısında bulabilirsiniz.

Salt (tuz) nedir?

Tuz, her şifre için ayrı üretilen rastgele bir değerdir ve özet hesaplanmadan önce şifreye eklenir. Tuzun üç faydası vardır:

• Aynı şifreyi kullanan iki kullanıcının özetleri farklı olur; veritabanına bakan biri kimin aynı şifreyi kullandığını göremez.
• Yaygın şifrelerin önceden hesaplanmış özet tabloları (rainbow table) işe yaramaz.
• Saldırgan her hesabı ayrı ayrı kırmak zorunda kalır.

Tuz gizli değildir; özetle birlikte saklanır. NIST SP 800-63B-4, tuzun en az 32 bit olmasını ve tuz ile özetin her şifre için saklanmasını şart koşar. RFC 9106 şifre hashleme için 16 bayt (128 bit) tuz önerir. bcrypt, Argon2 kütüphaneleri ve PHP'nin password_hash fonksiyonu tuzu kendileri üretir; elle tuz vermeniz gerekmez.

Pepper (biber) nedir?

Pepper, bütün şifreler için ortak olan ve veritabanında saklanmayan gizli bir anahtardır. Veritabanı sızsa bile pepper ele geçmediyse özetler kırılamaz. NIST, doğrulayıcının yalnızca kendisinin bildiği gizli bir anahtarla ek bir anahtarlı hash veya şifreleme adımı uygulamasını önerir (SHOULD) ve bu anahtarın donanım güvenlik modülü (HSM) gibi korumalı bir ortamda tutulmasını ister. Pepper tuzun yerine geçmez; ikisi birlikte kullanılır.

bcrypt nedir, nasıl çalışır?

bcrypt, Blowfish şifresinin anahtar hazırlama adımını tekrar tekrar çalıştırarak yavaşlayan bir şifre hashleme fonksiyonudur. Ürettiği metin örneği şuna benzer:

$2y$12$4Umg0rCJwMswRw/l.SwHvuQV01coP0eWmGzd61QH2RvAOMANUBGC.

Bu örnek php.net belgesindeki çıktıdır. $2y$ (Python kütüphanesinde $2b$) algoritma sürümünü, 12 maliyeti gösterir; ardından 22 karakterlik tuz ve 31 karakterlik özet gelir. Toplam 60 karakterdir ve doğrulama için gereken her şey içindedir.

• Maliyet (cost): Yineleme sayısının 2 tabanında logaritmasıdır; maliyet 1 artınca süre yaklaşık iki katına çıkar. OWASP en az 10 ister ve sunucunun kaldırabileceği kadar yüksek olmasını önerir. PHP 8.4 ile PHP'nin varsayılanı 10'dan 12'ye, Python bcrypt paketinde gensalt() varsayılanı 12'dir.
• 72 bayt sınırı: bcrypt çoğu uygulamada yalnızca ilk 72 baytı kullanır. PHP fazlasını sessizce keser; Python bcrypt 5.0.0 ise 72 bayttan uzun şifrede ValueError verir. Türkçe karakterler UTF-8'de 2 bayt tuttuğu için sınır 72 karakterden daha erken dolabilir.

72 bayt sınırını aşmak için şifreyi önce SHA-512 gibi bir fonksiyondan geçirip bcrypt'e vermek masum görünür ama OWASP bunu önermez: çıktı NUL bayt içerebilir ve başka bir sızıntıdaki çıplak özetlerle eşleştirme (password shucking) mümkün olur. OWASP'ın önerdiği biçim, pepper'lı HMAC-SHA384 çıktısının Base64 hâlini bcrypt'e vermektir.

Argon2 nedir? Argon2id neden öneriliyor?

Argon2, Eylül 2021'de RFC 9106 olarak yayımlanan, bellek zorlayıcı (memory-hard) bir şifre hashleme fonksiyonudur. Hesaplama için megabaytlarca bellek gerektirdiği için ekran kartı veya özel donanımla çok sayıda tahmini paralel denemek pahalılaşır. Üç biçimi vardır:

• Argon2d: Bellek erişimi veriye bağlıdır. RFC, yan kanal zamanlama saldırısı tehdidi olmayan kripto para ve iş kanıtı uygulamaları için uygun görür.
• Argon2i: Bellek erişimi veriden bağımsızdır; yan kanal saldırılarına dayanıklıdır.
• Argon2id: İlk geçişin ilk yarısında Argon2i, sonra Argon2d gibi çalışır; hem yan kanal koruması hem kaba kuvvete karşı maliyet avantajı sağlar. RFC 9106'ya göre Argon2id'yi desteklemek zorunludur (MUST), diğer ikisi isteğe bağlıdır.

Argon2'nin üç ayarı vardır: m (bellek, KiB), t (bellek üzerinden geçiş sayısı) ve p (paralellik). Bu değerler, tuz ve özet ile birlikte $argon2id$v=19$m=65536,t=3,p=4$... biçimindeki bir metinde saklanır.

Önerilen parametreler

Kaynaklar parametreleri farklı ihtiyaçlara göre verir. OWASP'ın önerdiği Argon2id ayarlarının hepsi aynı koruma düzeyini hedefler; bellek azaldıkça geçiş sayısı artar:

OWASP ayrıca bir özetin hesaplanmasının bir saniyeden kısa sürmesi gerektiğini hatırlatır; çok yüksek ayarlar giriş sayfanızı hizmet dışı bırakma saldırısına açık hâle getirebilir. Ayarları kendi sunucunuzda ölçerek seçin. NIST SP 800-63B-4 de maliyetin, doğrulayıcının performansını bozmadan olabildiğince yüksek tutulmasını ister.

Kaynaklar: OWASP Password Storage Cheat Sheet, RFC 9106, NIST SP 800-63B-4 (İngilizce).

Argon2 vs bcrypt: hangisini seçmeli?

Yeni bir projede kullandığınız dilde bakımı süren bir Argon2 kütüphanesi varsa Argon2id seçin. PHP'de PASSWORD_ARGON2ID, Python'da argon2-cffi bu işi görür. Çalışan bir bcrypt sistemi ise güvensiz değildir; acele etmeden, kullanıcılar giriş yaptıkça yeni algoritmaya taşıyabilirsiniz. Dile göre örnekler: Python ile bcrypt ve Argon2, PHP password_hash kullanımı, C# ile tuzlu PBKDF2.

Eski MD5 veya SHA-1 özetleri nasıl yükseltilir?

Elinizde MD5 ile saklanmış şifreler varsa kullanıcıların şifresini bilmeden de hemen iyileştirme yapabilirsiniz. OWASP iki yol anlatır:

1. Katmanlama: Mevcut MD5 özetini yeni algoritmanın girdisi yapın, yani bcrypt(md5(şifre)) gibi bir özet saklayın. Kullanıcı bir sonraki girişinde şifreyi doğrudan yeni algoritmayla özetleyip kaydı değiştirin.
2. Süre tanıma: Uzun süredir giriş yapmayan kullanıcıların eski özetlerini silin ve bir sonraki girişte şifre sıfırlamasını zorunlu tutun.

Geçiş sırasında hangi kaydın hangi algoritmayla oluşturulduğunu bilmeniz gerekir. $argon2id$ veya $2y$ gibi ön ekler içeren standart biçimler bu ayrımı kolaylaştırır.

Şifre saklarken sık yapılan hatalar

• Tuzu bütün kullanıcılar için aynı tutmak veya kullanıcı adından türetmek.
• Özetleri == ile karşılaştırmak; kütüphanelerin sabit sürede karşılaştıran doğrulama fonksiyonunu kullanın.
• Özet sütununu dar tutmak. PHP belgesi, algoritma ileride değişebileceği için 255 karakterlik sütun önerir.
• Şifreye üst sınırı çok kısa koymak. NIST en az 64 karakterlik şifrelere izin verilmesini ister (SHOULD).
• Ayarları bir kez seçip unutmak. Donanım hızlandıkça maliyeti artırın; doğrulama başarılı olduğunda eski ayarla oluşturulmuş özetleri yeniden hesaplayın.

Kullanıcı tarafında en iyi savunma yine uzun ve rastgele bir şifredir: en iyi saklama yöntemi bile "123456"yı korumaz. Kullanıcılarınıza şifre üreticimizi önerebilirsiniz.