ScotlandPHP

Güvenli Parola Karıştırma

Bu bölümde, parolaları güvenlik altına alma da kullanılan karıştırma (hashing) işlevinin arka planını ve etkin bir şekilde nasıl uygulayabileceğimizi ele alacağız.

Kullanıcıların girmiş olduğu parolaları neden karıştırmalıyım?

Parola karıştırma, kullanıcıların parola girerek kullandıkları bir uygulamanın tasarımında, mutlaka göz önüne alınması gereken en temel güvenlik faktörlerinden birisidir. Parola karıştırma tekniği kullanılmadığı takdirde, uygulamanızın veri tabanında saklanan her türlü parola veritabanınızı ele geçirenler tarafından çalınabilir ve ardından sadece uygulamanız değil uygulamanızı kullanan kullanıcılar aynı parolayı başka servisler için de kullanıyorlarsa risk altında kalırlar.

Kullanıcılarınızın parolalarını veri tabanına kaydetmeden önce, uygulayacağınız karıştırma algoritması ile saldırganın özgün parolayı tahminini imkansız kılarken, ilerleyen süreçte de özgün parolayı bulma çabalarını da (kaba kuvvet saldırısı tekniğiyle) zorlaştırmış olursunuz.

Ancak, dikkat edilmesi gereken önemli nokta, parola karıştırma sadece veri kaynağınızın ele geçirilmesine karşı koruma sağlarken, uygulamanıza isteminiz dışında yerleştirilmiş zararlı kodlar aracılığıyla şifreleri ele geçirmede koruma sağlamaz.

MD5() ve SHA1() gibi genel karıştırma işlevlerini parolalar için kullanmak neden uygun değildir?

MD5, SHA1 ve SHA256 gibi karıştırma algoritmaları verimli ve çok hızlı olmaları için tasarlanmıştır. Modern teknikler ve bilgisayar ekipmanları ile, Kaba kuvvet (brute force) atak tekniği kullanarak özgün değere ulaşma sıradan bir hale gelmiştir.

Çünkü, modern bir bilgisayar, oldukça hızlı olarak bu karıştırma tekniklerini tersine çevirir, çoğu güvenlik uzmanı da bunların parola karıştırma da kullanımına karşı aleyhte tavsiye de bulunur.

Genel karıştırma teknikleri kullanışlı olmadıklarına göre, parolalarımı nasıl karıştırmalıyım?

Parolaları karıştırmada, dikkate alınması gereken iki husus vardır; hesaplamanın maliyeti ve tuzlama. Karıştırma algoritmasında daha fazla hesaplama maliyeti demek kaba kuvvet ataklarının daha fazla zaman gerektirmesi demektir.

PHP 5.5, güvenli bir şekilde karıştırma ve parola doğrulamayı birlikte güvenle sağlayan bir yerel parola karıştıma APIsi sağlamaktadır. Ayrıca PHP 5.3.7 sürümünden itibaren kullanılabilen » saf bir PHP uyumluluk kütüphanesi de vardır.

Diğer bir seçenek PHP 5.3 sürümünden itibaren çeşitli karıştırma algoritmalarını destekleyen crypt() işlevidir. Bu işlevi kullanırken, PHP, desteklenen her bir algoritmayı kendi bünyesinde barındırdığı için, algoritmalardan bir veya bir kaçı sisteminizde bulunmasa da seçtiğiniz algoritmanın varlığını ve kullanımını garanti eder.

Parola karıştırma da tavsiyemiz Blowfish algoritmasını kullanmanızdır, parola karıştırma APIsi tarafından da öntanımlı olarak kullanılan bu algoritma MD5 veya SHA1 den daha fazla hesaplama gerektirmesine rağmen hala ölçeklenebilir durumdadır.

Bir parolayı doğrulamak için crypt() kullanıyorsanız, bir sabit zaman dizgesi karşılaştırması kullanarak zamanlama saldılarını engellemeyi düşünmeniz gerekir. Ne PHP'nin == ve === işleçleri ne de strcmp() işlevi sabit zaman dizgesi karşılaştırması yapar. password_verify() bunu sizin için yapacak gibi görünse de mümkün oldğunca yerel parola karıştıma APIsini kullanmanızı şiddetle öneririz.

Tuzlama nedir?

Bir şifreleme tuzu, gökkuşağı tablosu olarak bilinen, daha önceden hesaplanarak oluşturulmuş karıştırma listesinden karşılaştırma yaparak eşleştirme ihtimalini ortadan kaldırmak için, karıştırma işlemi esnasında uygulanan bir değerdir.

Basit anlamda tuz, karıştırılmış değerinizi kırma teşebbüslerini zorlaştırmada kullanılan ek bir veridir. İnternet üzerinde, daha önceden hesaplanmış kapsamlı karıştırma değerlerinin yanı sıra özgün değerleri de barındıran bir dizi liste hizmeti vardır. Tuz kullanmak bu listelerden karıştırma değerini bulmayı mantıksız veya imkansız kılar.

Bir tane sağlanmamışsa password_hash() rasgele bir tuz oluşturacaktır ve bu genelde en kolay ve en güvenilir yaklaşımdır.

Tuzlarımı nasıl saklarım?

password_hash() veya crypt() işlevini kullanırken, dönen değer üretilen karıştırılmış parola olup tuzu da içerir. Parolaları doğrularken password_verify() veya crypt() işlevine doğrudan verilebilecek şekilde karıştırma bilgisini içeren bu değer veritabanınızda hiç değiştirlmeden harfi harfine saklanmalıdır.

Aşağıdaki şekil, crypt() veya password_hash() işlevinden dönen değerin biçimini gösterir. Görebileceğiniz gibi, ileriki bir parola doğrulaması için gereken tuzu ve algoritma ile ilgili tüm bilgiyi içinde barındırmaktadır.


        password_hash veya crypt işlevinden dönen değerin bileşenleri:
        sırasıyla, seçilen algoritma, algoritmanın seçenekleri, kullanılan tuz
        ve karıştırlmış parola.

add a note add a note

User Contributed Notes 4 notes

up
96
alf dot henrik at ascdevel dot com
3 years ago
I feel like I should comment some of the clams being posted as replies here.

For starters, speed IS an issue with MD5 in particular and also SHA1. I've written my own MD5 bruteforce application just for the fun of it, and using only my CPU I can easily check a hash against about 200mill. hash per second. The main reason for this speed is that you for most attempts can bypass 19 out of 64 steps in the algorithm. For longer input (> 16 characters) it won't apply, but I'm sure there's some ways around it.

If you search online you'll see people claiming to be able to check against billions of hashes per second using GPUs. I wouldn't be surprised if it's possible to reach 100 billion per second on a single computer alone these days, and it's only going to get worse. It would require a watt monster with 4 dual high-end GPUs or something, but still possible.

Here's why 100 billion per second is an issue:
Assume most passwords contain a selection of 96 characters. A password with 8 characters would then have 96^8 = 7,21389578984e+15 combinations.
With 100 billion per second it would then take 7,21389578984e+15 / 3600 = ~20 hours to figure out what it actually says. Keep in mind that you'll need to add the numbers for 1-7 characters as well. 20 hours is not a lot if you want to target a single user.

So on essence:
There's a reason why newer hash algorithms are specifically designed not to be easily implemented on GPUs.

Oh, and I can see there's someone mentioning MD5 and rainbow tables. If you read the numbers here, I hope you realize how incredibly stupid and useless rainbow tables have become in terms of MD5. Unless the input to MD5 is really huge, you're just not going to be able to compete with GPUs here. By the time a storage media is able to produce far beyond 3TB/s, the CPUs and GPUs will have reached much higher speeds.

As for SHA1, my belief is that it's about a third slower than MD5. I can't verify this myself, but it seems to be the case judging the numbers presented for MD5 and SHA1. The issue with speeds is basically very much the same here as well.

The moral here:
Please do as told. Don't every use MD5 and SHA1 for hasing passwords ever again. We all know passwords aren't going to be that long for most people, and that's a major disadvantage. Adding long salts will help for sure, but unless you want to add some hundred bytes of salt, there's going to be fast bruteforce applications out there ready to reverse engineer your passwords or your users' passwords.
up
12
swardx at gmail dot com
1 year ago
A great read..

https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/

Serious Security: How to store your users’ passwords safely

In summary, here is our minimum recommendation for safe storage of your users’ passwords:

    Use a strong random number generator to create a salt of 16 bytes or longer.
    Feed the salt and the password into the PBKDF2 algorithm.
    Use HMAC-SHA-256 as the core hash inside PBKDF2.
    Perform 20,000 iterations or more. (June 2016.)
    Take 32 bytes (256 bits) of output from PBKDF2 as the final password hash.
    Store the iteration count, the salt and the final hash in your password database.
    Increase your iteration count regularly to keep up with faster cracking tools.

Whatever you do, don’t try to knit your own password storage algorithm.
up
5
fluffy at beesbuzz dot biz
5 years ago
The security issue with simple hashing (md5 et al) isn't really the speed, so much as the fact that it's idempotent; two different people with the same password will have the same hash, and so if one person's hash is brute-forced, the other one will as well.  This facilitates rainbow attacks.  Simply slowing the hash down isn't a very useful tactic for improving security.  It doesn't matter how slow and cumbersome your hash algorithm is - as soon as someone has a weak password that's in a dictionary, EVERYONE with that weak password is vulnerable.

Also, hash algorithms such as md5 are for the purpose of generating a digest and checking if two things are probably the same as each other; they are not intended to be impossible to generate a collision for.  Even if an underlying password itself requires a lot of brute forcing to determine, that doesn't mean it will be impossible to find some other bit pattern that generates the same hash in a trivial amount of time.

As such: please, please, PLEASE only use salted hashes for password storage.  There is no reason to implement your own salted hash mechanism, either, as crypt() already does an excellent job of this.
up
-6
sgbeal at googlemail dot com
5 years ago
sha1 in conjunction with one or more salt values need not be as insecure as the above makes it out to be. e.g. the Fossil SCM creates an sha1 password hash based on a user's clear-text password combined with the user's name and a shared secret known only to the specific source repository for which the user is set up.
To Top