Opened 9 years ago
Closed 9 years ago
#12278 closed defect (duplicate)
Reset password does not touch .htpasswd
Reported by: | Owned by: | Steffen Hoffmann | |
---|---|---|---|
Priority: | high | Component: | AccountManagerPlugin |
Severity: | normal | Keywords: | password reset, forgot password |
Cc: | Trac Release: | 1.0 |
Description (last modified by )
This is trac-1.0.4.
Using Reset password does send a new password via Email, but never touches the trac.htpasswd
. The new password doesn't work, the old password is still valid and password-reset enforcement is there after login.
Changing the htpasswd
file manually by the admin is the only work-around for users forgot their passwords:
htpasswd trac.htpasswd USER
I double-checked right now with the latest SVN version.
The logs have
INFO: Password reset for user: ...
and now error.
AccountManager config:
[account-manager] htpasswd_file = /mnt/data/trac/projects/A/trac.htpasswd htpasswd_hash_type = md5 login_attempt_max_count = 3 password_store = HtPasswdStore persistent_sessions = true reset_password = true user_lock_time = 30
Attachments (0)
Change History (10)
comment:1 Changed 9 years ago by
comment:3 Changed 9 years ago by
I read the password reset procedure but as the new password sent by mail just is not accepted this issue seemed to be a wrong behaviour.
Yes, looking like a duplicate of #11869. What is the status there? Discussion has just stopped.
If HtPasswdStore won't be able to use the Reset procedure by design then the cause is clear why my configuration is not working. Could we have a note about that in this section?
comment:4 follow-up: 9 Changed 9 years ago by
It is not strictly related to a particular password store. All share the common design limitation to store just one hash per UID.
In general the password reset (old style) was vulnerable to DOS attack by locking out users with known email through repeated password reset requests. So (new style) procedure now requires configuration of a hash method and enabling it together with ResetPasswdStore
.
#11869 is about a sane and graceful fallback from new to old behavior for some situations, especially when not using account manager's LoginModule
, so ResetPasswdStore
wont work too.
comment:5 follow-up: 6 Changed 9 years ago by
The fallback is only applied if not using AccountManager? All share the common design limitation? So is there any way to get password reset working with AccountManager without help of the administrator, as AccountManager provides the setting reset_password = true?
comment:6 follow-up: 7 Changed 9 years ago by
Replying to massimo.b@…:
The fallback is only applied if not using AccountManager?
I think you got my explanation wrong.
In Trac core (without account manager plugin) there is no user-accessible account management at all. The fallback I've been talking about refers to the former password reset procedure, that has been replaced. Now I aim at making it switch-able somehow.
All share the common design limitation?
Yes. I think you'll not find exceptions from the rule one UID - one password hash, even in third-party extensions providing more authentication backends for this plugin.
So is there any way to get password reset working with AccountManager without help of the administrator, as AccountManager provides the setting reset_password = true?
Yes, it should work for regular users, but I'm aware of issues regarding caching of relevant db parts in recent Trac 1.0.4.
comment:7 follow-up: 10 Changed 9 years ago by
Replying to hasienda:
So is there any way to get password reset working with AccountManager without help of the administrator, as AccountManager provides the setting reset_password = true?
Yes, it should work for regular users, but I'm aware of issues regarding caching of relevant db parts in recent Trac 1.0.4.
So how can I get a basic password reset without administrator? It does not work for regular users as described in the initial comment. That's why I filed this as bug. Would you prefer to move discussion to the mailing list?
comment:8 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:9 Changed 9 years ago by
Replying to hasienda:
In general the password reset (old style) was vulnerable to DOS attack by locking out users with known email through repeated password reset requests.
Could that be mitigated by some mechanism of SpamFilterPlugin, such as a captcha?
comment:10 Changed 9 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Replying to massimo.b@…:
Replying to hasienda:
So is there any way to get password reset working with AccountManager without help of the administrator, as AccountManager provides the setting reset_password = true?
Yes, it should work for regular users, but I'm aware of issues regarding caching of relevant db parts in recent Trac 1.0.4.
So how can I get a basic password reset without administrator? It does not work for regular users as described in the initial comment. That's why I filed this as bug. Would you prefer to move discussion to the mailing list?
I've also been very confused by the discussion in this thread.
The configuration in comment:description should work, after the additional configuration hash_method = HtPasswdHashMethod
. However it does not work. trac-hacks.org has a similar configuration and password reset doesn't work here.
You’ll probably find the following in the logs
11:58:28 Trac[web_ui] WARNING: ResetPwStore is disabled, therefor password reset won't work.
If using Trac's LoginModule
rather than AccountManager's LoginModule
, the configuration will not work. To be explicit:
- Password reset won't work when letting Apache handle the authentication:
acct_mgr.web_ui.loginmodule = disabled trac.web.auth.loginmodule = enabled
- Password reset could work using form based login and letting AccountManagerPlugin handle authentication:
acct_mgr.web_ui.loginmodule = enabled trac.web.auth.loginmodule = disabled
For case (2), I say could work, because I had to make a patch, which I'll post in comment:11:ticket:11869.
Thanks for taking care to report your findings. But I would prefer, if you did not ignore invitations to answer questions first - on our trac-users t:MailingList.
And be sure to read about the password reset procedure first, before asserting an issues where there is likely just normal behavior. Sure user's auth store is not touched before next successful login, because this way we avoid unwanted or even maliciously triggered lockouts by writing the new temporary password to
ResetPasswdStore
, a new, hidden store, that in turn requires loading and configuration of aSessionStore
's hash method. You shall see associated complaints on Trac environment re-load, if this is relevant for you.