CakeFest 2024: The Official CakePHP Conference

password_hash

(PHP 5 >= 5.5.0, PHP 7, PHP 8)

password_hashParola aşı oluşturur

Açıklama

password_hash(string $parola, string|int|null $algo, array $seçenekler = []): string

password_hash() işlevi güçlü ve tek yönlü bir aşlama algoritması kullanarak yeni bir parola aşı oluşturur.

Desteklenen algoritmalar:

  • PASSWORD_DEFAULT - Bcrypt algoritması kullanılır (PHP 5.5.0'dan itibaren öntanımlıdır). Bu sabitin, PHP'ye yeni ve daha güçlü algoritmalar eklendikçe zamanla değişmek üzere tasarlandığı unutulmamalıdır. Bu sebeple, bu tanımlayıcının kullanımından kaynaklanan sonucun uzunluğu zamanla değişebilir. Bu bakımdan, sonucun 60 karakterden fazla genişleyebilen bir veritabanı sütununda saklanması önerilir (255 karakter iyi bir seçim olacaktır).
  • PASSWORD_BCRYPT - Aş oluşturmak için CRYPT_BLOWFISH algoritması kullanılır. Bu, "$2y$" belirtecini kullanarak crypt() uyumlu standart bir aş oluşturacaktır. Sonuç her zaman 60 karakterlik bir dizge olacaktır, başarısızlık durumunda false döner.
  • PASSWORD_ARGON2I - Aş oluşturmak için Argon2i aşlama algoritması kullanılır. Bu algoritma sadece PHP, Argon2 desteği ile derlenmişse kullanılabilir.
  • PASSWORD_ARGON2ID - Aş oluşturmak için Argon2id aşlama algoritması kullanılır. Bu algoritma sadece PHP, Argon2 desteği ile derlenmişse kullanılabilir.

PASSWORD_BCRYPT için desteklenen seçenekler:

  • salt (string) - Parola aşlanırken kullanmak üzere elle bir tuz sağlamak için kullanılır. Bunun bir tuzun otomatik olarak oluşturulmasını geçersiz kılıp önleyeceği unutulmamalıdır.

    Belirtilmezse, aşlanan her parola için password_hash() tarafından rasgele bir tuz üretilir. Bu amaçlanan çalışma kipidir.

    Uyarı

    salt seçeneğinin kullanımı önerilmemektedir. Artık öntanımlı olarak üretilen tuzun kullanımı öneriliyor. PHP 8.0.0 ve sonrasında elle sağlanan tuz yok sayılmaktadır.

  • cost (int) - Kullanılması gereken algoritmik maliyeti belirtir. Bu değerin örnekleri crypt() işlevinde bulunabilir.

    Belirtilmezse, 10 öntanımlı değeri kullanılır. Bu iyi bir temel maliyettir, ancak donanımınıza bağlı olarak arttırılabilir.

PASSWORD_ARGON2I ve PASSWORD_ARGON2ID için desteklenen seçenekler:

Bağımsız Değişkenler

parola

Kullanıcı parolası.

Dikkat

Algoritma olarak PASSWORD_BCRYPT kullanımı parola bağımsız değişkeninin 72 bayttan kırpılmasına sebep olur.

algo

Parolaya karıştırma uygulamak için kullanılacak algoritmayı belirten parola algoritması sabiti.

seçenekler

Seçenekleri içeren ilişkisel bir dizi. Her algoritma için desteklenen seçenekler parola algoritması sabitleri bölümünde bulunabilir.

Belirtilmezse, rasgele bir tuz oluşturulur ve öntanımlı maliyet kullanılır.

Dönen Değerler

Başarılı olursa aşlanmış parola döner.

Kullanılan algoritma, maliyet ve tuz aşın parçası olarak döndürülür. Bu bakımdan aş, doğrulanması için gereken tüm bilgiyi içermiş olur. Böylece, password_verify() işlevinin aşı doğrulamak için ayrı bir yerde saklanmış tuz ve algoritma bilgisine ihtiyacı olmaz.

Sürüm Bilgisi

Sürüm: Açıklama
8.0.0 password_hash() başarısız olduğunda artık false döndürmüyor, onun yerine parola aşlama algoritması geçersizse ValueError, bilinmeyen bir hatadan dolayı parola aşlanamazsa Error istisnası oluşuyor.
8.0.0 algo bağımsız değişkeni artık null olabiliyor.
7.4.0 algo için artık bir dizge gerekiyor, ancak geriye uyumluluk için hala tamsayılar kabul ediliyor.
7.4.0 Argon2 parolalar için artık sodium eklentisi de bir diğer gerçeklenim olarak kullanılabiliyor.
7.3.0 PASSWORD_ARGON2ID kullanan Argon2id parolaları için destek eklendi.
7.2.0 PASSWORD_ARGON2I kullanan Argon2i parolaları için destek eklendi.

Örnekler

Örnek 1 - password_hash() örneği

<?php
/**
* Sadece mevcut öntanımlı algoritmayı kullanarak parolayı aşla.
* Bu şu anda BCRYPT'dir ve 60 karakterlik bir sonuç üretecektir.
*
* Öntanımlının zamanla değişebileceğine dikkat.
* Saklama alanı 60 karakterden fazlasını alabilmeli (255 iyidir)
*/
echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
?>

Yukarıdaki örnek şuna benzer bir çıktı üretir:

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Örnek 2 - Maliyet belirtilen password_hash() örneği

<?php
/**
* BCRYPT için öntanımlı maliyet 12'ye çıkarılmak isteniyor.
* BCRYPT için 60 karakter gerektiğine dikkat.
*/
$seçenekler = [
'cost' => 12,
];
echo
password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $seçenekler);
?>

Yukarıdaki örnek şuna benzer bir çıktı üretir:

$2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K

Örnek 3 - password_hash() iyi bir maliyet bulma örneği

<?php
/**
* Bu kod, karşılanabilir maliyetin ne kadar yüksek olduğunu
* belirlemek için sunucuyu sınayacaktır. Sunucuyu çok yavaşlatmadan
* atanabilecek en yüksek maliyetin belirlenmesi isteniyor. 10 iyi
* bir başlangıçtır ve sunucular yeterince hızlıysa fazlası daha iyidir.
* Aşağıdaki kod, etkileşimli oturum açılabilen sistemler için iyi bir sınır
* olarak ≤ 350 milisaniyelik süreyi hedeflemektedir.
*/
$süreHedefi = 0.35; // 350 milisaniye

$maliyet = 10;
do {
$maliyet++;
$ilk = microtime(true);
password_hash("test", PASSWORD_BCRYPT, ["cost" => $maliyet]);
$son = microtime(true);
} while ((
$son - $ilk) < $süreHedefi);

echo
"Yaklaşık maliyet bulundu: " . $maliyet;
?>

Yukarıdaki örnek şuna benzer bir çıktı üretir:

Yaklaşık maliyet bulundu: 12

Örnek 4 - Argon2i kullanılan password_hash() örneği

<?php
echo 'Argon2i aş: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>

Yukarıdaki örnek şuna benzer bir çıktı üretir:

Argon2i aş: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0

Notlar

Dikkat

Bu işlev için kendi tuzunuzu oluşturmamanız şiddetle tavsiye edilir. Tuz belirtilmezse, otomatik olarak güvenli bir tuz oluşturulur.

Yukarıda belirtildiği gibi, PHP 7.0'da salt seçeneğinin belirtilmesi, bir kullanımdan kaldırma uyarısı üretecektir. El ile tuz sağlama desteği, PHP 8.0'da kaldırıldı.

Bilginize:

Bu işlevin sunucularda sınanması ve cost bağımsız değişkeninin, işlevin etkileşimli sistemlerdeki çalışma süresinin 350 milisaniyeden daha az olmasını sağlayacak şekilde ayarlanması önerilir. Yukarıdaki örnek kod, donanım için iyi bir maliyet değeri seçilmesine yardımcı olacaktır.

Bilginize: Bu işlev tarafından desteklenen algoritmalarda yapılan güncellemeler (veya öntanımlı algoritmada yapılan değişiklikler) aşağıdaki kurallara uymalıdır:

  • Herhangi bir yeni algoritma, öntanımlı duruma gelmeden önce PHP'nin en az 1 tam sürümü için çekirdek kodda olmalıdır. Dolayısıyla, örneğin 7.5.5'te yeni bir algoritma eklenirse, 7.7'ye kadar öntanımlı olması uygun olmayacaktır (çünkü 7.6 ilk tam sürüm olacaktır). Ancak 7.6.0'da farklı bir algoritma eklenmişse, 7.7.0 öntanımlılık için uygun olacaktır.
  • Öntanımlı, düzeltme sürümünde değil, yalnızca tam sürümde (7.3.0, 8.0.0 vb.) değişmelidir. Bunun tek istisnası, geçerli öntanımlıda kritik bir güvenlik açığı bulunduğunda ortaya çıkan aciliyet durumudur.

Ayrıca Bakınız

add a note

User Contributed Notes 10 notes

up
140
phpnetcomment201908 at lucb1e dot com
4 years ago
Since 2017, NIST recommends using a secret input when hashing memorized secrets such as passwords. By mixing in a secret input (commonly called a "pepper"), one prevents an attacker from brute-forcing the password hashes altogether, even if they have the hash and salt. For example, an SQL injection typically affects only the database, not files on disk, so a pepper stored in a config file would still be out of reach for the attacker. A pepper must be randomly generated once and can be the same for all users. Many password leaks could have been made completely useless if site owners had done this.

Since there is no pepper parameter for password_hash (even though Argon2 has a "secret" parameter, PHP does not allow to set it), the correct way to mix in a pepper is to use hash_hmac(). The "add note" rules of php.net say I can't link external sites, so I can't back any of this up with a link to NIST, Wikipedia, posts from the security stackexchange site that explain the reasoning, or anything... You'll have to verify this manually. The code:

// config.conf
pepper=c1isvFdxMDdmjOlvxpecFw

<?php
// register.php
$pepper = getConfigVariable("pepper");
$pwd = $_POST['password'];
$pwd_peppered = hash_hmac("sha256", $pwd, $pepper);
$pwd_hashed = password_hash($pwd_peppered, PASSWORD_ARGON2ID);
add_user_to_database($username, $pwd_hashed);
?>

<?php
// login.php
$pepper = getConfigVariable("pepper");
$pwd = $_POST['password'];
$pwd_peppered = hash_hmac("sha256", $pwd, $pepper);
$pwd_hashed = get_pwd_from_db($username);
if (
password_verify($pwd_peppered, $pwd_hashed)) {
echo
"Password matches.";
}
else {
echo
"Password incorrect.";
}
?>

Note that this code contains a timing attack that leaks whether the username exists. But my note was over the length limit so I had to cut this paragraph out.

Also note that the pepper is useless if leaked or if it can be cracked. Consider how it might be exposed, for example different methods of passing it to a docker container. Against cracking, use a long randomly generated value (like in the example above), and change the pepper when you do a new install with a clean user database. Changing the pepper for an existing database is the same as changing other hashing parameters: you can either wrap the old value in a new one and layer the hashing (more complex), you compute the new password hash whenever someone logs in (leaving old users at risk, so this might be okay depending on what the reason is that you're upgrading).

Why does this work? Because an attacker does the following after stealing the database:

password_verify("a", $stolen_hash)
password_verify("b", $stolen_hash)
...
password_verify("z", $stolen_hash)
password_verify("aa", $stolen_hash)
etc.

(More realistically, they use a cracking dictionary, but in principle, the way to crack a password hash is by guessing. That's why we use special algorithms: they are slower, so each verify() operation will be slower, so they can try much fewer passwords per hour of cracking.)

Now what if you used that pepper? Now they need to do this:

password_verify(hmac_sha256("a", $secret), $stolen_hash)

Without that $secret (the pepper), they can't do this computation. They would have to do:

password_verify(hmac_sha256("a", "a"), $stolen_hash)
password_verify(hmac_sha256("a", "b"), $stolen_hash)
...
etc., until they found the correct pepper.

If your pepper contains 128 bits of entropy, and so long as hmac-sha256 remains secure (even MD5 is technically secure for use in hmac: only its collision resistance is broken, but of course nobody would use MD5 because more and more flaws are found), this would take more energy than the sun outputs. In other words, it's currently impossible to crack a pepper that strong, even given a known password and salt.
up
162
martinstoeckli
11 years ago
There is a compatibility pack available for PHP versions 5.3.7 and later, so you don't have to wait on version 5.5 for using this function. It comes in form of a single php file:
https://github.com/ircmaxell/password_compat
up
4
bhare at duck dot com
6 months ago
If you are you going to use bcrypt then you should pepper the passwords with random large string, as commodity hardware can break bcrypt 8 character passwords within an hour; https://www.tomshardware.com/news/eight-rtx-4090s-can-break-passwords-in-under-an-hour
up
42
nicoSWD
10 years ago
I agree with martinstoeckli,

don't create your own salts unless you really know what you're doing.

By default, it'll use /dev/urandom to create the salt, which is based on noise from device drivers.

And on Windows, it uses CryptGenRandom().

Both have been around for many years, and are considered secure for cryptography (the former probably more than the latter, though).

Don't try to outsmart these defaults by creating something less secure. Anything that is based on rand(), mt_rand(), uniqid(), or variations of these is *not* good.
up
25
Lyo Mi
8 years ago
Please note that password_hash will ***truncate*** the password at the first NULL-byte.

http://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html

If you use anything as an input that can generate NULL bytes (sha1 with raw as true, or if NULL bytes can naturally end up in people's passwords), you may make your application much less secure than what you might be expecting.

The password
$a = "\01234567";
is zero bytes long (an empty password) for bcrypt.

The workaround, of course, is to make sure you don't ever pass NULL-bytes to password_hash.
up
19
martinstoeckli
11 years ago
In most cases it is best to omit the salt parameter. Without this parameter, the function will generate a cryptographically safe salt, from the random source of the operating system.
up
23
Cloxy
10 years ago
You can produce the same hash in php 5.3.7+ with crypt() function:

<?php

$salt
= mcrypt_create_iv(22, MCRYPT_DEV_URANDOM);
$salt = base64_encode($salt);
$salt = str_replace('+', '.', $salt);
$hash = crypt('rasmuslerdorf', '$2y$10$'.$salt.'$');

echo
$hash;

?>
up
9
Mike Robinson
9 years ago
For passwords, you generally want the hash calculation time to be between 250 and 500 ms (maybe more for administrator accounts). Since calculation time is dependent on the capabilities of the server, using the same cost parameter on two different servers may result in vastly different execution times. Here's a quick little function that will help you determine what cost parameter you should be using for your server to make sure you are within this range (note, I am providing a salt to eliminate any latency caused by creating a pseudorandom salt, but this should not be done when hashing passwords):

<?php
/**
* @Param int $min_ms Minimum amount of time in milliseconds that it should take
* to calculate the hashes
*/
function getOptimalBcryptCostParameter($min_ms = 250) {
for (
$i = 4; $i < 31; $i++) {
$options = [ 'cost' => $i, 'salt' => 'usesomesillystringforsalt' ];
$time_start = microtime(true);
password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
$time_end = microtime(true);
if ((
$time_end - $time_start) * 1000 > $min_ms) {
return
$i;
}
}
}
echo
getOptimalBcryptCostParameter(); // prints 12 in my case
?>
up
2
ms1 at rdrecs dot com
4 years ago
Timing attacks simply put, are attacks that can calculate what characters of the password are due to speed of the execution.

More at...
https://paragonie.com/blog/2015/11/preventing-timing-attacks-on-string-comparison-with-double-hmac-strategy

I have added code to phpnetcomment201908 at lucb1e dot com's suggestion to make this possible "timing attack" more difficult using the code phpnetcomment201908 at lucb1e dot com posted.

$pph_strt = microtime(true);

//...
/*The code he posted for login.php*/
//...

$end = (microtime(true) - $pph_strt);

$wait = bcmul((1 - $end), 1000000); // usleep(250000) 1/4 of a second

usleep ( $wait );

echo "<br>Execution time:".(microtime(true) - $pph_strt)."; ";

Note I suggest changing the wait time to suit your needs but make sure that it is more than than the highest execution time the script takes on your server.

Also, this is my workaround to obfuscate the execution time to nullify timing attacks. You can find an in-depth discussion and more from people far more equipped than I for cryptography at the link I posted. I do not believe this was there but there are others. It is where I found out what timing attacks were as I am new to this but would like solid security.
up
-8
Anonymous
4 years ago
According to the draft specification, Argon2di is the recommended mode of operation:

> 9.4. Recommendations
>
> The Argon2id variant with t=1 and maximum available memory is
> recommended as a default setting for all environments. This setting
> is secure against side-channel attacks and maximizes adversarial
> costs on dedicated bruteforce hardware.

source: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-06#section-9.4
To Top