Closed Bug 339972 Opened 14 years ago Closed 10 years ago

User should be prompted for password when a stored password fails

Categories

(Thunderbird :: Security, defect)

x86
Windows XP
defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: aognio, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

All mayor other e-mail clients are doing this: if a stored password is not working , ask the user for the new password. In any situation it's the idea that perhaps makes more sense. It doesn't make sense to keep trying and trying with the old password. Removing the stored password to get prompted for the new one is not easy nor obvious and requires looking around several levers of windows.

Reproducible: Always

Steps to Reproduce:
1. Ask Thunderbird to remember a password
2. Change the password server-side

Actual Results:  
Thunderbird keeps complaining there's a problem with the stored password.

Expected Results:  
Thunderbird should prompt the user for the new password.

I understand doing something because all the other kids do it it's not logical, but in this case I don't think Thunderbird approach to this problem is a good solution.
is this an IMAP or POP3 server, and have you tried a recent nightly trunk build? I've made some changes in this area.
Confirmed with thunderbird 1.5.0.2 linux (ubuntu package). Annoying, i have been searching for password management in account settings instead of options. Hopefully google was my friend here. Prompt for new password should be done.
confirmed with Version 1.5.0.7 (20060911)
There could be a possibility to change or delete the password in "account properties" as well. Trying to get mail after having changed the password does not make any sense.
Some of my email accounts are not accesible any more due to this bug and worse they have got locked through automatic retries so that I can not access them via www any more.
A comment to the original bug report. I strongly contradict the following statement:

<quote>
It doesn't make sense to keep trying and trying with the old password.
</quote>

Yes, it DOES MAKE SENSE in certain cases to retry with the old password, EVEN if you received a permanent(!) negative reply from the POP/IMAP server.

I support several users with freemail accounts on Web.DE, one of the largest mail providers in Germany and probably even Europe. They regularly seem to have problems with their LDAP (or whatever backend they are using,) thus causing said "permanent negative reply."

Thunderbird in this case forgets the "old" (still correct!!!) password and forces the user to enter the "new" (i. e. old!!!) one. This is especially cumbersome for newbie users who don't understand what happened on the server's side, or when you are on the road and don't have your (cryptical) password in your memory.

So there should be a button "I'm positive that the stored password is valid, continue to use it."
"They regularly seem to have problems with their LDAP"

hum, to me it does not make sense to adapt a client software to a potential abnormal-and-specific-to-a-kind-of-achitecture server failure. Server should work, and password should be prompt when connection fails due to an authentication problem. If the server does not work, the user get confused and the mail provider should be blamed. If my server works and i changed my password, i should not get confused and should be prompted for my password. Especially in thunderbird case where password management dialog is not easy to find.

I understand that avoid prompting for passwords solve many problems and make sense in your case. But your case is not the general case, and it breaks "expected behaviour" of the client for most users.
I agree that "my" case is not the general case; nevertheless I opt for an additional button/checkbox (which possibly can be reached by switching the dialog to "advanced mode" (a feature to-be-implemented)) where users who know what they are doing can override the default/"correct" behavior.
I agree with comment #4, and the problem is definitely not limited to Web.DE.  Any time an IMAP server is having problems with authentication, it's possible it could send a "permanent negative reply".  I have this problem with my ISP (Dreamhost) every now and then.

I wish bug 48570 were fixed so I could vote against this bug.
do you see this problem in v2.0.0.6 or newer?

david's comment 1 changes probably made it into _version 2_,  but not v1.5 unless he later checked the trunk fixes into v1.5 branch.
Yup, I do see this problem in 2.0.0.6.

I'm using IMAP with MySQL as a back-end. To administer the login credentials, I use VExim.

To check whether the behavior has changed, I modified my password and started Thunderbird. Thunderbird gave me an error message "You cannot log on because you have enabled secure authentication, and this server doesn't support it." It then prompted my for a new password with the old password cleared (i. e. there wasn't a password masked by asterisks present in the entry field.) I clicked "Cancel."

From this point on, my old password was gone. Even after I shut down Thunderbird, changed the password on the server back to its original value, and restarted Thunderbird, it kept prompting me again and again for a new password.
I've recently been encountering password prompt popups for IMAP, due to internet connection flakiness.

However, users should never be prompted for password asynchronously a dialog box that is presented to accept the password. This is always susceptible to Trojans.

Rather, the user should be informed of the need to enter a password, possibly
via a dialog box, but preferably some other way (flashing window bar that says
"need password to continue"?) and then take appropriate action using the
facilities of the application to supply a password.

This seems related to, if not a dup of, bug 123440
Actually there is two issues that must be solved separately :
 1) this one, were when the connection fails server side due to wrong password, something must be done to make client ask for a password confirmation and/or a way to make client stored password easy to change. But connection should be check in background, to make sure the problem does not solves by itself (see Ralf G. R. Bergs comment).
 2) bug 123440 that occurs when server is unreachable/not responding.
I agree that those two issues (comment #11) can both occur.

Given the history of the problem, I'm not very sure that they can be discriminated successfully in all circumstances.

If a single solution can address both problems, then there is no need to solve them separately; or maybe my suggested solution _is_ two solutions... it has two parts.

Part 1 is to stop the asynchronous dialogs under all circumstances... providing some other method of informing the user than an error occurred... I mentioned flashing window bar in comment #10), but it could be changing the color of the account name in the list of accounts, or both.

Part 2 is to provide an interface which is _not_ an asynchronous popup dialog, to allowing the user to change the password, when that might be helpful (because it was changed on the server side).  This could be as simple (in the sense of few changes) as a button or menu entry that _synchronously_ invokes today's popup, but would be much better as a setting in the account settings, right alongside the corresponding usernames.
Assignee: mscott → nobody
Do you see problem using thunderbird 2? Or, better yet, please check Thunderbird 3 beta 2**?

If you do, please see the problem comment.
If you do not, please close the bug with resolution WORKSFORME (or some appropriate resolution, but not FIXED)

** Beta 2 has big fix of Bug 239131 Thunderbird should use the new password manager, which includes numerous improvements
http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
(suggest you backup your profile before using beta release)
Component: Account Manager → Security
Whiteboard: closeme 2009-04-25
QA Contact: account-manager → thunderbird
What I wrote in comment #9 still holds true for Thunderbird 3 beta 2. :-(
Whiteboard: closeme 2009-04-25
Ralf: your issue sounds much more like bug 121647 than what Antonio originally reported on this bug.
@Mark Banner: Yup, that's right. Thanks for pointing me to that one.
I agree to comment #13,  more improvements are landed with new TB 3 and password manager was completely rewrite (bug #239131).

Closing as WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Depends on: 239131
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.