Karma şifre alanı için hangi veri türü ve hangi uzunluk kullanılır?


268

Şifre karma nasıl çalışır emin değilim (daha sonra uygulayacak), ama şimdi veritabanı şeması oluşturmak gerekir.

Şifreleri 4-20 karakterle sınırlamayı düşünüyorum, ancak hash dizesini şifreledikten sonra anladığım gibi farklı uzunlukta olacak.

Peki, bu şifreleri veritabanında nasıl saklayabilirim?


Ayrıca Openwall'un PHP şifre karma çerçevesine (PHPass) bakın. Taşınabilir ve kullanıcı şifreleri üzerinde yaygın saldırılara karşı sertleştirilmiş. Çerçeveyi yazan kişi (SolarDesigner) John The Ripper'ı yazan ve Password Hashing Yarışması'nda yargıç olarak oturan aynı adamdır . Bu yüzden parola saldırıları hakkında bir iki şey biliyor.
jww

2
Lütfen şifrelerinize üst limit koymayın. Onları hash ediyorsun, üst limit için depolama nedeni yok. Parola karmasını kullanan DoS saldırıları konusunda endişeleriniz varsa, 1000 veya 1024 makul bir üst sınırdır.
Iiridayn

neden şifre uzunluğunu sınırlamalı? En azından bir kullanıcının 100 karakterlik bir şifre oluşturmasına izin ver :)
Andrew

4 karakter parolalar için oldukça tehlikeli bir alt sınırdır, çünkü bunlar çatlamak için önemsizdir. En azından 8 kullanın ama 14 veya 16 çok daha iyi.
quikchange

Bu, eski bir cevabı olan çok eski bir sorudur. Güncel olmak için Gilles cevabına bakınız .
kelalaka

Yanıtlar:


448

Güncelleme: Sadece bir hash fonksiyonu kullanmak şifreleri saklamak için yeterince güçlü değildir. Daha ayrıntılı bir açıklama için Gilles'ten bu konudaki cevabı okumalısınız .

Parolalar için, Bcrypt veya Argon2i gibi bir anahtar güçlendirme karma algoritması kullanın. Örneğin, PHP'de varsayılan olarak Bcrypt kullanan password_hash () işlevini kullanın .

$hash = password_hash("rasmuslerdorf", PASSWORD_DEFAULT);

Sonuç, aşağıdakine benzer 60 karakterlik bir dizedir (ancak basamaklar değişecektir, çünkü benzersiz bir tuz üretir).

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

CHAR(60)Bir Bcrypt karma kodlamasını depolamak için SQL veri türünü kullanın. Bu işlevin onaltılık basamaklardan oluşan bir dize olarak kodlanmadığına dikkat edin, bu nedenle ikili dosyada saklamak için kolayca onu çözemeyiz.

Diğer hash işlevlerinin hala kullanımları vardır, ancak şifreleri saklamak için değil, bu yüzden 2008'de yazılmış orijinal cevabı aşağıda tutacağım.


Bu, kullandığınız karma algoritmaya bağlıdır. Karma, girdiden bağımsız olarak her zaman aynı uzunlukta bir sonuç üretir. Onaltılı basamaktan oluşan bir dizi olarak metindeki ikili karma sonucunu temsil etmek tipiktir. Veya UNHEX()bir onaltılık basamak dizesini yarıya indirmek için bu işlevi kullanabilirsiniz .

  • MD5, 128 bit karma değeri oluşturur. CHAR (32) veya BINARY (16) kullanabilirsiniz
  • SHA-1, 160 bitlik karma değer üretir. CHAR (40) veya BINARY (20) kullanabilirsiniz
  • SHA-224, 224 bitlik karma değer üretir. CHAR (56) veya BINARY (28) kullanabilirsiniz
  • SHA-256, 256 bit karma değeri üretir. CHAR (64) veya BINARY (32) kullanabilirsiniz
  • SHA-384, 384 bitlik bir karma değer oluşturur. CHAR (96) veya BINARY (48) kullanabilirsiniz
  • SHA-512, 512 bit karma değeri üretir. CHAR (128) veya BINARY (64) kullanabilirsiniz
  • BCrypt, uygulamaya bağlı 448 bit karma değeri üretir. CHAR (56), CHAR (60), CHAR (76), BINARY (56) veya BINARY (60) 'a ihtiyacınız olabilir.

NIST, 2015 itibariyle birlikte çalışabilirlik gerektiren karma işlevlerin tüm uygulamaları için SHA-256 veya daha üstünün kullanılmasını önerir . Ancak NIST, şifreleri güvenli bir şekilde saklamak için bu basit sağlama işlevlerini kullanmanızı önermez.

Daha az karma algoritmaların kullanımları vardır (bir uygulama için dahili, değişim için değil), ancak kırılabilir oldukları bilinmektedir .


47
@Hippo: Lütfen kullanıcı adını tuz olarak kullanmayın. Kullanıcı başına rastgele bir tuz üret.
Bill Karwin

11
Evet, aynı satırda saklamamanız için hiçbir neden yok. Bir saldırgan veritabanınıza erişse bile, gökkuşağı tuzlarını bu tuza dayanarak inşa etmeleri gerekir. Ve bu sadece şifreyi tahmin etmek kadar işe yarar.
Bill Karwin

5
@SgtPooki: Tuzu düz metin halinde saklamak için başka bir sütuna ihtiyacınız var. Daha sonra, kullanıcının parolasını yazarken aynı tuzla hash edebilir ve sonucu tabloda saklanan karma özeti ile karşılaştırabilirsiniz.
Bill Karwin

12
Tuzu aynı tabloda (veya aynı erişim izinlerine sahip başka bir yerde) saklıyorsanız, kullanıcı adını tuz olarak kullanmamanız için hiçbir neden yoktur, çünkü kullanıcı başına benzersiz olacaktır. Bununla birlikte, bilinen herhangi bir tuz, karmayı bilinen bir tuz olmadığından daha kriptografik olarak zayıflatır. Bir tuz sadece bilinmiyorsa değer katar.
fijiaaron

9
Bilinen ve bilinmeyen tuzla olan anlaşmayı anlamıyorum. Bir site uyguluyorsanız - tuzun, şifreyi test eden giriş sayfası / script / sevice tarafından bilinmesi gerekir. Yani - siz "bilinmeyen" tuz savunucuları - giriş işleminin kodunun saldırgan tarafından bilinmediğini mi düşünüyorsunuz? Aksi takdirde - saldırgan , rastgele, benzersiz, karma parola ile birlikte veya ayrı olarak depolanmış olsun, tuzu her zaman bilmeyecek mi?
mattstuehler

13

Aslında kullanabilirsiniz CHAR(karma uzunluğu) her müzakere algoritması hep aynı karakter sayıda dışarı değerlendirecek çünkü MySQL için veri türünü tanımlamak için. Örneğin, SHA1her zaman 40 karakterlik bir onaltılık sayı döndürür.


1
SHA-1 parolaları karma yapmak için uygun değildir.
Gilles 'SO- kötü olmayı kes'

10

Her zaman bir şifre karma algoritması kullanın: Argon2 , scrypt , bcrypt veya PBKDF2 .

Argon2 , 2015 şifre karma yarışmasını kazandı. Scrypt , bcrypt ve PBKDF2 şu anda daha az tercih edilen, ancak yine de temelde sağlam olan eski algoritmalardır, bu nedenle platformunuz Argon2'yi henüz desteklemiyorsa, şimdilik başka bir algoritma kullanmak iyidir.

Parolayı asla doğrudan veritabanında saklamayın. Şifrelemeyi de yapmayın: aksi takdirde, siteniz ihlal edilirse, saldırgan şifre çözme anahtarını alır ve böylece tüm şifreleri alabilir. Şifreler karma olmalıdır ZORUNLU .

Bir şifre karma bir karma tablo karma veya şifreleme karması farklı özelliklere sahiptir. Parola üzerinde asla MD5, SHA-256 veya SHA-512 gibi sıradan bir şifreleme karması kullanmayın. Parola karma algoritması benzersiz bir tuz kullanır (başka herhangi bir kullanıcı veya başka birinin veritabanında kullanılmaz). Tuz, saldırganların sadece ortak parolaların karmalarını önceden hesaplayamaması için gereklidir: bir tuzla, her hesap için hesaplamayı yeniden başlatmaları gerekir. Parola karma algoritması özünde yavaştır - karşılayabildiğiniz kadar yavaştır. Yavaşlık saldırganı sizden çok daha fazla incitir çünkü saldırganın birçok farklı parola denemesi gerekir. Daha fazla bilgi için bkz . Parolaları güvenli bir şekilde sağlama .

Parola karması dört bilgiyi kodlar:

  • Hangi algoritmanın kullanıldığının bir göstergesi. Bu çeviklik için gereklidir : kriptografik öneriler zamanla değişir. Yeni bir algoritmaya geçiş yapabilmeniz gerekir.
  • Zorluk veya sertlik göstergesi. Bu değer ne kadar yüksek olursa, karma değerini hesaplamak için o kadar fazla hesaplama gerekir. Bu, parola değiştirme işlevinde sabit veya genel bir yapılandırma değeri olmalıdır, ancak bilgisayarlar hızlandıkça zaman içinde artmalıdır, bu nedenle her bir hesap için değeri hatırlamanız gerekir. Bazı algoritmaların tek bir sayısal değeri vardır, diğerlerinin orada daha fazla parametresi vardır (örneğin CPU kullanımını ve RAM kullanımını ayrı ayrı ayarlamak için).
  • Tuz. Tuzun küresel olarak benzersiz olması gerektiğinden, her hesap için saklanması gerekir. Tuz, her şifre değişikliğinde rastgele oluşturulmalıdır.
  • Karma uygun, yani karma algoritmasındaki matematiksel hesaplamanın çıktısı.

Birçok kütüphane, bu bilgiyi uygun bir şekilde tek bir dize olarak paketleyen bir çift işlevi içerir: algoritma göstergesini, sertlik göstergesini ve parolayı alan, rastgele bir tuz üreten ve tam karma dizesini döndüren; ve parola ve tam sağlama dizesini girdi olarak alan ve parolanın doğru olup olmadığını gösteren bir boole döndüren bir parola. Evrensel bir standart yoktur, ancak ortak bir kodlama

$ algorithm $ parametreleri $ salt $ çıktı

nerede algorithmbir sayı veya algoritmanın seçimi deşifre eden kısa alfanümerik dizedir parametersyazdırılabilir dize ve saltve outputsonlandırma olmadan Base64 kodlanıyor =.

Tuz ve çıktı için 16 bayt yeterlidir. (Örneğin Argon2 için önerilere bakın .) Base64 ile kodlanmıştır, her biri 21 karakterdir. Diğer iki bölüm algoritmaya ve parametrelere bağlıdır, ancak 20-40 karakter tipiktir. Bu , alanı daha sonra büyütmenin zor olacağını düşünüyorsanız, bir güvenlik marjı eklemeniz gereken toplam yaklaşık 82 ASCII karakteri ( CHAR(82)ve Unicode'a gerek yoktur).

Karmayı ikili biçimde kodlarsanız, algoritma için 1 bayta, sertlik için 1–4 bayta (bazı parametrelerin kodunu sabit olarak kodlarsanız) ve tuz ve çıktı için her biri 16 bayta kadar alabilirsiniz. , toplam 37 bayt için. En az birkaç yedek bayta sahip olmak için 40 bayt ( BINARY(40)) deyin . Bunların yazdırılabilir karakterler değil, 8 bit bayt olduğunu, özellikle alanın boş bayt içerebileceğini unutmayın.

Karma uzunluğunun parola uzunluğuyla tamamen alakasız olduğunu unutmayın.


9

Tuzlama ile ilgili bu Wikipedia makalesini değerli bulabilirsiniz . Fikir, karma değerinizi rastgele ayarlamak için belirli bir bit veri eklemektir; bu, birisi şifre karmalarına yetkisiz erişirse şifrelerinizi sözlük saldırılarına karşı koruyacaktır.


2
Bu gerçekten çok değerli (+1), ancak soruya cevap vermiyor! (-1)
Bill Karwin

3
Evet, ama bu bağlamda kesinlikle alakalı (+1)
Treb

7

Sabit uzunluklu bir dize olarak (VARCHAR (n) veya MySQL bunu çağırır). Bir karma her zaman örneğin 12 karakterlik sabit bir uzunluğa sahiptir (kullandığınız karma algoritmaya bağlı olarak). Böylece 20 karakterlik bir şifre 12 karakterlik bir karmaya, 4 karakterlik bir şifre de 12 karakterlik bir karmaya neden olur.


3
'ya da MySQL bunu çağırıyor' - MYSQL buna CHAR diyor. Bu tip sabit uzunluk değeri içindir. Bu yüzden CHAR'ın VARCHAR'dan daha iyi bir tip olduğunu düşünüyorum.
t298712383

4

TEXTİleri uyumluluk için (sınırsız sayıda karakter depolamak) kullanmalısınız . Karma algoritmalar (gerekmesi) zamanla güçlenir ve bu veritabanı alanının zaman içinde daha fazla karakteri desteklemesi gerekir. Ayrıca, geçiş stratejinize bağlı olarak, yeni ve eski karmaları aynı alanda depolamanız gerekebilir, bu nedenle uzunluğun bir tür karmaya sabitlenmesi önerilmez.


3

Bu gerçekten kullandığınız karma algoritmaya bağlıdır. Doğru hatırlıyorsam, şifrenin uzunluğunun karma uzunluğuyla ilgisi yoktur. Kullandığınız karma algoritmasındaki teknik özelliklere bakın, birkaç test yapın ve hemen üzerinde kesin.


3

Karmalar bir bit dizisidir (algoritmaya bağlı olarak 128 bit, 160 bit, 256 bit vb.). MySQL izin veriyorsa, sütununuz ikili yazılmalı, metin / karakter yazılmamalıdır (SQL Server veri türü binary(n)veya varbinary(n)). Ayrıca karmaları da tuzlamalısınız. Tuzlar metin veya ikili olabilir ve karşılık gelen bir sütuna ihtiyacınız olacaktır.


Adalet burada tamamen doğru - MySQL bunları sayısal değerler olarak saklayacak ve bu sütunda aramayı dize eşleşmesi yapmaktan çok daha verimli hale getirecektir, ancak tuzlar tuzlu verilerin yanında veritabanında saklanmamalıdır - bu da tuzların sağladığı güvenliği ortadan kaldırır .
Tony Maro

6
Tuzlar gizli değildir . Sadece gizli şifre. Her yeni şifrenin yeni bir tuz aldığından emin olun. Kullanıcı parolasını her değiştirdiğinde, sistem bu parola için yeni bir tuz oluşturmalıdır. Tuzlar, kriptografik olarak güvenli bir PRNG'den üretilen 16 bayt gibi uzun ve rasgele olmalıdır.
yfeldblum

1
@TonyMaro SQL düzeyinde bir parola dizesinin eşleşip eşleşmediğinden emin değilsiniz. Başka bir deyişle, veritabanınızda bir şifre aramamalı, bunun yerine kullanıcıyı kullanıcı adına göre almalı ve şifreleri SQL yerine kodla karşılaştırmalısınız.
bart

1

Ben her zaman şifreli bir dize MAX dize uzunluğunu bulmak için test ve bir VARCHAR türü karakter uzunluğu olarak ayarlamak. Kaç kayda sahip olacağınıza bağlı olarak, veritabanı boyutuna gerçekten yardımcı olabilir.


Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.