Reset password does not touch .htpasswd

[massimo.b@…]

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

[Steffen Hoffmann]

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 a SessionStore's hash method. You shall see associated complaints on Trac environment re-load, if this is relevant for you.

[Ryan J Ollos]

Possible duplicate of #11869?

[massimo.b@…]

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?

[Steffen Hoffmann]

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.

[massimo.b@…]

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?

[Steffen Hoffmann]

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.

[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?

[Ryan J Ollos]

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?

[Ryan J Ollos]

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:

1. Password reset won't work when letting Apache handle the authentication:

   acct_mgr.web_ui.loginmodule = disabled
   trac.web.auth.loginmodule = enabled
   

2. 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.