280622 - infinite loop when password wrong

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Robert Harvey]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Thunderbird 1.0 20041206

If the account details for a pop3 mailbox are wrong, e.g. wrong or out of date
password in the password manager, and connection fails, then there is an
infinite loop.  Pressing OK on the dialogue only results in a retry - there is
no way to re-enter the password or back out of the attempted transfer.  The
process has to be killed.

Reproducible: Always

Steps to Reproduce:
1. create accounte
2. enter bad password first time connection is attempted
3. infinite loop entered - have to kill thunderbird
4. start thunderbird again
5. get mail from that account
6. infinite loop again - have to kill thunderbird



Expected Results:  
give up connection after a few tries, then remove entry from password manager. 
Next attempt would prompt for new password.

Comment 1

[Ralf Hauser]

this is particularly bad if the mail provider implements decent security features:
i.e. the smtp/pop is not an unlimited oracle for password guessing.


==> thus if once the password is wrong your password manager - you see the error
message from the server and you assume by pressing ok, the password-re-entry-for
correction pops up, but oops, already a second, unstoppable attempt with the
wrong password is under way. Another "ok" and you are typically locked out...
(at least for a few hours if the mail provider uses a throttle mechanism...)

I suggest to up the severity to "major"!!!

Also, I suggest to change this bug's subject line to "infinite loop when
password wrong in password manager - leading to lockout from responsible mail
providers"

Comment 2

[Ben Lentz]

Yes, this bug needs to be changed to MAJOR or CRITICAL.

We just had a misconfigured LDAP password cause an Active Directory Service
account to be locked out, bringing down many directory-based services because
Thunderbird was throwing 25 invalid password attempts against our  server per
second!

NOT GOOD.

This one needs to be given a serious priority boost. Perhaps giving this a
'security' spin will help elevate this one: Thunderbird was effectively used to
DoS our LDAP directory.

This experience was on a Mac OSX installation, so this bug is not linux specific.

Comment 3

[David :Bienvenu]

that doesn't sound like the same bug - the user couldn't be pressing cancel 25
times in a second. That sounds more like bug 270249, which we tried to fix for
1.0 (we were never able to reproduce this, so we tried to throttle the number of
logon attempts)

What version of Thunderbird are your users using? Can you recreate this in a
controlled situation, and perhaps generate a pop3 protocol log, by following
these instructions,
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap replacing
"protocol" with POP3.

Comment 4

[Ben Lentz]

First off, the problem is with an LDAP bind, not a POP3 Login. Parenthetically,
the mail is being accessed via IMAP, and not POP3.

And you're right, the user wasn't clicking cancel repeatedly, the Password
Manager saved password for the LDAP bind was attempting over and over in the
background, while the user worked with her mail obivious to the fact that this
was happening in the background.

It is Thunderbird 0.9 (20041109) for Mac OSX. I fully realize this is not the
latest version.

Comment 5

[David :Bienvenu]

just to be clear, was the ldap connection coming from the imap server, or
directly from the thunderbird client? I know some mail servers use an ldap
server for password verification...

Yes, Thunderbird .9 is old. Can you reproduce the problem with 1.0 or 1.1a?

Comment 6

[Ben Lentz]

The problem was coming from the Thunderbird client, as part of an LDAP Address
book configuration, and Password Manager was retaining the corresponding BIND
password for said LDAP Address book.

I can't seem to replicate the problem with 1.0.4... so perhaps it's been fixed.
I apologize if that was the case, because clearly it's my fault for not
upgrading. D'Oh.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Resolving as WORKSFORME as per last comment.