Hi all,
A quick update, since the plan changed after review on PR #6670:
- FINERACT-2956 no longer rejects the current password. That check moved to
FINERACT-2961, so for 2956 a value of N still means the last N previous
passwords.
- For FINERACT-2961, resubmitting the current password when updating a user
(PUT /users/{id}) will be ignored rather than rejected, so nothing that
resends the user object breaks. Only the change-password endpoint (POST
/users/{id}/pwd) will return a 400 for it.
Details are on the ticket:
https://issues.apache.org/jira/browse/FINERACT-2961
Thanks,
Mandib
On Fri, 16 Oct 2026 at 21:18, Mandib Chaulagain <[email protected]>
wrote:
> Hi all,
>
> I've been working on the password reuse check
> (password-reuse-check-history-count). It never rejected a previously used
> password, because it compared bcrypt hashes with equals(), and bcrypt salts
> every hash.
>
> FINERACT-2956 fixes that in PR #6670. It also rejects the user's current
> password when the check is on, so a value of N now blocks the current
> password plus the last N previous ones. That's a behaviour change, and it's
> noted on the ticket.
>
> While working on it, I found a related problem, FINERACT-2961. When the
> check is off, setting a password to the one the user already has is treated
> as a real change: it saves a new hash, adds a history row and restarts the
> password expiry period. For the fix, I plan to return a 400 whenever the
> submitted password is the current one, regardless of the reuse setting.
> That's a new rule for installations that have the check off, so if anyone
> relies on being able to resubmit the current password, for example when
> updating a user, please let me know on the ticket.
>
> https://issues.apache.org/jira/browse/FINERACT-2961
> https://github.com/apache/fineract/pull/6670
> https://issues.apache.org/jira/browse/FINERACT-2956
>
> Thanks,
> Mandib
>
