I recently converted two Wordpress sites to Classicpress , very happy.
However , when I use the Android Wordpress app , even just refreshing will disable / damage my site password.
I am then logged-out in all web admin pages elsewhere.
The browser-saved site password no longer works , so I request a password reset , visit the URL and reset the password to my original password and can then login again everywhere.
All non-vital plugins on the sites are disabled.
I am using an application password inside the Android app.
Anyone else having this issue or even using the Android Wordpress app ?
Site Software Versions -
ClassicPress : 2.2.0 (WP-6.2.6)
Android -
GrapheneOS 15 Stable.
timkaye
October 29, 2024, 12:26pm
2
Welcome to ClassicPress! And apologies for this problem!
We have indeed logged a bug that using an application password for a specific user causes that user’s original password to be rendered unusable.
My suggestion for a workaround while we develop a fix is to have two accounts for yourself, with one solely for using with an application password.
OK , thanks for responding and confirming my issue.
Is this the bug you are referring to ?
opened 02:04PM - 08 Oct 24 UTC
type: bug
### Expected behavior
Hi folks, I'm working on implementing the switch to usi… ng bcrypt for password hashing in WordPress core and somebody pointed out that ClassicPress made the switch in #1426. I took a look and I think the implementation will cause a user's password to be overwritten with an unexpected value whenever `wp_check_password()` is used to check something other than the user's password. This includes:
1. When a valid application password is used in ClassicPress core
2. When a plugin uses `wp_check_password()` to check something other than the user's password, for example an authentication code
The crux of the problem is that the `wp_check_password()` implementation in ClassicPress assumes the function is only used to check the user password of the given user, which is incorrect. The password can be for anything and it isn't always associated with a user account.
Note that I've not tested this, I've only read through the code. Proper testing is needed to verify whether the issue is valid.
### Current behavior
A user's password will be overwritten to the value of an application password at the point where a valid application password is used.
### Possible solution
Move the password re-hashing out of `wp_check_password()` and to the point where the function is called. See https://github.com/WordPress/wordpress-develop/pull/7333 for the implementation that I'm working on for WordPress core.
### Steps to reproduce bug
1. Set an application password for a user. This can be done from the user profile editing screen.
2. Perform a request that uses the application password, for example a request to a protected REST API endpoint.
3. Observe that after the successful request is made, the user's password has been updated to the value of the application password.
Alternatively, observe how `wp_check_password()` is used by third party plugins and likely suffers from the same problem: https://plugins.trac.wordpress.org/browser/better-wp-security/tags/9.3.3/core/modules/two-factor/providers/class.two-factor-backup-codes.php?marks=299#L282 .
### Context
_No response_
### ClassicPress version
2.2
### PHP version
I don't know
### Can you help?
I can help test a solution
system
October 31, 2024, 1:22pm
5
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
timkaye
November 8, 2024, 11:05pm
6
This should now be fixed in the latest nightly version. It would be great if you could test it before we release version 2.3.0, which is scheduled to include this fix.