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.
password_hash
(PHP 5 >= 5.5.0, PHP 7, PHP 8)
password_hash — Crée une clé de hachage pour un mot de passe
Description
La fonction password_hash() crée un nouveau hachage en utilisant un algorithme de hachage fort et irréversible.
Les algorithmes suivants sont actuellement supportés :
-
PASSWORD_DEFAULT- Utilisation de l'algorithme bcrypt (par défaut depuis PHP 5.5.0). Notez que cette constante est concue pour changer dans le temps, au fur et à mesure que des algorithmes plus récents et plus forts sont ajoutés à PHP. Pour cette raison, la longueur du résultat issu de cet algorithme peut changer dans le temps, il est donc recommandé de stocker le résultat dans une colonne de la base de données qui peut contenir au moins 60 caractères (255 caractères peut être un très bon choix). -
PASSWORD_BCRYPT- Utilisation de l'algorithmeCRYPT_BLOWFISHpour créer la clé de hachage. Ceci va créer une clé de hachage standard crypt() utilisant l'identifiant "$2y$". Le résultat sera toujours une chaîne de 60 caractères, oufalsesi une erreur survient. -
PASSWORD_ARGON2I- Utilise l'algorithme de hachage Argon2i pour créer le hachage. Cet algorithme est seulement disponible si PHP a été compilé avec le support d'Argon2 -
PASSWORD_ARGON2ID- Utilise l'algorithme de hachage Argon2id pour créer le hachage. Cet algorithme est seulement disponible si PHP a été compilé avec le support d'Argon2
Options supportées pour PASSWORD_BCRYPT:
-
salt- pour fournir manuellement un salt à utiliser lors du hachage du mot de passe. Notez que cette option empêchera la génération automatique.Si omis, un salt aléatoire sera généré par la fonction password_hash() pour chaque mot de passe haché. C'est le mode de fonctionnement prévu.
AvertissementL'option Salt est obsolète. Il est préférable d'utiliser simplement le sel qui est généré par défaut. À partir de PHP 8.0.0, un sel explicitement fournit est ignoré.
-
cost- détermine le coût algorithmique qui doit être utilisé. Des exemples de ces valeurs peuvent être trouvés sur la page de la documentation de la fonction crypt().Si omis, la valeur par défaut
10sera utilisée. C'est un bon compromis, mais vous pourriez vouloir l'augmenter suivant votre architecture.
Options supporté pour PASSWORD_ARGON2I et PASSWORD_ARGON2ID :
-
memory_cost(int) - Mémoire maximale (en kilo octets binaire) pouvant être utilisée pour calculer le hachage Argon2. Par défaut àPASSWORD_ARGON2_DEFAULT_MEMORY_COST. -
time_cost(int) - Durée maximale de temps qu'il peut prendre pour calculer le hachage Argon2. Par défaut àPASSWORD_ARGON2_DEFAULT_TIME_COST. -
threads(int) - Nombre de threads à utiliser pour calculer le hachage Argon2. Par défaut àPASSWORD_ARGON2_DEFAULT_THREADS.AvertissementUniquement disponible quand PHP utilise libargon2, et non l'implementation libsodium.
Liste de paramètres
-
password -
Le mot de passe utilisateur.
AttentionL'utilisation de la constante
PASSWORD_BCRYPTpour l'algorithme fera que le paramètrepasswordsera tronqué à une longueur maximale de 72 octets. -
algo -
Une constantes de l'algorithme de mot de passe représentant l'algorithme à utiliser lors du hachage du mot de passe.
-
options -
Un tableau associatif contenant les options. Voir aussi les constantes de l'algorithme de mot de passe pour une documentation sur les options supportées pour chaque algorithme.
Si omis, un salt aléatoire sera créé et le cost par défaut sera utilisé.
Valeurs de retour
Retourne le mot de passe haché.
L'algorithme utilisé, le coût et le salt sont contenus dans le hachage retourné. Aussi, toutes les informations utiles pour vérifier ce dernier y sont incluses. Ceci permet à la fonction password_verify() de vérifier le hachage sans avoir besoin de stocker séparément ces informations.
Historique
| Version | Description |
|---|---|
| 8.0.0 |
password_hash() ne retourne plus false en cas d'échec, une
ValueError sera levée si l'algorithme de hachage
de mot de passe n'est pas valide, ou une Error si le hachage
de mot de passe a échoué pour une raison inconnue.
|
| 8.0.0 |
algo est désormais nullable.
|
| 7.4.0 |
Le paramètre algo attend désormais une chaîne de caractères, mais
continue d'accepter un entier afin de conserver une compatibilité antérieure.
|
| 7.4.0 | L'extension sodium fournit un implémentation alternative pour les mots de passes Argon2. |
| 7.3.0 |
Ajout de la prise en charge des mots de passe Argon2id à l'aide de PASSWORD_ARGON2ID.
|
| 7.2.0 |
Ajout de la prise en charge des mots de passe Argon2i à l'aide de PASSWORD_ARGON2I.
|
Exemples
Exemple #1 Exemple avec password_hash()
<?php
/**
* Nous voulons juste hacher notre mot de passe en utiliant l'algorithme par défaut.
* Actuellement, il s'agit de BCRYPT, ce qui produira un résultat sous forme de chaîne de
* caractères d'une longueur de 60 caractères.
*
* Gardez à l'esprit que DEFAULT peut changer dans le temps, aussi, vous devriez vous
* y préparer en autorisant un stockage supérieur à 60 caractères (255 peut être un bon choix)
*/
echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
?>Résultat de l'exemple ci-dessus est similaire à :
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
Exemple #2 Exemple avec password_hash() en définissant manuellement l'option cost
<?php
/**
* Dans ce cas, nous souhaitons augmenter le "cost" par défaut pour BCRYPT à la valeur 12.
* Notez que nous passons également à l'algorithme BCRYPT, qui produit toujours un résultat
* de 60 caractères.
*/
$options = [
'cost' => 12,
];
echo password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
?>Résultat de l'exemple ci-dessus est similaire à :
$2y$12$QjSH496pcT5CEbzjD/vtVeH03tfHKFy36d4J0Ltp3lRtee9HDxY3K
Exemple #3 Exemple avec password_hash() trouver un bon coût (cost)
<?php
/**
* Ce code va tester votre serveur pour déterminer quel serait le meilleur "cost".
* Vous souhaitez définir le "cost" le plus élevé possible sans trop ralentir votre serveur.
* 10 est une bonne base, mais une valeur plus élevée est aussi un bon choix à partir
* du moment où votre serveur est suffisament rapide ! Le code suivant espère un temps
* ≤ à 350 millisecondes, ce qui est un délai approprié pour les systèmes gérants les identifications
* intéractivement.
*/
$timeTarget = 0.350; // 350 millisecondes
$cost = 10;
do {
$cost++;
$start = microtime(true);
password_hash("test", PASSWORD_BCRYPT, ["cost" => $cost]);
$end = microtime(true);
} while (($end - $start) < $timeTarget);
echo "Valeur de 'cost' la plus appropriée : " . $cost;
?>Résultat de l'exemple ci-dessus est similaire à :
Valeur de 'cost' la plus appropriée : 12
Exemple #4 Exemple avec password_hash() et Argon2i
<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>Résultat de l'exemple ci-dessus est similaire à :
Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0
Notes
Attention
Il est vivement recommandé de ne pas générer vous-même votre propre salt pour cette fonction. La fonction va générer un salt sécurisé automatiquement pour vous si vous n'en spécifiez pas un !
Comme indiqué ci-dessus, fournir l'option Salt en PHP 7.0
générera un avertissement de désapprobation. La prise en charge d'un sel
fourni manuellement a été supprimée en PHP 8.0.
Note:
Il est recommandé de tester cette fonction sur vos serveurs, et d'ajuster le paramètre "cost" afin que l'exécution de cette fonction prenne moins de 350 millisecondes. Le script dans l'exemple ci-dessus vous aide à choisir une bonne valeur suivant votre architecture matérielle.
Note: La mise à jour des algorithmes supportés par cette fonction (ou le changement à celui par défaut) doit suivre les règles suivantes :
- Chaque nouvel algorithme doit faire parti du cœur de PHP pendant au moins 1 version complète avant de prétendre à devenir l'algorithme par défaut. Aussi, si, par exemple, un nouvel algorithme est ajouté en version 7.5.5, il ne sera éligible comme algorithme par défaut qu'à partir de PHP 7.7 (sachant que 7.6 sera la première version complète). Mais si un algorithme différent a été ajouté en 7.6.0, il sera aussi éligible comme algorithme par défaut à partir de la version 7.7.0.
- L'algorithme par défaut ne peut être changé que lors d'une version complète (7.3.0, 8.0.0, etc...) et non pendant une version de révision. La seule exception à ce principe de base serait une urgence, par exemple, lors de la découverte d'un bogue critique au niveau de la sécurité dans l'algorithme par défaut.
Voir aussi
- password_verify() - Vérifie qu'un mot de passe correspond à un hachage
- password_needs_rehash() - Vérifie que le hachage fourni est conforme à l'algorithme et aux options spécifiées
- crypt() - Hachage à sens unique (indéchiffrable)
- sodium_crypto_pwhash_str() - Get an ASCII-encoded hash
add a note
User Contributed Notes 10 notes
phpnetcomment201908 at lucb1e dot com ¶
5 years ago
martinstoeckli ¶
12 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
bhare at duck dot com ¶
1 year 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
nicoSWD ¶
11 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.
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.
Cloxy ¶
11 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;
?>
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.
Mike Robinson ¶
10 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
?>
ms1 at rdrecs dot com ¶
5 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.
Anonymous ¶
5 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
