Repository navigation
[Bug]: passwordsalt migration missing #34780
Description
Activity
It happened to me too after upgrading to Nextcloud 25
Reacted by FrabjousSame here after upgrading from v24.0.6 to v25.0.0
My original installation is very old and based on OC3. Did every update (major or minor) since then.
Just checked my backups and there has been no passwordsalt variable set in config.php at all.I just added the value to the config.php by using
php /var/www/nextcloud/occ config:system:set passwordsalt --type=string --value=''But still no change.
try:
php /var/www/nextcloud/occ config:system:set passwordsalt --type=string --value='ReplaceThisTest'the passwordsalt needs to be not empty
@CarlSchwan Ok, but setting a salt on an existing installation with users will not prevent users to login?
Minutes ago I tried https://help.nextcloud.com/t/passwordsalt-missing-from-config-php/148081/2 and for sure this works as a workaround.
Oddly the patch doesn't work on my instance...
edit : it works. Cache problem.
But I can't confirm actions like updating apps, the button is greyed out (maybe a browser problem)
What patch did you apply?
- Set a non empty passwordsalt
- Remove config check for passwordsalt
I removed config check for passwordsalt as described here :
https://help.nextcloud.com/t/passwordsalt-missing-from-config-php/148081/2
(not a bug in my browser as I thought)
edit : it's a display bug, pressing enter works ! #34828
As far as I understand hashes, changing the salt would invalidate them.
Therefore, to migrate to a new salt all hashes must be updated and because this would require the actually passwords this has to be triggered by the user.A procedure like this might work, but I know very little about the inner workings of nextcloud:
- Admin forces a password hash update on login
- User uses the old/empty salt for the next login
- The entered password value is used to generate a new hash using the new salt
- To allow this to work for more than one user the migration has to be tracked for all users
However, I don't know how to trigger such a password change.
Furthermore, it could be that the hashes are also used for other things that are not user passwords, making migration more complicated.
Sorry but I'm still confused what the outcome of all this is,
As far as I know I've never had passwordsalt in my config file and my Nextcloud installation is as old as the first Nextcloud version releases in 2015-2016?
It would be great that someone could point out what needs to be done.. for the moment I just removed the passwordsalt from:
foreach (['secret', 'instanceid', 'passwordsalt'] as $requiredConfig) { if ($config->getValue($requiredConfig, '') === '' && !\OC::$CLI && $config->getValue('installed', false)) { $errors[] = [But messing with the code it's not obviously a solution.
Thanks,
My understanding so far:
Old installations does not have a passwordsalt in their config.
New ones have one.NC v25.0.0 is checking for it and here the trouble started for old installations.
Workaround is to modify code.My question already added to a previous post is "Will setting a salt on an existing installation with users prevent these users to login?"
If so it needs a solution.Reacted by Glandos17 remaining items
@modzilla99 thank you! It has clearly been to long ago since I have installed Nextcloud, I totally forgot about that. It has just been working to well. Now it is working again for me 🙏
@jejanim I did with these steps. Not sure if the first is needed but did it non the less.
- build a new container based on upstream
FROM nextcloud:25.0.1-apache RUN sed -i "s/'secret',//g" /usr/src/nextcloud/lib/private/legacy/OC_Util.php- Since I have persisted the data (https://github.com/nextcloud/docker#persistent-data) I needed to fix
/var/www/html/lib/private/legacy/OC_Util.phpfrom within the container, the same way with sed or editor if you prefer that. You can also do it on the host system where the location will be different.
Reacted by jejanimOriginally posted by @wolegis in #34780 (comment)
This worked perfectly for me thanks!
upgrading 24 -> 25 has been the first rough update for years. Somewhat sad that this issue here is four weeks old, and it is still present in NC25.0.1.
In my case: i set a new, random passwordsalt to my existing config, and all old logins continued to work just fine. I just wish this was either automated or there was a warning somewhere along the way.
Reacted by Joachim Astelah, interesting, so this is from old versions or coming from ownCloud.
I have an instance currently on NC 24 that was migrated two years ago from OC 10 and earlier, and indeed I don't have a password salt either.
Reacted by rakekniven and Christoph WurstI gave it a try. Generated a password salt with
base64 </dev/urandom | head -c 30
and inserted that into
/etc/webapps/nextcloud/config/config.php. To my surprise login was still possible. Changing passwords also worked.After that I upgraded to 25.0.1(from 24.0.6). Still logging in and changing passwords is possible.
Meanwhile I'm pretty sure that
passwordsaltis not taken into account at the moment - at least not for the Argon2ID password hashes in tableoc_users. I would strongly appreciate that the Nextcloud developers enlighten the community about:* Why the config parameter `passwordsalt` became mandatory?Because this increase the security as it allows new password to use it. Also this caused some application (e.g end to end encryption) to fail when
secretwas not set* Where and under which circumstances the parameter is actually used?When hashing a password and in general using the
Security\Hasherservice. When comparing the hash with a previous stored hash we compare with both am empty passwordsalt and an the passwordsalt set in the config.php* Whether there are any plans to use `passwordsalt` for the hashes in table `oc_users`?It is used already but only when setting new passwords. We don't rehash old passwords
Reacted by Claudius Coenen, Christoph Wurst and Côme ChillietReacted by Claudius Coenen@CarlSchwan if
passwordsaltis actually used (again) it might also be a good idea to remove the deprecation notice in the sample config file, as this was very confusing to me at first while looking at the docs.The config entry has been officially deprecated in 2014 with 726626b
Many thanks for taking care of this issue and answering my questions.
- Why the config parameter
passwordsaltbecame mandatory?
Because this increase the security as it allows new password to use it. Also this caused some application (e.g end to end encryption) to fail when
secretwas not set- Where and under which circumstances the parameter is actually used?
When hashing a password and in general using the
Security\Hasherservice. When comparing the hash with a previous stored hash we compare with both am empty passwordsalt and an the passwordsalt set in the config.php- Whether there are any plans to use
passwordsaltfor the hashes in tableoc_users?
It is used already but only when setting new passwords. We don't rehash old passwords
I had a closer look at
Security/Hasher. From what I understand your statements are not correct. Actually thepasswordsaltis only used to verify very old (legacy) password hashes. These are recognised by their length of 60 characters (and absence of|). See function legacyHashVerify.New password hashes (anything that has
|s and a preceding version marker) are verified by using PHP's functionpassword_verifyin function verifyHash without ever using the password salt.Hashes of new passwords are generated by applying PHP's function
password_hashagain without consideration of the password salt. See function hash.Bottom line: For new passwords
passwordsaltis not taken into account. Neither when calculating the hashes, nor when verifying the password hashes. There is no fallback to verify these password hashes first with and then without the password salt. There is no security gain whatsoever whenpasswordsaltis set in the configuration.The only case when
passwordsaltis taken into account is for verification of legacy password hashes of length 60 (and without any|). The enforcement ofpasswordsaltonly makes sense in case there is at least one such password hash in tableoc_users.Please correct me if I'm wrong.
- Why the config parameter
@PVince81 Based on the administrator documentation and the comment in the
config.sample.phpfile this parameter has been deprecated and should never be used by a developer anymore. I remember that I removed it from the configuration file approximately 6 years ago (Nextcloud 11.0.0) and never had problems afterwards. I wonder why it has been reactivated now but the documentation haven't been updated?!@deprecated This salt is deprecated and only used for legacy-compatibility, developers should *NOT* use this value for anything nowadays.Reacted by Shoki
Bug description
Upgrading to 25 with a config.php that has no or an empty passwordsalt results in an error message.
There is no clear solution on how to introduce a passwordsalt setting to an older setup.
Adiddional description on discord: https://help.nextcloud.com/t/passwordsalt-missing-from-config-php/148081/2
Steps to reproduce
1.install 24
2.use a config.php without a passwordsalt
3.upgrade to 25
Expected behavior
A warning before the upgrade or migration/guide to use salted password hashes.
Possible questions:
Does setting passwordsalt make passwords unusable?
What must be done to migrate this setting?
Installation method
Community Docker image
Operating system
Other
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "overwrite.cli.url": "https:\/\/nextcloud.domain.at", "enable_previews": false, "overwriteprotocol": "https", "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "25.0.0.18", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "maintenance": false, "theme": "", "forcessl": true, "trusted_domains": [ "owncloud.domain.at", "nextcloud.domain.at" ], "trusted_proxies": "***REMOVED SENSITIVE VALUE***", "overwritehost": "nextcloud.domain.at", "share_folder": "\/Shared", "secret": "***REMOVED SENSITIVE VALUE***", "loglevel": 0, "updater.release.channel": "stable", "htaccess.RewriteBase": "\/", "memcache.local": "\\OC\\Memcache\\APCu", "memcache.locking": "\\OC\\Memcache\\Redis", "filelocking.enabled": true, "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 6379, "password": "***REMOVED SENSITIVE VALUE***" }, "apps_paths": [ { "path": "\/var\/www\/html\/apps", "url": "\/apps", "writable": false }, { "path": "\/var\/www\/html\/custom_apps", "url": "\/custom_apps", "writable": true } ], "mail_smtpmode": "smtp", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "25", "mail_sendmailmode": "smtp", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "default_phone_region": "AT", "mysql.utf8mb4": true } }List of activated Apps
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response