Skip to content

Conversation

@browner12
Copy link
Contributor

as of PHP 8.0.0, password_hash() no longer returns false on failure, instead a ValueError will be thrown if the password hashing algorithm is not valid, or an Error if the password hashing failed for an unknown error.

I noticed the ArgonHasher already had a slightly updated check using error suppression, which was added in #33856. however, I couldn't seem to get that to actually work, and for consistency I updated them both to use try/catch.

added tests for all 3 implementations to see if they correctly throw a RuntimeException if they are not able to be created. I used invalid "cost" and "time" options to trigger this. not sure if there's a better way.

https://www.php.net/manual/en/function.password-hash.php#:~:text=the%20salt%20generation.-,8.0.0,-password_hash()%20no

as of PHP 8.0.0, `password_hash()` no longer returns false on failure, instead a `ValueError` will be thrown if the password hashing algorithm is not valid, or an `Error` if the password hashing failed for an unknown error.

I noticed the `ArgonHasher` already had a slightly updated check using error suppression, which was added in laravel#33856.  however, I couldn't seem to get that to actually work, and for consistency I updated them both to use try/catch.

added tests for all 3 implementations to see if they correctly throw a `RuntimeException` if they are not able to be created.  I used invalid "cost" and "time" options to trigger this. not sure if there's a better way.

https://www.php.net/manual/en/function.password-hash.php#:~:text=the%20salt%20generation.-,8.0.0,-password_hash()%20no
'time_cost' => $this->time($options),
'threads' => $this->threads($options),
]);
} catch (Error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might it be helpful to add this caught Error as the previous parameter of the RuntimeException?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yah, I was considering that. is there any security implication though, because it could expose info like which algo is being used?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it already showing the hashing algo in the exception message?

In theory, these exceptions should not be passed along to the end-user when the app is set to production mode.

(I don't have a strong opinion on it either way, just a thought as I have fallen into the practice of forwarding exceptions when throwing a new one)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also catches a generic Error object, which could be caused by any number of things. At least this way you can see what specifically happened.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it could also expose other info, like cost factor, etc.

you're right, it should never show to users in production.

I'd say give a PR a shot, and see what other people think.

@taylorotwell taylorotwell merged commit 977e418 into laravel:11.x Dec 10, 2024
38 checks passed
@browner12 browner12 deleted the AB-bcrypt-hashing branch December 10, 2024 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants