Loris: Fix Phan errors introduced in PHP 7.4

[johnsaigle]

htdocs/postdeploy.php:45 PhanTypeMismatchArgumentInternalProbablyReal Argument 2 ($algo) is null but \password_hash() takes int
modules/configuration/php/configuration.class.inc:142 PhanCompatibleDimAlternativeSyntax Array and string offset access syntax with curly braces is deprecated in PHP 7.4. Use square brackets instead. Seen for $setting{'ID'}
php/installer/Installer.class.inc:554 PhanTypeMismatchArgumentInternalProbablyReal Argument 2 ($algo) is null but \password_hash() takes int
php/libraries/Password.class.inc:207 PhanTypeMismatchArgumentInternalProbablyReal Argument 2 ($algo) is null but \password_hash() takes int
php/libraries/SinglePointLogin.class.inc:314 PhanTypeMismatchArgumentInternalProbablyReal Argument 2 ($algo) is null but \password_needs_rehash() takes int
php/libraries/SinglePointLogin.class.inc:328 PhanTypeMismatchArgumentInternalProbablyReal Argument 2 ($algo) is null but \password_hash() takes int

[driusan]

phan seems to be wrong about the password_hash. In all the cases, the second argument being passed on those lines is the PASSWORD_DEFAULT constant.

[johnsaigle]

Fair enough. We should re-evaluate these bugs after TravisCI updates to PHP 7.4 instead of the snapshot.

Also phan should be updated in case this is a bug on their side. I have a PR doing this here: https://github.com/aces/Loris/pull/5762

Once these two things are updated we can see whether the error still appears and go from there.

[xlecours]

Maybe we should explicitely use PASSWORD_BCRYPT instead of PASSWORD_DEFAULT

It is worth noting that over time this constant can (and likely will) change. Therefore you should be aware that the length of the resulting hash can change. Therefore, if you use PASSWORD_DEFAULT you should store the resulting hash in a way that can store more than 60 characters (255 is the recommended width).

from https://www.php.net/manual/en/password.constants.php

[johnsaigle]

https://github.com/aces/Loris/blob/4155ea37030eecc913701b1aebd81e0798916dbb/SQL/0000-00-00-schema.sql#L95

If we're going to require a specific password algorithm i think we should do more research into possible advantages/disadvantages there are to the different algorithms.

[driusan]

We should keep using PASSWORD_DEFAULT, as the point of the API is that it can upgrade itself over time. It's a bug with phan (or, depending on your point of view, with php changing the type signature of the API with 7.4...) PHP seems to have changed the second argument from an int in 7.3 to a nullable string in 7.4 (which shouldn't make a difference if you're using the constants, as you should be, but is affecting the static analysis..)

I filed phan/phan#3560

[johnsaigle]

Maybe until that's fixed we should add phan suppressions for those lines.

[driusan]

I don't think there's any reason to suppress them, it's already been fixed. We can wait until the fix makes it into a release. (The NEWS.md file in phan suggests they happen often enough that it's not much of a burden.)