Bir hata yaptım ve Django projemi SECRET_KEYhalka açık bir depoya koydum .
Bu anahtar, https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECRET_KEY dokümanlarına göre gizli tutulmalıdır.
Django projesi yayında ve bazı aktif kullanıcılarla bir süredir çalışıyor. Değiştirirsem etkileri nelerdir SECRET_KEY? Mevcut kullanıcılar, çerezler, oturumlar vb. Etkilenecek mi? Açıkçası, yeni SECRET_KEYartık halka açık bir yerde saklanmayacak.
Yanıtlar:
Edit: Bu cevap django 1.5 dayanmaktadır
SECRET_KEY birçok yerde kullanılıyor, önce neyin etkilendiğine işaret edeceğim ve sonra bu listeyi gözden geçirmeye çalışacağım ve etkinin tam bir açıklamasını vereceğim.
SECRET_KEYDoğrudan veya dolaylı olarak kullanılan şeylerin listesi :
startprojectGerçekte kullanmak burada listelenen öğelerin bir sürü SECRET_KEYaracılığıyla django.utils.crypt.get_random_string()kullanır hangi rastgele motorunu tohuma. Bu, değerindeki bir değişiklikten etkilenmeyecektir SECRET_KEY.
Değer değişikliğinden doğrudan etkilenen kullanıcı deneyimi:
django.contrib.comments), değer değişikliğinden önce talep edildiyse ve değer değişikliğinden sonra gönderildiyse doğrulanmaz. Bence bu çok küçük ama kullanıcı için kafa karıştırıcı olabilir.django.contrib.messages), sunucu tarafını yorum formuyla aynı zamanlama koşullarında doğrulamaz.GÜNCELLEME : şimdi django 1.9.5 üzerinde çalışıyor, kaynağa hızlı bir bakış bana hemen hemen aynı cevapları veriyor. Daha sonra ayrıntılı bir inceleme yapabilir.
SECRET_KEYkullanılan oturumda bulunan verileri okuyamazsınız salted_hmac.
<algorithm>$<iterations>$<salt>$<hash>rastgele tuz her durumda şifre yanında saklanır, böylece AUTH_USER içinde.
Bu soru sorulduğundan, Django belgeleri bir yanıt içerecek şekilde değiştirildi.
Gizli anahtar aşağıdakiler için kullanılır:
- Tüm oturumlar arka uçtan başka bir arka uç
django.contrib.sessions.backends.cachekullanıyorsanız veya varsayılanı kullanıyorsanızget_session_auth_hash().CookieStorageVeya kullanıyorsanız tüm mesajlarFallbackStorage.- Tüm
PasswordResetViewsimgeler.- Farklı bir anahtar sağlanmadığı sürece herhangi bir kriptografik imzalama kullanımı.
Gizli anahtarınızı döndürürseniz, yukarıdakilerin tümü geçersiz kılınacaktır. Gizli anahtarlar kullanıcıların parolaları için kullanılmaz ve anahtar döndürme onları etkilemez.
Gizli anahtarı tam olarak nasıl döndürmem gerektiği tam olarak belli değildi. Django'nun yeni bir proje için nasıl bir anahtar oluşturduğu ve diğer seçenekleri tartışan bir Gist hakkında bir tartışma buldum . Sonunda yeni bir proje oluşturmaya, yeni gizli anahtarı eski projeme kopyalamaya ve sonra yeni projeyi silmeye karar verdim .
cd ~/junk # Go to some safe directory to create a new project.
django-admin startproject django_scratch
grep SECRET_KEY django_scratch/django_scratch/settings.py # copy to old project
rm -R django_scratchGörünüşe göre Django bu get_random_secret_key()işlevi 1.10 sürümüne ekledi . Bunu yeni bir gizli anahtar oluşturmak için kullanabilirsiniz.
$ ./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
s!)5@5s79sp=92a+!f4v!1g0d0+64ln3d$xm1f_7=749ht&-zi
$ ./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
_)+%kymd=f^8o_fea1*yro7atz3w+5(t2/lm2cz70*e$2mn\g3
$startproject bakarsanız , cryptomodülü kullanarak rastgele bir dize oluşturduğunu görebilirsiniz .
Bu sayfaya göre https://docs.djangoproject.com/tr/dev/topics/signing/ , SECRET_KEY çoğunlukla geçici şeyler için kullanılır - örneğin kurcalamayı tespit edebilmeniz için kablo üzerinden gönderilen geçici veri imzalama. KESİNEBİLECEK şeyler şöyle:
Benden daha yeni ve / veya göze çarpan Django deneyimi olan biri, aksi takdirde chime olabilir, ancak açıkça imzalama API'sı ile bir şey yapmazsanız, bu sadece kullanıcılarınız için hafif bir rahatsızlık yaratmak gerekir.
SECRET_KEY dizesi temel olarak çerez verilerini şifrelemek ve / veya ayırmak için kullanılır. Varsayılan oturum çerezlerinin kendi dezavantajları olduğundan, birçok çerçeve (Django dahil) buna gelir.
Gizli bir alana sahip makaleleri düzenlemek için django'da formunuz olduğunu düşünün. Bu gizli alanda, düzenlediğiniz makalenin kimliği saklanır. Ve kimsenin size başka bir makale kimliği gönderemeyeceğinden emin olmak istiyorsanız, karma kimliğine sahip ekstra gizli bir alan ekleyeceksiniz. Birisi kimliği değiştirirse, bunu bileceksiniz çünkü karma aynı olmayacaktır.
Tabii ki bu önemsiz bir örnek ama SECRET_KEY bu şekilde kullanılıyor.
Django dahili olarak kullanıyor, örneğin {% csrf_token%} ve daha pek çok şey için. Sorunuza bağlı olarak değiştirirseniz ve kullanmadığınız takdirde uygulamanız üzerinde gerçekten bir etkisi olmamalıdır.
Tek şey, belki de oturum değerlerinin düşürülmesidir. Örneğin, kullanıcılar django oturumunu farklı bir anahtarla deşifre edemeyeceği için kullanıcıların tekrar admin'e giriş yapması gerekecek.
Ben de aynı hatayı yaptım. Varsayılan şifre 50 uzun oldu, bu yüzden 50 uzun rastgele bir dize oluşturmak için powershell kullandım ve onunla eski SECRET_KEY değiştirdim. Oturum açtım ve SECRET_KEY değiştirildikten sonra önceki oturumum geçersiz kılındı.
Powershell ( kaynak ) ile:
# Load the .net System.Web namespace which has the GeneratePassword function
[Reflection.Assembly]::LoadWithPartialName("System.Web")
# GeneratePassword(int length, int numberOfNonAlphanumericCharacters)
[System.Web.Security.Membership]::GeneratePassword(50,5)Bash ile ( kaynak ):
# tr includes ABCabc123 and the characters from OWASP's "Password special characters list"
cat /dev/urandom | tr -dc 'A-Za-z0-9!"#$%&\''()*+,-./:;<=>?@[\]^_`{|}~' | head -c 100 ; echoBu noktada neden daha büyük bir anahtarı denemediğimi düşündüm, bu yüzden 100 ve 1000 uzunluğunda bir anahtarla denedim. İkisi de çalıştı. Ben anlamak kaynak kodu , imzalayan işlevi tarafından döndürülen nesne base64 bir hmac bozulmasıdır. RFC 2104 , bir HMAC gizli anahtarının gerekli uzunluğu için bunu söyleyecektir.
B baytından daha uzun anahtarlar kullanan uygulamalar önce H tuşunu kullanır ve ardından HMAC'ın gerçek anahtarı olarak sonuçtaki L bayt dizesini kullanır.
HMAC anahtarı herhangi bir uzunlukta olabilir (B baytlarından daha uzun anahtarlar önce H kullanılarak karma yapılır). Bununla birlikte, fonksiyonun güvenlik gücünü azaltacağı için L bayttan daha azı kesinlikle önerilmez. L bayttan daha uzun tuşlar kabul edilebilir, ancak ekstra uzunluk işlev gücünü önemli ölçüde artırmaz. (Anahtarın rastgele olması zayıf kabul edilirse daha uzun bir anahtar önerilebilir.)
Normal konuşmaya çevirmek için gizli anahtarın boyutunun çıktıyla aynı boyutta olması gerekir. Anahtarın bit halinde olması gerekir. Base64'teki her bir rakam 6 biti temsil eder. 50 karakterlik bir parolanız varsa, 50 x 6 = 300 bit gizli anahtarınız olacaktır. SHA256 kullanıyorsanız, 256 bitlik bir anahtara ihtiyacınız olacaktır ( sha256 tanım gereği 256 bit kullanır ). SHA256'dan daha büyük bir karma algoritması kullanmayı düşünmüyorsanız, 50 uzunluğunda bir şifre çalışmalıdır.
Ancak, anahtardaki herhangi bir ekstra bit karma olduğundan, boyutu büyük ölçüde performansı düşürmez. Ancak, daha büyük hash fonksiyonları için yeterli bitiniz olduğunu garanti eder. SHA-512, 100 uzunluğunda bir SECRET_KEY ( 50 x 6 = 600 bit> 512 bit ) ile kaplanacaktır .
data decode will breakbiraz daha detaylandırabilir ve belki de kırılacak bazı kodlara (django veya örnek projede) dikkat çeker misiniz? EDIT: hala django 1.4 kullanıyor - durum böyle mi?