You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Mandib Chaulagain <ma...@gmail.com> on 2026/10/16 15:33:22 UTC
Password reuse check fixes (FINERACT-2956, FINERACT-2961)
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
Re: Password reuse check fixes (FINERACT-2956, FINERACT-2961)
Posted by Ádám Sághy <ad...@gmail.com>.
Thank you for the heads-up.
Regards,
Adam S
> On Oct 25, 2026, at 4:17 PM, Mandib Chaulagain <ma...@gmail.com> wrote:
>
> 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 <mandibchaulagain8@gmail.com <ma...@gmail.com>> 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
Re: Password reuse check fixes (FINERACT-2956, FINERACT-2961)
Posted by Mandib Chaulagain <ma...@gmail.com>.
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 <ma...@gmail.com>
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
>