After migration, passwords no longer work

[cigamit]

Migrating from an old Centos 7 server to Rocky 9. I installed the same exact version of Weblate 4.8 on the new server. Copied over my data, home, and settings. Backed up and restored the DB. I can see the users in the DB, they are using the pbkdf2_sha256 algo. I verified that that the algo is set in the Hashers (its handled by the PBKDF2PasswordHasher class).

PASSWORD_HASHERS = [
    "django.contrib.auth.hashers.Argon2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2PasswordHasher",
    "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",
    "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
]

But no user can login. I reset the admin password and can get in with that, and it got a new Argon2 hash. If I change the PBKDF2PasswordHasher to be the top, and then reset a user's password, I can login as that user and I see the account has a new pbkdf2_sha256 hashed password in the db. So its not like the Hasher isn't working. I have upgraded Weblate to 5.4.3 (latest for Python 3.9) and used the new example setting file and edited my settings into it, still the same issue.

pbkdf2_sha256 passwords are suppose to be portable, as it contains everything it needs in the hash (algo, iterations, salt, and hash). Django doesn't use the Secret_key to generate user password, but even if it did, I have the same key as the old box. No errors in any of the logs. The audit log just states "Could not sign in using password." So I am at a lost as to why it isn't working.

Next will try upgrading to python10 and the absolute latest Weblate, but I haven't seen anything in the changelog, issues, or PRs that makes me think this is something that was resolved in a later version.

Relevant versions

weblate 5.4.3
uwsgi 2.0.28
django 4.2.19
redis 5.2.1
celery 5.3.6

[nijel]

The passwords should just work after the migration. That's why there are multiple hashers in the list to support older methods (and migrate them to the new one upon login).

• Are users active? Inactive users cannot sign in.
• Wasn't the database corrupt somehow? Truncated fields, lowercase, or something like that?

[cigamit]

One of the accounts is mine, so I know its not an inactivity issue. I have the old server up still and can login to it. I have even done a select on the password field for my account in the old db, copy and pasted it into an UPDATE sql command on the other side. I am running Mariadb 10.5 on both (just different minor versions). The SQL dump set everything to UTF8 before dumping, and the default character sets are the same on the old servers and new (DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci), so its not an encoding issue.

Old server was running Django 3.2.8, so it was after they already upped the salt entropy and iteration counts for PBK and after they changed the default hashing algo from sha1 to sha256. I have went through every release note from Django from my old version to the new (4.2.19), and I see nothing that could possibly cause this except they keep upping the default iterations (which still wouldn't cause this, as its just the default for new passwords). I have tried downgrading django and dependencies back to 4.1, etc...

I think now I will start debugging the django code to trace down what exactly is happening.

[nijel]

The parameters such as iterations are usually part of the hashed password, so changing the parameters should not have an effect on the verification. What you can try is manually verify the password from the Django shell.

[nijel]

This Python snippet could be useful:

from weblate.auth.models import User
from django.conf import settings

# Check that password hashers are correctly set
print(settings.PASSWORD_HASHERS)
# Get user instance
user = User.objects.get(username="USERNAME")
# This prints the encoded password, it should be the same on both servers
print(user.password)
# Checks the password
user.check_password("PASSWORD")