Re: [PHP-DEV] password_verify() and unknown algos
On Wed, Jan 27, 2021 at 11:27 AM Benjamin Morel
wrote:
> Hi internals,
>
> I just spent some time debugging an authentication issue after upgrading
> PHP, and realized that it was due to ext-sodium not being installed, so
> password_verify() would always return false for argon2i hashes.
>
> Digging a bit more, I realized that password_verify() does not complain if
> the algorithm is unknown, or if the hash string is malformed:
>
> var_export(password_verify('passw0rd', 'any/string%as|a$hash')); //
> false
>
> Shouldn't it throw an exception, or a least trigger a warning, when the
> algorithm is unknown, or the hash is malformed? Returning false IMO, should
> mean "I recognize this hash, but it doesn't match your password". "I don't
> recognize this hash" is an application issue and should be reported.
>
> What do you think?
>
>
Hey all,
I just wanted to drop in and make a note here. When I designed
password_verify, the lack of validation/errors on invalid hases was 100%
explicit and intentional. The primary reason is to support multiple
validation strategies in order to allow for migration paths between
different storage mechanisms.
Take an example where someone used to use Wordpress's custom phpass based
$P$ system. They now want to migrate to bcrypt/argon/etc. If
password_verify threw errors the validation system would need to introspect
each hash to determine how to validate it (note, this happens in
password_verify and the other validators already). But without errors, it
becomes a simple fallthrough:
function validate($password, $hash) {
if (password_verify($password, $hash)) return true;
if (legacy_verify($password, $hash) || other_legacy_verify($password,
$hash)) {
update_password_hash($password);
return true;
}
return false;
}
There are definitely a fair number of applications that use the above
method to ensure backwards compatibility and a solid upgrade path, and as
such I would be resistant to adding warnings/errors/exceptions here.
The case for "it's an application issue" is definitely valid, though that's
also what password_info was added to provide (it is easy to introspect).
One other point I'd make is to normally suggest not disclosing any
information about cryptographic material via error handling mechanisms
(it's too easy to expose to attackers). This is one of those dev-x/security
tradeoffs. Does not throwing a warning improve security? Not in most cases.
But can throwing a warning make an attackers job easier (or at least point
them in the right direction)? Perhaps.
My $0.02 at least
Anthony
— Benjamin
>
Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode
Den 2021-01-28 kl. 01:31, skrev Kamil Tekiela: I'm missing a thing here when we talk about "your code". I mean on our site we have third party libraries. They can typically have a release schedule on a couple of releases each year. So all code is not up to us to change. So how does this proposal adress that scenario when it's not up to us to do the necessary changes? Is it e.g. a blocker to upgrade to PHP 8.1 with exceptions vs warnings until the library is updated? As a side note I'm at the moment migrating our test site to PHP 8 and the two most prominent hickups are located in a third party library: "Undefined array key" and "Attempt to read property "value" on null" which are warnings. Not sure how it would have been with these as exceptions, e.g. would the test site stop running and thereby stop testing of other parts. And as I have said earlier, I do like exceptions! It's the migration aspect I'm wondering about... r//Björn L This is a valid concern. I have thought about it for a while and I think that we should handle this the same way we did with PDO error mode change. We don't do anything special. I really don't see a way that we could make a smoother upgrading experience. For users that avail of old libraries the onus is on them to check the library's compatibility with the new PHP version. Ideally, the change should have been made in PHP 8.0 where it would be more justifiable to change a default setting. The good thing about mysqli error reporting compared to PDO is that the setting is global. If the library you are using is abandoned or you can't wait for the library to be updated then you can set the error reporting level in your own code. The only problem comes when you want to mix both modes in the same code, but that is a huge code smell anyway. This means that this change is not a blocker for the upgrade. I think the proposal is good to be implemented in PHP 8.1 as it is now. But if anyone thinks otherwise or has any ideas on how to improve I would gladly take it into consideration. If there is any way that we could make the migration smoother then it would be great. Kamil Yes, this proposal would probably have been close to a no-brainer in PHP 8.0. I think the RFC would benefit on expanding on some of the key issues that has been discussed, e.g. the clarification above about migration aspects. /r//Björn L/
[PHP-DEV] Re: "This page is not secure (broken HTTPS)" on https://master.php.net/
Forwarding to the internals mailing list, and also to systems. On 28.01.2021 at 14:03, André L F S Bacci wrote: > On Thu, Jan 21, 2021 at 10:59 PM Christoph M. Becker > wrote: > >> On 21.01.2021 at 17:22, André L F S Bacci wrote: >> >>> Today I was working in documentation when a got this, while accessing >>> https://master.php.net/manage/users.php : >>> >>> This page is not secure (broken HTTPS). >>> Certificate - missing >>> This site is missing a valid, trusted certificate >>> (net::ERR_SSL_OBSOLETE_VERSION). >>> View certificate >>> Resources - all served securely >>> All resources on this page are served securely. >>> >>> Maybe it's time to upgrade here. >> >> Yes, it is, but nobody volunteered for doing it so far. Note that the >> whole OS would need to be upgraded, though. :( >> >> Anyhow, we're on the wrong mailing list. :) >> > > Could you ping the correct list with this discussion? > > This little machine runs some very critical systems in the PHP... universe. > > André > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
