Curious about how Hash works

Does the PASSWORD_BCRYPT work the same across different Laravel Projects?

Yes. Bcrypt is actually built-in in PHP, so it will be the same across different Laravel Projects

Is the APP_KEY used to encrypt the password ?

No. Passwords are hashed not encrypted.

When you hash a value, you cannot get the original value back from the hash.

When you encrypt a value, if you have the encryption key you can get the original value back.

Also imagine you need to change your APP_KEY for any reason (employee moves to competitor, .env is leaked, etc.). Every user's password would be invalidated if they are dependent on the APP_KEY.

One last thing: Passwords using Bcrypt in Laravel are salted. It is true Laravel doesn't handle the salt or allow you to define a custom salt, but what happens is that PHP itself will generate a random salt for you.

Reference: https://www.php.net/manual/en/function.password-hash.php

Supported options for PASSWORD_BCRYPT:

• salt (string) - to manually provide a salt to use when hashing the password. Note that this will override and prevent a salt from being automatically generated.

If omitted, a random salt will be generated by password_hash() for each password hashed. This is the intended mode of operation.

When you see a password hash in the database, for example, using the password string shipped in ./database/factories/UserFactory.php

$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
| A| B|          C          |               D              |

• Part A ($2y$) identifies the hashing algorithm (in this case Bcrypt)
• Part B (10$) identifies the hashing algorithm options, in this case it states this password was hashed using 10 rounds (cost)
• Part C (92IXUNpkjO0rOQ5byMi.Ye / 22 characters) is the salt. As Laravel doesn't allow you to provide a custom one, a random one is generated
• Part D (4oKoEa3Ro9llC/.og/at2.uheWG/igi) Is the actual password hash.

When comparing a password, internally Laravel uses PHP's password_verify() which takes a plain string and a password hash to verify if they match.

The way it works is that from the full hash PHP is able to find out the algorithm, options and salt used in the hash. Then it applies the same algorithm, options and salt to the plain string and compare both outputs.

Hope it helps.

EDIT Was curious to see if the . as limiter between the salt and password hash. After not identifying a pattern when verifying some patterns in my local project database, I decided to Google it, and found the the salt, for bcrypt, are the first 22 characters after the algorithm options.

Reference: https://stackoverflow.com/a/40995551

@lukegalea16

Are you just curious about hashing or is there a bigger question to all these?

1. Salting is meant to prevent patterns being discovered in the hashes.
2. Salting is not applicable before sending for authentication.
3. And NO, you don't want to be hashing before sending, this is literally breaking the protection provided by the hash. Once a hacker gets your hashes, they can login directly your system.

Please state your bigger question or read up on hash and salt so that we can have a more productive conversation about the idea you have in mind.

And if I may add, these concepts are developed by rigorous mathematicians over the decades. It is very unlikely for non-researchers to find better ideas.