[freddyDOTCMS]

Summary

• Passwords stored in the older digest format are matched only against the digest of the typed password; a stored value is never compared directly with the input. Matching values are upgraded to the current hash on login, as before.
• Accounts created for SAML, LDAP and CAS sign-in get the hash of a random secret as their local password.
• The initial admin password (DotCMSInitDb) and the passwords generated in UserManagerImpl.notifyNewUsers are stored hashed.
• WebDAV sign-in requires the configured pre-authenticator (auth.pipeline.pre) to accept the login, as UserManagerImpl.authenticate already does.
• Remove the unused UserLocalUtil.
• UserDataGen stores the hash of the password it is given, so tests sign in the same way users do.

Behaviour change

Accounts whose stored password is plain text no longer sign in with it and need a password reset.

Tests

• Unit: PasswordFactoryProxyTest (1)
• Integration, new: LoginFactoryTest (5), DotWebdavHelperAuthorizePrincipalTest (3)
• Integration, extended: SAMLHelperTest (+1, 13 total)
• Re-run, all passing: EncryptPlainPasswordsJobTest, UserResourceIntegrationTest, PermissionResourceIntegrationTest, WorkflowResourceLockUnlockIntegrationTest, BinaryExporterServletTest

Suite placement (just suite-timings 6):

MainSuite    median  samples   each run (min)
2a           15.9m       6   16, 16, 13, 13, 17, 19
3a           16.1m       6   17, 18, 12, 16, 16, 16
2b           18.4m       6   20, 17, 20, 19, 17, 17
1a           19.8m       6   19, 20, 17, 17, 21, 20
1b           26.9m       6   23, 29, 28, 21, 27, 26

-> register new coverage in MainSuite2a (15.9 min median)
   slowest suite is MainSuite1b (26.9 min median)

Fixes dotCMS/private-issues#901

🤖 Generated with Claude Code

[freddyDOTCMS]

For review: follow-ups identified during review are tracked as a pending list in the linked issue. Nothing on that list blocks this PR.

[claude]

Claude finished @freddyDOTCMS's task in 3m 8s —— View job

---

Review

• Read the PR diff
• Analyze auth/password changes for bugs & security
• Check error paths, replay safety, test gaps
• Post review

I traced the password-storage changes through UserAPIImpl.save (confirmed save(user, systemUser, false) is the 3-arg overload → respectFrontEndRoles, so it does not re-hash — storing the hash directly is correct) and the EncryptPlainPasswordsJob sweep.

New Issues

• 🟠 High: dotCMS/src/main/java/com/liferay/portal/ejb/UserManagerImpl.java:340 — notifyNewUsers now stores generateHash(newPassword) but never sets user.setPasswordEncrypted(true). The users are loaded via UserUtil.findByC_P(companyId, "password") (line 333) — i.e. accounts whose stored password is the plaintext default, so their passwordEncrypted column/flag is false. After setPassword(hash) the flag stays false, and UserUtil.update(user) persists password_ = hash, passwordEncrypted = false. EncryptPlainPasswordsJob (enabled by default, 0 0/5 * * * ?) selects exactly those rows (passwordEncrypted = false and password_ is not null, EncryptPlainPasswordsJob.java:44) and re-hashes them — producing hash(hash(newPassword)). The clear-text password that was just emailed to the user then fails passwordMatch, locking them out within ~5 minutes.

  This is the one place in the PR that stores a hash without flagging it: DotCMSInitDb.setUpInitialPassword (:203), SAMLHelper.createNewUser (:764) and UserDataGen.persist all set setPasswordEncrypted(true) right after setPassword. The fix is to do the same here.

  Fix this →

Notes (non-blocking)

• 🟡 Medium: the other random-hash paths — CASAuthUtils.loadUserFromLDAP:125, LoginFactory.syncPassword:287, LoginFactory.doLogin:369, DotCustomLoginPostAction.run:60 — also set a hash without setPasswordEncrypted(true). Here it is harmless (the value is a random secret nobody can type, and the job would only re-hash it into another unmatchable value), so this is not a defect — but setting the flag for consistency would stop EncryptPlainPasswordsJob from repeatedly picking these rows up as "plaintext" on every tick.

The rest of the change is sound:

• passwordMatch correctly drops the direct equals(password) comparison, guards the typed FAKE_PASSWORD, and guards a null/empty stored value before calling the verifier.
• The WebDAV change to require Authenticator.SUCCESS from the pre-authenticator matches UserManagerImpl.authenticate (line 564), which also only proceeds to passwordMatch when the PRE pipeline returns SUCCESS.
• DotCMSInitDb correctly downgrades the init-password failure from an abort to a logged error.

· issue-901-password-compare-hardening