346944 - If login fails due to bad password enter, there is no way to get a login screen to reappear

Status: RESOLVED INCOMPLETE

(Thunderbird :: Security, defect)

Description

[Tim Clark]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: version 1.5.0.5 (20060719)

If you enter a bad password in the login panel and fail authentication, the only way I have found to attempt to login in again and enter the correct password is to terminate Thunderbird and restart it.   If you just select "get Mail" again, it reuses the bad password and fails again. 

Reproducible: Always

Steps to Reproduce:
1.Set the profile for no auto logon

2.Restart Thunderbird
3.Select Read Mail from the main panel and the login window appears
4.Enter an incorrect password (I have to change my password every 30 days so this happens to me frequently.
5.Login will fail.   So how do you restart the logon to allow you to enter the correct password?? 

Actual Results:  



Expected Results:  
Detect the authentication failure and pop up the login window again to allow another authentication attempt with the correct credentials.

Comment 1

[Mike Enright]

I've seen this one with LDAP on 1.5.0.8. No pop-up happens, even though the LDAP server is sending a 'bind failure'. I couldn't even find the bad password in the password cache. I had to create a new LDAP server configuration to get a password prompt. 

Details:
I have known good exchange credentials, and I put them in the usual fields of the LDAP server configuration. At some point (I don't know when or how) the LDAP component of TBird decided that the password should be "lame1" (for example). But my exchange/AD password has to be changed every 4 weeks. I alternate between "lame1" and "lame2". I tried to get LDAP working today, and of course the password it should be using today is "lame2". I looked in the password cache and I could see my SMTP and IMAP passwords, but no indication what my LDAP password was. But with Ethereal I could see that TBird was sending the "lame1" password. So there's no UI and it's sending the wrong password.

In creating the new LDAP configuration, I made one change to see if it would game the system in my favor. The non-working configuration uses the server's "short" hostname. The new working config uses the "full" hostname. And now that one shows up in the password cache. But where is the old erroneous password being kept? Will I have to switch between the two LDAP configurations every month when my password changes?

Oddly enough, I don't have the problem with IMAP or SMTP. I wonder if there's some sort of migration issue. The TBird setup on this box goes back to around 11/1/04, a lot of TBirds.

I'm not posting these questions to get answers here. I'm posting them here to stimulate the developer's thought process.

Comment 2

[hartnegg]

This bug only occurs if the IMAP server closes the connection after the first wrong password attempt, for example on gmx.de
If the IMAP server leaves the connection open, Thunderbird issues an error message and then asks again for the password. If this time the correct password is entered, the connection is now established and new Emails shown.
If the IMAP server closes the connection, Thunderbird does not issue an error message, instead it displays the stored email list from the last run, including messages that were deleted long ago from another PC, not showing anything new that has come in meanwhile.
In my opinion these are THREE bugs: not showing an error message, not asking for the password again and showing an incorrect list of emails.

Comment 3

[Wayne Mery (:wsmwk)]

Do you see problem using thunderbird 2? Or, better yet, Thunderbird 3 beta 2**?

If you do, please 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
http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
(suggest you backup your profile before using beta release)

Comment 4

[hartnegg]

Problem still exists in Thunderbird 2.0.0.19 (on Win-XP SP3).

Comment 5

[Ludovic Hirlimann [:Usul]]

(In reply to comment #4)
> Problem still exists in Thunderbird 2.0.0.19 (on Win-XP SP3).

We rewrote the password management code completely for 3.0 so testing 3.0 b2 would help a lot.

Comment 6

[hartnegg]

The problem is unchanged in 3.0 b2, although it tries to hide the problem by caching email contents, even from imap-servers, even of emails that were not yet looked at, even though I switched that feature off and set the cache size to zero. The email contents even stay on the local hard disk when Thunderbird is removed and re-installed. This is absolutely not what I want when I configure an email client to use imap!

Comment 7

[Wayne Mery (:wsmwk)]

hartnegg, can you retry?

current trunk (not sure about beta 3) adds a prompt choice to enter a different password, in addition to retry and cancel.   It works fine for me with imap

Comment 8

[WADA:World Anti-bad-Duping Agency]

To Tim Clark(bug opener):

POP3? IMAP? (because you say "Get Mail", I ruled out NNTP/SMTP/LDAP)

To Mike Enright(Comment #1):

What is evidence that your problem on LDAP is same as original problem of bug(comment #0), even though what protocol is used still not unclear?

To [e-mail](Comment #2):

What is evidence that your problem on IMAP is same as original problem of bug(comment #0), even though what protocol is used still not unclear?

To Mike Enright(Comment #1) and [e-mail](Comment #2):

Because communication with server is relevant to phenomenon/problem, server side behaivour is relevant to problem, and server side behaivour depends on protocol and server, and Tb side behaviour also depends on protocol and server's behaviour.
See Bug 428611 for an similar external symptom/phenomenon on POP3.
Open separate bug for your problem, with attaching protocol log(LDAP or IMAP), please.
> https://wiki.mozilla.org/MailNews:Logging

To Tim Clark(bug opener), who reported this bug on 2006-08-01 for Tb 1.5.0.5, and no response/no additional comment to this bug.

Does your problem still occurs with newest release version of Tb 2.0.0.23?

Comment 9

[hartnegg]

The same problem occurs both with IMAP and POP (in Thunderbird 2.0.0.23).
The error is that (i) Thunderbird caches failed passwords and (ii) doesn't retry when the server closes the connection. Some servers do close the connection when a wrong password was sent, most servers leave the connection open to allow an immediate retry. Thunderbird should forget failed passwords and ask again before the next try. Can't test any newer versions right now, maybe next week.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #9)
> The same problem occurs both with IMAP and POP (in Thunderbird 2.0.0.23).
> The error is that (i) Thunderbird caches failed passwords
> and (ii) doesn't retry when the server closes the connection.
> (iii) Some servers do close the connection when a wrong password was sent,
> most servers leave the connection open to allow an immediate retry.
> Thunderbird should forget failed passwords and ask again before the next try.
> ( string of "(iii)" is added by me. )

(iii) is server's RFC violation. (i) is Tb's bug.
I think (ii) is wrong at least for some servers. Because some servers of (iii) silently kill connection, client side can't know event of connection-loss immediately. So, phenomenon becomes "Tb issues next command, and wait for reply forever" in some cases. "wait for reply forever" part is Tb's bug, if connection close is already detected by OS. I can say nothing about "connection close is not detected by OS" case.

Bug 508381 is for problem mainly caused by (i).
Bug 428611 is for problem of "no chance to re-enter correct password until restart" on POP3 when (iii) exists. Bug 429069/Bug 490140(listed in dependency tree for Bug 428611) is similar phenomenon on POP3 when (iii) exists, but restart isn't required fortunately. See POP3 log attached to these bugs.
I think similar phenomenon can occur on IMAP if (iii) exists.

I believe problem of (i) has been resolved by Bug 508381 on 9/06. (See Bug 508381 Comment #27).
Cause of Bug 428611(Bug 429069, Bug 490140) looks (iii) itself for me. i.e. Tb is not tolerant with (iii). I don't know whether patch for Bug 508381 will resolve problem like Bug 428611 due to (iii).

Check with latest trunk nightly, please.
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/
> If MS Win, download win32.zip build. You can test by UNZIP only.

Comment 11

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 429069 on POP3 due to (iii) still occurs with 2009/9/07 build.
Only difference was;
   connection error dialog -> password prompt (-> CAPA, then wait forever)
=> connection error dialog -> "Retry, New Password, Retry" dialog -> password prompt

Comment 12

[Mike Enright]

(In reply to comment #8)
> To Tim Clark(bug opener):
> 
> POP3? IMAP? (because you say "Get Mail", I ruled out NNTP/SMTP/LDAP)
> 
> To Mike Enright(Comment #1):
> 
> What is evidence that your problem on LDAP is same as original problem of
> bug(comment #0), even though what protocol is used still not unclear?

I was merely drawing a parallel. I was experiencing an LDAP problem (obtaining address book entries) where Ethereal (wireshark by now) would show that the wrong password was sent and I had absolutely no way to fix the password short of starting a new profile or adding a "new" LDAP server that was actually the same LDAP server by a different name. 
> 
> To [e-mail](Comment #2):
> 
> What is evidence that your problem on IMAP is same as original problem of
> bug(comment #0), even though what protocol is used still not unclear?
> 
> To Mike Enright(Comment #1) and [e-mail](Comment #2):
> 
> Because communication with server is relevant to phenomenon/problem, server
> side behaivour is relevant to problem, and server side behaivour depends on
> protocol and server, and Tb side behaviour also depends on protocol and
> server's behaviour.
> See Bug 428611 for an similar external symptom/phenomenon on POP3.
> Open separate bug for your problem, with attaching protocol log(LDAP or IMAP),
> please.

I'm going to have to let this drop because I don't know how to get the LDAP component into the state in which the problem happened. I no longer use the computer on which this problem occurred and I no longer have to change my password every month.

Comment 13

[hartnegg]

I think bug 428611 is a duplicate of this.

Comment 14

[hartnegg]

I cannot try this any more. The server, where I had this problem, now behaves different. Probably now it doesn't close the connection any more when a wrong password was entered. My problem went away, but I don't know how the final version 3 of thunderbird would behave if the server did still close the connection.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #14)
> I cannot try this any more. The server, where I had this problem, now behaves different.

There is no need to keep this bug open per comment #14.
Closing as INCOMPLETE.

To bug opener:
If your problem persists, and if you can provide data which can be evidence that your problem was caused by Tb's fault in Tb's code, re-open this bug with attaching sufficient data for diagnosis, please.