admin_password

[olaf7]

Debian Bullseye running Nginx, FPM-PHP7.4 and Rainloop all from packages from the Debian repository. Rainloop: 1.12.1-2 Requiremen add to virtual server: fastcgi_param PHP_VALUE open_basedir="/usr/share/rainloop/:/var/lib/rainloop/:/etc/rainloop/";

Admin password issue: /etc/rainloop/application.ini

stanza: [security] setting: admin_password

it is useless. Why? See below.

even when: allow_admin_panel = On (Default in Debian: Off, see Readme in /usr.share/doc/rainloop)

https://github.com/RainLoop/rainloop-webmail/blob/master/rainloop/v/0.0.0/app/libraries/RainLoop/Config/Application.php

function SetPassword

• It uses, if it can, PASSWORD_DEFAULT which is coming from: https://www.php.net/manual/en/function.password-hash.php Potential problem: as specified the default can change over time Currently equal to: PASSWORD_BCRYPT - Use the CRYPT_BLOWFISH algorithm to create the hash. This will produce a standard crypt() compatible hash using the "$2y$" identifier. The result will always be a 60 character string, or false on failure.
• It sets a password hashed with md5 which is old and weak. And is even deprecated by Rainloop. But not here to remain compatibility. Maybe deprecate sub PHP 5.5 support just because of this?

Note: there is no check on false after calling password-hash

function ValidatePassword

• password is checked using three methods:
  1. default as defined in code, NOT read from INI-file. This is problematic.
  2. legacy MD5 depending of hash length to maintain compatibility with PHP < 5.5.0
  3. password_verify function --> available since PHP 5.5.0 : https://www.php.net/manual/en/function.password-verify.php also see password-hash function as documented above.

function defaultValues

• hard coded admin password, which is useless as it is never used/read from this file

How does this work in practice? When the user changes the admin password in the INI file, say from '12345' to 'admin12345', (s)he is safer and following instruction not to bind Rainloop to the internet using the default password. Not: that new password is still weak, but at least not the default. Result: error -102 auth error Looking this up in documentation: not found. What probably goes on under the hood: The new set admin password is compared to the default '12345' password which is in code (line 121). This is obviously not a match resulting in an auth error.

Worth testing? in terminal: php -r 'echo password_hash("admin12345", PASSWORD_DEFAULT).PHP_EOL;' This will give a hash of the supplied password. Use that in the INI-file. Will probably fail due to method 1 in function ValidatePassword.

Desired solution:

Read the INI file setting and use (the hash of) the admin_password as defined there instead of '12345' in function ValidatePassword

[the-djmaze]

When the user changes the admin password in the INI file, say from '12345' to 'admin12345',

You do not that do that. You save it like admin_password = "$2y$10$Base64EncodedHashCreatedByBcryptOrArgon2"

That works fine