Django 6.1'in PBKDF2 artışı, giriş sırasında parola hash'lerini yeniden yazıyor — daha güçlü olanlar dahil

Artışın bedeli

Yazar, Django 6.1.2 ve 6.0.9'u ayrı virtualenv'lerde kurdu ve her sürümün varsayılan iterasyon sayısıyla, boşta duran 4 çekirdekli bir container'da üç süreç çalışması boyunca 20'şer hash'in süresini ölçtü. Her girişte yapılan iş olan ortalama doğrulama süreleri kabaca 270–290ms'den 366–378ms'ye çıktı ve en hızlı süreler, yeni ve eski iterasyon sayıları arasındaki 1,25 oranıyla neredeyse tam olarak ölçeklendi. Net etki, makinenin yoğunluğuna bağlı olarak her girişte kabaca 50–90ms daha fazla CPU tüketilmesi.

Ancak bu maliyet istekleri seri hale getirmiyor. CPython'un hashlib.pbkdf2_hmac fonksiyonu, OpenSSL temeldeki işi yaparken GIL'i serbest bıraktığı için benchmark'lar, dört worker'a kadar neredeyse doğrusal ölçeklenen throughput gösterdi — saniyede yaklaşık 10,5–10,7 hash — ve sekizde düzleşti. dev.to yazısı, bedelin istek başına bloke olan bir thread değil, giriş yoğunluğu高的 dağıtımlarda login sırasında CPU payı olarak ödendiği sonucuna varıyor.

Hash'ler bir sonraki girişte yeniden yazılıyor

Django, mevcut hasher'ın parametreleri saklananla artık eşleşmediğinde saklanan hash'i yükseltmek için genel bir mekanizmaya sahip ve yazar bunun bu belirli değişiklik için tetiklendiğini doğruladı. Hash'i 1.200.000 iterasyon altında oluşturulmuş bir kullanıcı authenticate() üzerinden bir kez giriş yaptı; saklanan hash 1.500.000 iterasyonla geri döndü ve query logging, auth_user tablosuna yapılan UPDATE'i kaydetti. Hiçbir migration komutu çalıştırılmadı ve açık bir set_password() çağrısı yapılmadı. İkinci giriş başka bir yazma tetiklemedi, çünkü güncelleme yalnızca saklanan iterasyon sayısı canlı varsaylanla uyuşmadığında gerçekleşiyor.

6.0'dan 6.1'e geçen bir site için bu, her aktif kullanıcının hash'inin, herhangi bir backfill işi gerekmeden, birer giriş ile güçlendirildiği anlamına geliyor.

Daha güçlü hash'ler zayıflatılıyor

Yeniden yazıp yazmama kararını veren kontrol, saklanan sayının mevcut varsayilandan düşük olup olmadığı değil, hiç fark etmesi. Yazar, kasıtlı olarak 3.000.000 iterasyona — yeni varsayılanın iki katına — ayarlanmış, güvenlik bilinci yüksek bir yöneticinin özel bir PASSWORD_HASHERS girdisiyle yapılandırabileceği türden bir hash test etti. Tek bir girişten sonra hash 1.500.000'e yeniden yazılmıştı. Hiçbir şey bunun hakkında uyarmadı ve yazıya göre 6.1 sürüm notları sayının yükseldiğini anlatıyor ama zaten üzerinde olan hash'lere ne olduğuna değinmiyor.

Ayar üzerinde hiçbir güvence yok

Analiz ayrıca hasher'ın sınırlarını yokladı. Negatif bir iterasyon sayısı ValueError yükseltiyor, ama 1 iterasyon sayısı şikayetsizce kabul ediliyor ve yaklaşık çeyrek milisaniyede bir hash üretiyor. Hiçbir system check yok ve manage.py check --deploy içinde PASSWORD_HASHERS iterasyon sayılarını inceleyen bir şey bulunmuyor. Ayrı bir tuhaflık: encode() argümanını iterations = iterations or self.iterations olarak çözüyor, yani açıkça 0 geçmek sessizce yok sayılıyor ve Python'un doğruluk kuralları girdiyi onurlandırmak ya da reddetmek yerine size tam güçteki varsayılanı veriyor.

Bunların hiçbiri uygulamanın kendi sinyallerinden de görünmüyor. Yazı, bir hasher yükseltmesi kaydını sıradan bir parola değişikliğinden ayıran bir log satırı ya da Django sinyali olmadığını belirtiyor; tek iz, UPDATE sorgusunun kendisi.

Neden önemli

Sessiz yükseltme, varsayılan dağıtımlar için gerçek bir kazanç çünkü hash gücü, aktif kullanıcılar için sıfır operasyonel işle iyileşiyor. Ama mekanizma iki yönlü kesiyor ve 'herhangi bir fark' karşılaştırması, ekstra pay için iterasyonları yukarı ayarlamış yöneticilerin bu güçlendirmenin görünmez biçimde, birer giriş ile geri alındığını görecekleri anlamına geliyor. Özelleştirilmiş bir hasher ile 6.1'e yükselen herkes, yükseltme sonrası varsayılanın ne olmasını istediğine karar vermeli ya da kullanıcılar giriş yapmadan önce saklanan hash'leri denetlemeli. Giriş başına CPU'daki kabaca %25'lik artış ayrıca giriş yoğun siteler için bir kapasite planlama kalemi ve iterasyon sayılarında herhangi bir taban ya da deploy zamanı kontrolünün yokluğu, yanlış yapılandırmayı tamamen operatöre bırakıyor.