PHP 8.5.0 Alpha 1 available for testing

password_hash

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

password_hashCrea una clave de hash para una contraseña

Descripción

password_hash(#[\SensitiveParameter] string $password, string|int|null $algo, array $options = []): string

La función password_hash() crea un nuevo hash utilizando un algoritmo de hash fuerte e irreversible.

Los siguientes algoritmos son actualmente soportados:

  • PASSWORD_DEFAULT - Uso del algoritmo bcrypt (por omisión desde PHP 5.5.0). Tenga en cuenta que esta constante está diseñada para cambiar con el tiempo, a medida que se añaden algoritmos más recientes y fuertes a PHP. Por esta razón, la longitud del resultado de este algoritmo puede cambiar con el tiempo, por lo que se recomienda almacenar el resultado en una columna de la base de datos que pueda contener al menos 60 caracteres (255 bytes puede ser una muy buena opción).
  • PASSWORD_BCRYPT - Uso del algoritmo bcrypt para crear la clave de hash. Esto creará una clave de hash estándar crypt() utilizando el identificador $2y$.
  • PASSWORD_ARGON2I - Utiliza el algoritmo de hash Argon2i para crear el hash. Este algoritmo solo está disponible si PHP ha sido compilado con el soporte de Argon2
  • PASSWORD_ARGON2ID - Utiliza el algoritmo de hash Argon2id para crear el hash. Este algoritmo solo está disponible si PHP ha sido compilado con el soporte de Argon2

Opciones soportadas para PASSWORD_BCRYPT:

  • salt - para proporcionar manualmente un salt a utilizar durante el hash de la contraseña. Tenga en cuenta que esta opción evitará la generación automática.

    Si se omite, un salt aleatorio será generado por la función password_hash() para cada contraseña hash. Este es el modo de funcionamiento previsto.

    Advertencia

    La opción Salt está obsoleta. Es preferible utilizar simplemente el salt que se genera por omisión. A partir de PHP 8.0.0, un salt proporcionado explícitamente es ignorado.

  • cost - determina el costo algorítmico que debe ser utilizado. Ejemplos de estos valores pueden ser encontrados en la página de documentación de la función crypt().

    Si se omite, el valor por omisión 12 será utilizado. Este es un buen compromiso, pero debe ser ajustado según el hardware utilizado.

Opciones soportadas para PASSWORD_ARGON2I y PASSWORD_ARGON2ID:

Parámetros

password

La contraseña del usuario.

Precaución

El uso de la constante PASSWORD_BCRYPT para el algoritmo hará que el parámetro password sea truncado a una longitud máxima de 72 bytes.

algo

A constante del algoritmo de contraseñas indicando qué algoritmo utilizar para crear el hash de la contraseña.

options

Un array asociativo de opciones. Véanse las constantes de algoritmos de contraseñas para la documentación sobre las opociones admitidas de cada algoritmo.

Valores devueltos

Retorna la contraseña hash.

El algoritmo utilizado, el costo y el salt están contenidos en el hash retornado. También, toda la información útil para verificar este último está incluida. Esto permite que la función password_verify() verifique el hash sin necesidad de almacenar por separado esta información.

Historial de cambios

Versión Descripción
8.4.0 El valor por omisión de la opción cost del algoritmo PASSWORD_BCRYPT ha sido aumentado de 10 a 12.
8.3.0 password_hash() ahora asocia la excepción Random\RandomException subyacente a Exception::$previous cuando una ValueError es lanzada debido a un fallo en la generación del salt.
8.0.0 password_hash() ya no retorna false en caso de fallo, una ValueError será lanzada si el algoritmo de hash de contraseña no es válido, o una Error si el hash de contraseña falló por una razón desconocida.
8.0.0 algo ahora es nullable.
7.4.0 El parámetro algo ahora espera una chaîne de caractères, pero sigue aceptando un entier para mantener la compatibilidad hacia atrás.
7.4.0 La extensión sodium proporciona una implementación alternativa para las contraseñas Argon2.
7.3.0 Añadido el soporte para contraseñas Argon2id utilizando PASSWORD_ARGON2ID.
7.2.0 Añadido el soporte para contraseñas Argon2i utilizando PASSWORD_ARGON2I.

Ejemplos

Ejemplo #1 Ejemplo con password_hash()

<?php
echo password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
?>

El resultado del ejemplo sería algo similar a:

$2y$12$4Umg0rCJwMswRw/l.SwHvuQV01coP0eWmGzd61QH2RvAOMANUBGC.

Ejemplo #2 Ejemplo con password_hash() definiendo manualmente la opción cost

<?php
$options
= [
// Aumenta el costo de bcrypt de 12 a 13.
'cost' => 13,
];
echo
password_hash("rasmuslerdorf", PASSWORD_BCRYPT, $options);
?>

El resultado del ejemplo sería algo similar a:

$2y$13$xeDfQumlmdm0Sco.4qmH1OGfUUmOcuRmfae0dPJhjX1Bq0yYhqbNi

Ejemplo #3 Ejemplo con password_hash() para encontrar un buen costo (cost)

Este código realizará un benchmark de la máquina para determinar el costo máximo que puede ser utilizado sin degradar la experiencia del usuario. Se recomienda elegir el costo más alto posible sin ralentizar otras operaciones que la máquina debe ejecutar. 11 es una buena base, y un valor más alto es preferible si la máquina es suficientemente rápida. El código de abajo apunta a un tiempo de estiramiento ≤ 350 milisegundos, lo cual representa un retraso adecuado para sistemas que manejan conexiones interactivas.

<?php
$timeTarget
= 0.350; // 350 milisegundos

$cost = 11;
do {
$cost++;
$start = microtime(true);
password_hash("test", PASSWORD_BCRYPT, ["cost" => $cost]);
$end = microtime(true);
} while ((
$end - $start) < $timeTarget);

echo
"Valor de 'cost' más apropiado: " . $cost - 1;
?>

El resultado del ejemplo sería algo similar a:

Valor de 'cost' más apropiado: 13

Ejemplo #4 Ejemplo con password_hash() y Argon2i

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

El resultado del ejemplo sería algo similar a:

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

Notas

Precaución

Se recomienda encarecidamente no proporcionar un salt explícito para esta función. Un salt seguro será generado automáticamente si no se especifica ningún salt.

Como se mencionó anteriormente, el uso de la opción salt a partir de PHP 7.0.0 generará una advertencia de deprecación. El soporte para un salt explícito fue eliminado a partir de PHP 8.0.0.

Nota:

Se recomienda probar esta función en la máquina utilizada y ajustar el/los parámetro(s) de costo para que la ejecución de la función tome menos de 350 milisegundos para conexiones interactivas. El script del ejemplo anterior ayudará a elegir un costo bcrypt adecuado para la máquina dada.

Nota: La actualización de los algoritmos soportados por esta función (o el cambio al por omisión) debe seguir las siguientes reglas:

  • Cada nuevo algoritmo debe formar parte del núcleo de PHP durante al menos 1 versión completa antes de aspirar a convertirse en el algoritmo por omisión. También, si, por ejemplo, un nuevo algoritmo es añadido en la versión 7.5.5, no será elegible como algoritmo por omisión hasta PHP 7.7 (sabiendo que 7.6 será la primera versión completa). Pero si un algoritmo diferente ha sido añadido en 7.6.0, también será elegible como algoritmo por omisión a partir de la versión 7.7.0.
  • El algoritmo por omisión solo puede ser cambiado durante una versión completa (7.3.0, 8.0.0, etc...) y no durante una versión de revisión. La única excepción a este principio básico sería una emergencia, por ejemplo, al descubrir un bug crítico de seguridad en el algoritmo por omisión.

Ver también

add a note

User Contributed Notes 8 notes

up
155
phpnetcomment201908 at lucb1e dot com
5 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
6
fullstadev at gmail dot com
1 year ago
Similar to another post made here about the use of strings holding null-bytes within password_hash(), I wanted to be a little more precise, as we've had quite some issues now.

I've had a project of an application generating random hashes (CSPRN). What they've done is that they've used random_bytes(32), and the applied password_hash() to that obtained string, with the bcrypt algorithm.

This on one side led to the fact that sometimes, random_bytes() generated a string with null-bytes, actually resulting to an error in their call to password_hash() (PHP v 8.2.18). Thanks to that ("Bcrypt password must not contain a null character") I modified the the function generating random hashes to encoding the obtained binary random string with random_bytes() using bin2hex() (or base64 or whatever), to assure that the string to be hashed has no null-bytes.

I then just wanted to add that, when you use the bcrypt algorithm, make sure to remember that bcrypt truncates your password at 72 characters. When encoding your random string (e.g. generated using random_bytes()), this will convert your string from binary to hex representation, e.g. doubling its length. What you generally want is that your entire password is still contained within the 72 characters limit, to be sure that your entire "random information" gets hashes, and not only part of it.
up
46
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.
up
7
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
up
33
Lyo Mi
9 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
18
martinstoeckli
12 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
6
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.
up
13
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
?>
To Top