Kullanıcı Şifrelerinin Temizlenmesi


100

Kullanıcı tarafından sağlanan şifreleri hash hale getirmeden ve veritabanımda saklamadan önce nasıl kaçmalı veya temizlemeliyim?

PHP geliştiricileri, güvenlik amacıyla kullanıcıların şifrelerini karıştırmayı düşündüklerinde, genellikle bu şifreleri kullanıcı tarafından sağlanan diğer veriler gibi düşünme eğilimindedirler. Bu konu, parola depolamayla ilgili PHP sorularında sıklıkla ortaya çıkar; geliştirici genellikle gibi işlevleri kullanarak şifreyi temizlemek istiyor escape_string()(çeşitli iterasyonlarında), htmlspecialchars(), addslashes()ve bunu karma ve veritabanında saklayarak önce diğerleri.


1
kullanıcı base64 kodlayabilir
MSS

@MSS yok, yapmamalısınız çünkü base64 kodlama yapıyor , şifreleme veya karma oluşturma değil . Şifrelere her zaman hashing uygulanmalıdır .
Jay Blanchard

1
Hash'ten önce demek istiyorum;)
MSS

Hashing yapmadan önce bunu yapmamalısınız ve yapmanıza gerek yoktur. Gereksiz ek kod yazmak zorunda kalmanıza neden olur @MSS
Jay Blanchard

Yanıtlar:


100

password_hash()Bir dizi nedenden ötürü PHP'lerle hashing uygulayacağınız şifreler üzerinde asla kaçmamalı, düzeltmemeli veya başka herhangi bir temizleme mekanizması kullanmamalısınız , bunların en büyüğü, şifre için ek temizlik yapmak gereksiz ek kod gerektirmesidir.

Tüm kullanıcı girdilerini temizlememiz gerektiğini ve kullanıcılarımızdan aldığımız diğer her bilgi için haklı olacağınızı iddia edeceksiniz (ve sisteminizde kullanıcı verilerinin kabul edildiği her gönderide bunu göreceksiniz). Şifreler farklıdır. Karma şifreler herhangi bir SQL enjeksiyon tehdidi sunamaz çünkü dize veritabanında depolanmadan önce karma hale getirilir.

Bir parolaya hashing uygulamak, parolayı veritabanınızda saklamak için güvenli hale getirme eylemidir. Karma işlevi herhangi bir bayta özel bir anlam vermez, bu nedenle güvenlik nedeniyle girdisinin temizlenmesi gerekmez

Kullanıcıların istedikleri şifreleri / cümleleri kullanmalarına izin verme mantralarını takip ederseniz ve şifreleri sınırlamazsanız , herhangi bir uzunluğa, herhangi bir sayıda boşluğa ve herhangi bir özel karakter karmasına izin vermek, içinde ne olursa olsun şifreyi / parolayı güvenli hale getirir. şifre. Şu anda en yaygın karma (varsayılan), PASSWORD_BCRYPTşifreyi, karma şifre bilgileri ve bir maliyetle birlikte rastgele bir tuz içeren 60 karakter genişliğinde bir dizeye dönüştürür (karma oluşturmanın algoritmik maliyeti):

PASSWORD_BCRYPT, CRYPT_BLOWFISH algoritmasını kullanarak yeni parola karmaları oluşturmak için kullanılır. Bu, her zaman 60 karakter genişliğinde olan "$ 2y $" şifreleme biçimini kullanan bir hash ile sonuçlanacaktır.

Karmanın depolanması için alan gereksinimleri, işleve farklı karma oluşturma yöntemleri eklendikçe değişebilir, bu nedenle VARCHAR(255)veya gibi depolanan karma için sütun türünde daha büyük olmak her zaman daha iyidir TEXT.

Şifreniz olarak eksiksiz bir SQL sorgusu kullanabilirsiniz ve bu sorgu, SQL motoru tarafından yürütülemez hale getirilerek, örneğin,

SELECT * FROM `users`;

Hashing yapılabilir $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

Farklı temizleme yöntemlerinin parolayı nasıl etkilediğini görelim -

Parola I'm a "dessert topping" & a <floor wax>!(Burada gösterilmeyen parolanın sonunda 5 boşluk vardır.)

Aşağıdaki kırpma yöntemlerini uyguladığımızda çılgınca farklı sonuçlar elde ederiz:

var_dump(trim($_POST['upassword']));
var_dump(htmlentities($_POST['upassword']));
var_dump(htmlspecialchars($_POST['upassword']));
var_dump(addslashes($_POST['upassword']));
var_dump(strip_tags($_POST['upassword']));

Sonuçlar:

string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // double quotes, ampersand and braces have been changed
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>!     " // escape characters have been added
string(34) "I'm a "dessert topping" & a !     " // looks like we have something missing

Bunları gönderdiğimizde ne olur password_hash()? Yukarıda sorgunun yaptığı gibi hepsi hashed edilir. Parolayı doğrulamaya çalıştığınızda sorun ortaya çıkar. Bu yöntemlerden birini veya birkaçını kullanırsak, bunları karşılaştırmadan önce onları yeniden kullanmalıyız password_verify(). Aşağıdakiler başarısız olur:

password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query

Bunun sonucunu parola doğrulamada kullanmadan önce, gönderilen parolayı seçtiğiniz temizleme yöntemiyle çalıştırmanız gerekir. Gereksiz bir dizi adımdır ve hash'i daha iyi yapmaz.


5.5'ten daha düşük bir PHP sürümü mü kullanıyorsunuz? password_hash() Uyumluluk paketini kullanabilirsiniz .

MD5 şifre karmalarını gerçekten kullanmamalısınız .


13
O izin verilir sonunda boşluk şifresini yarattı sayılı, o giriş @DanBracuk bunları kullanması gerekir
Jay Blanchard

12
Ne kadar @DanBracuk? Baştaki / sondaki boşluklar dahil olmak üzere kullanıcının istediği şifreyi ayarlamasına izin verirsek?
Jay Blanchard

16
Bu nedenle çoğu şey, seçtiğiniz parolayı iki kez girmenizi gerektirir. Kullanıcı kaza anında boşlukları eklerse, daha fazla ilerlemeden bunu anlayacaklardır. Kullanıcı bunu bilerek yaptıysa sorun değil.
Bir ayıyla güreştim.

4
@MargaretBloom, pratik bir kural sadece bir buluşsal yöntemdir. Bazen şifreler gibi bazı şeyleri derinlemesine düşünmemiz gerekir. "Gelecekte işlerin nasıl değişeceğini kimse bilmiyor" diyorsunuz, ancak görünen o ki, herhangi bir şey değişecekse, bu verileri veritabanına koymadan önce veriden kaçış şeklimizdir, bu durumda kullanıcılar şifreleri hayır olduğunda kendilerini kilitlenmiş bulurlar. sakladığımızla daha uzun eşleşir. Parola karmalarından kaçmamanın tehlikesi ve bunlardan kaçma tehlikesi nedir?
DavidS

3
Kesin olarak: Sınırlı anlamda "karmaşadan kaçacaksınız", bunu parametreleştirilmiş bir SQL sorgusuna doğru bir şekilde geçireceksiniz, burada SQL bağlayıcınızdaki bazı kodlar onunla "kaçmaya" karşılık gelen herhangi bir şey yapabilir veya yapmayabilir, yapamazsınız. bilmiyorum ve umursamıyorum. Bunu başarmak için herhangi bir özel kod yazmak zorunda kalmayacaksınız çünkü daha önce bazı kötü yaşam kararları vermediyseniz, tüm SQL sorgularınız için tamamen rutin.
Steve Jessop

36

Parolaya hashing uygulamadan önce, parolayı RFC 7613'ün 4. bölümünde anlatıldığı gibi normalleştirmelisiniz . Özellikle:

  1. Ek Eşleme Kuralı: ASCII olmayan alanın herhangi bir örneği ASCII alanına (U + 0020) eşlenmelidir ZORUNLU; ASCII olmayan bir alan, Unicode genel kategorisi "Zs" olan herhangi bir Unicode kod noktasıdır (U + 0020 hariç).

ve:

  1. Normalleştirme Kuralı: Unicode Normalleştirme Formu C (NFC) tüm karakterlere uygulanmalıdır ZORUNLU.

Bu, kullanıcı aynı parolayı ancak farklı bir giriş yöntemi kullanarak girerse, parolanın yine de kabul edilmesini sağlamaya çalışır.


3
@DavidS, Süper parlak bir Kuzey Amerika Mac Kitabı (Joe'nun ayrılmadan hemen önce kullandığı) ve yetersiz bir şekilde uluslararasılaştırılmış Tayvanlı bir internet kafe bilgisayarı (Joe'nun indirmek için kullanmaya çalıştığı uçuş geri biniş kartı).
Margaret Bloom

2
Kulağa çılgınca geliyor. :-) Yine de teşekkürler.
DavidS

3
Hmm. Bunu yaparsanız, henüz atanmamış karakterler içerenleri reddetmek için parolaları da doğrulamanız gerekir. Bir kullanıcının uygulamanızın tanımadığı ve bu nedenle olduğu gibi karma oluşturduğu NEWFANGLED SPACE kullanması ve ardından Unicode Karakter Veritabanınızı yükseltirseniz ve aniden NEWFANGLED SPACE, hashing işleminden önce SPACE ile eşlenirse korkunç olur. artık uygulamanızın eski karmaya hash oluşturacağı bir şifre giremezsiniz.
ruakh

4
@JayBlanchard Çünkü bir makinede bir boşluk tuşuna bastığınızda ve başka bir makinede bu tuşa bastığınızda, iki farklı Unicode kod noktası elde edebilirsiniz ve kullanıcı hiçbir şeyin farkında olmadan iki farklı UTF-8 kodlamasına sahip olurlar. Bunun göz ardı etmek isteyeceğiniz bir sorun olduğu söylenebilir, ancak RFC 7613 bu tür gerçek hayat sorunlarından doğmuştur, bu bir çalışma önerisi değildir.
Monica'yı

1
@ruakh Şifreleri belirli bir şekilde kullanmaya karar verdiğinizde, bu şekilde ele alınmaları gerekir, aksi takdirde işler mevcut kullanım durumlarında bozulacaktır. Gelecekte ön işleme yöntemini değiştirmeyi düşünüyorsanız, parolanın önceden işlenmiş ve karma hale getirilmiş temsili ile birlikte saklamalısınız. Bu şekilde, girdiyi aldıktan sonra, neyle karşılaştırdığınıza bağlı olarak ön işleme / hashing yöntemini seçersiniz.
Monica'yı
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.