Saldırı altında mısınız? Olay müdahalesi için bize ulaşın

info@angelforce.eu
Güvenli yazılım geliştirme

Parola hashleme: Argon2id ayarları ve eski hash'leri yükseltme

Argon2id asgari ayarları, bcrypt 72 bayt tuzağı ve eski hash'lerin girişte Argon2id'ye taşınması; bir daha dönmeyen hesaplar dahil.

Diğer diller:EnglishDeutschFrançaisEspañolItalianoPolskiNederlandsEesti

İllüstrasyon: Parola hashleme: Argon2id ayarları ve eski hash'leri yükseltme

Parolaları Argon2id ile saklayın; en az 19 MiB bellek, 2 iterasyon ve 1 paralellik derecesi kullanın, her parola için benzersiz bir salt tanımlayın. Bu, OWASP Password Storage Cheat Sheet belgesindeki asgari yapılandırmadır. Veritabanınızda hâlâ MD5, SHA-1 veya salt'sız hash'ler varsa, toplu parola sıfırlamasına gitmeden ve uzun süredir giriş yapmayan hesaplar için zayıf hash'leri geride bırakmadan bunu düzeltebilirsiniz.

Ne kullanmalı ve asgari ayarlar

Cheat sheet şu asgari değerleri verir:

DurumAlgoritmaAsgari ayarlar
Tercih edilenArgon2id19 MiB bellek, 2 iterasyon, paralellik 1
Argon2id kullanılamıyorscryptmaliyet parametresi 2^17, blok boyutu 8, paralellik 1
bcrypt kullanan eski sistemlerbcryptwork factor 10 veya üzeri, 72 bayt parola sınırı
FIPS-140 uyumluluğu gerekiyorPBKDF2600.000 veya üzeri, HMAC-SHA-256

Argon2id, RFC 9106'daki birincil varyanttır ve bu belgeyi uygulayan her implementasyonun onu desteklemesi gerekir. Bellek üzerindeki ilk geçişin ilk yarısında Argon2i gibi, geri kalanında Argon2d gibi çalışır.

bcrypt'in 72 bayt sınırı

Cheat sheet, bcrypt için 72 bayt parola sınırı koyar. Kaynaklar, tek tek kütüphanelerin daha uzun girdiyi nasıl ele aldığını belirtmez; bu nedenle kendi kütüphanenizi test edin. 72 adet a karakteri ve ardından b içeren bir parolayı hash'leyin, sonra 72 adet a karakteri ve ardından c içeren parolayı doğrulayın. Doğrulama başarılı olursa kütüphaneniz girdiyi sessizce kırpıyor demektir.

Ardından ya formlarınızda parola uzunluğunu 72 bayt ile sınırlayıp bunu kullanıcıya açıkça belirtin ya da Argon2id'ye geçişi planlayın. RFC 9106, 2^32-1 bayta kadar parolaya izin verir.

Hızlı hash'ler neden yetersiz kalır

MD5 ve SHA-1 hızlı olacak şekilde tasarlandı; SHA-256 da aynı nedenle uygun değildir: saldırganın kısa sürede çok sayıda tahmin yapmasına olanak tanır. Saldırgan, sızdırılmış parola listelerinden, wordlist'lerden veya brute force ile ürettiği adayları hash'ler ve sonuçları sizin kayıtlarınızla karşılaştırır. GPU'lar ve kiralık bulut sunucuları bunu ucuz hale getirir.

Benzersiz bir salt, saldırganı hash'leri tek tek kırmaya zorlar. Rainbow table'ları da etkisiz kılar ve aynı parolalar artık aynı hash'i üretmez. RFC 9106, parola hashleme için 16 baytlık salt önerir. Olgun kütüphaneler salt'ı sizin yerinize üretip saklar; bu kısmı elle yazmayın.

Work factor ayarı

Herkes için geçerli tek bir sayı yoktur. Değer, sunucunuza ve kullanıcı sayınıza bağlıdır ve çalıştığınız donanım üzerinde deneyerek bulunur. Genel kural, tek bir hash'in bir saniyeden kısa sürmesidir.

Değeri çok yükseltmenin bir bedeli vardır. Her giriş denemesi CPU tüketir ve yoğun bir deneme akışı sunucuyu tüketebilir. Gerçekçi eşzamanlılık altında benchmark yapın ve en yoğun yükte karşılayabileceğiniz bir değer seçin.

Argon2 kütüphanenizin beklediği birimi kontrol edin. RFC 9106 bellek boyutunu kibibayt cinsinden tanımlarken cheat sheet MiB olarak verir. 19 MiB, 19456 KiB'dir; kütüphane KiB beklerken 19 verirseniz 19 KiB bellek elde edersiniz. Bu ayar çalışır, ancak amaçlanandan çok daha zayıftır.

Work factor genellikle hash çıktısının içinde saklanır. Bu, geçişi kolaylaştırır; çünkü girişte belirli bir hash'in hangi parametrelerle oluşturulduğunu görebilirsiniz.

Ek katman olarak pepper

Pepper, saklanan tüm parolalar için ortak olan ve veritabanının dışında, bir gizli bilgi kasasında (secrets vault) veya HSM'de tutulan bir sırdır. Saldırgan yalnızca veritabanını ele geçirdiğinde, örneğin SQL injection ile ya da çalınmış bir yedekle, işe yarar. Tek başına bir şey kazandırmaz; bu yüzden derinlemesine savunmanın bir parçası olarak düşünün.

Sorun rotasyondadır. Ele geçirilmiş bir pepper, her kullanıcının parolasını bilmeden değiştirilemez; dolayısıyla onu değiştirmek, koruduğu herkes için sıfırlama zorunlu kılar. Pepper kullanmaya başlamadan önce bu prosedürün sahibinin kim olacağına karar verin.

Eski hash'leri yükseltme

Cheat sheet'in work factor'ü artırma yaklaşımı, kullanıcının bir sonraki kimlik doğrulamasını beklemek ve ardından parolasını yeni ayarlarla yeniden hash'lemektir. MD5, SHA-1 veya salt'sız hash'lerden geçiş de aynı mantığı izler; ancak bu genişletme bize aittir.

  1. Saklanan her hash'i algoritmasıyla işaretleyin; bunu ayrı bir sütunda ya da hash formatı aracılığıyla yapabilirsiniz. Tabloda neyin bulunduğundan emin değilseniz hash tanımlayıcı formatları tanımanıza yardımcı olur.
  2. Girişte, saklanan hash hangi algoritmayı kullanıyorsa onunla doğrulama yapın.
  3. Başarılı olursa ve hash eski bir algoritmaya aitse ya da mevcut parametrelerinizin altındaysa, gönderilen paroladan yeni bir salt ile yeni bir Argon2id hash'i hesaplayın.
  4. Eski değerin üzerine aynı işlemde yazın.
ok = verify(row.scheme, row.hash, submitted)
if ok and (row.scheme != "argon2id" or needs_rehash(row.hash)):
    row.hash   = argon2id_hash(submitted)   # fresh salt, current parameters
    row.scheme = "argon2id"
    save(row)

Uzun süredir kullanılmayan hesaplar

Bir daha giriş yapmayan kullanıcılar hiç yükseltilmez; zayıf hash'leri tabloda süresiz kalır. Çözümlerden biri bu hash'leri şimdiden sarmalamaktır. Mevcut MD5 veya SHA-1 değerinin üzerinden Argon2id çalıştırın, sonucu argon2id(md5) gibi bir şema işaretiyle saklayın ve çıplak hash'i silin.

Girişte, gönderilen parolanın eski hash'ini hesaplar, Argon2id sarmalayıcısına karşı doğrularsınız ve başarılı olursa sarmalayıcıyı düz bir Argon2id hash'iyle değiştirirsiniz. Eski değerin tam olarak nasıl kodlandığını (hex veya ham bayt) kaydedin; çünkü uyumsuzluk, o şemadaki tüm girişleri bozar. Sarmalanmış yolu önce tablonun bir kopyası üzerinde test edin.

Sarmalama zayıf bir parolayı güçlü yapmaz. Yalnızca çalınmış bir tablonun MD5 hızında saldırıya uğramasını engeller.

Alternatif, belirli bir son tarihten sonra eski hash'leri kaldırmak ve bir sonraki girişte sıfırlama zorunlu kılmaktır; cheat sheet bunu uygulamaya bağlı bir seçenek olarak tanımlar. Değişiklik tam olarak kontrol etmediğiniz bir kod tabanına dokunuyorsa güvenli yazılım geliştirme ekibimiz bunu inceleyebilir.

Nereden başlamalı

  1. Kullanıcı tablosunu denetleyin: hangi algoritmalar kullanılıyor, salt var mı, parolalardan herhangi biri düz metin veya geri döndürülebilir şekilde şifrelenmiş mi? Şifreleme yalnızca orijinal parolayı geri almanız gereken durumlarda kabul edilebilir; cheat sheet ise buna ihtiyaç duymaktan kaçınmanızı söyler.
  2. En az 19456 KiB, 2 iterasyon ve paralellik 1 ile Argon2id'yi seçin ve tek bir hash bir saniyenin altına inene kadar üretim donanımında benchmark yapın.
  3. bcrypt kullanıyorsanız yukarıdaki 72 bayt testini çalıştırın ve uzunluk sınırı ile Argon2id'ye geçiş arasında karar verin.
  4. Şemaya bir algoritma işareti ekleyin, giriş kodunu eski şemayla doğrulayacak ve başarılı olunca yeniden hash'leyecek şekilde değiştirin.
  5. Kalan eski hash'leri Argon2id ile sarmalayın ya da sonrasında kaldırılacakları ve sıfırlamanın zorunlu olacağı bir son tarih belirleyin.
  6. Pepper ekliyorsanız bunu bir gizli bilgi kasasında saklayın ve önce rotasyon ile zorunlu sıfırlama prosedürünü yazılı hale getirin.

Nasıl yardımcı olabiliriz

Güvenli yazılım

Güvenliği yazılıma ilk satırdan itibaren yerleştirir, kendi güvenlik araçlarımızı da geliştiririz.

Hash türü tanımlayıcı

Bir hash’in hangi algoritmayla üretildiğini tarayıcınızda bulun: MD5, SHA-256, bcrypt ve daha fazlası.

Bize yazın
AngelForce ekibi

Bu yazıyı AngelForce ekibi hazırladı: Avrupa genelindeki kurumların sistemlerini test eden, izleyen ve koruyan; CEH, LPT Master ve CISA sertifikalı güvenlik danışmanları.

Aşağıda listelenen herkese açık kaynaklardan yapay zekâ desteğiyle yazıldı ve yayından önce AngelForce ekibi tarafından incelendi.

Kaynaklar

  1. cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
  2. www.rfc-editor.org/rfc/rfc9106.html

Güvenli yazılım geliştirme hakkında yazılar

Neyi korumanız gerektiğini anlatın

Altyapınızı ve hedefinizi kısaca yazın, size e-postayla dönelim.

Bize yazın
info@angelforce.eu

AngelForce OÜ · Tallinn, Estonya