Closed Bug 596675 Opened 14 years ago Closed 6 years ago

Thunderbird attempts bad password multiple times on the mail server - Which locks out the account (when multiple authentication method are available, if bad password is typed by user, all atempts of login by fall-back is done with the bad password)

Categories

(MailNews Core :: Networking: IMAP, defect)

1.9.2 Branch
x86
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 516464

People

(Reporter: yoon, Unassigned)

References

Details

Attachments

(3 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 Thunderbird attempts to authenticate to the mail server multiple times until the account gets locked out. Reproducible: Always Steps to Reproduce: 1.clear password and unlock account 2. start thunderbird which prompts for account password 3. hit login with incorrect password, and then the mail account is locked out Actual Results: the account gets locked out on the server for 3 password failure attempts Expected Results: password prompt should come up immediately after the first login failure instead of retrying a bad password Thunderbird should immediately prompt for password after the first failure, instead of continuously trying a bad password. this is what we see on the server side with only entering in the password once. 11:10:29.868 1 EXTAUTH yoon@test.com(IMAP) plain password is incorrect 11:10:29.868 1 ACCOUNT(yoon@test.com) login(IMAP) from [192.168.13.221]:53512 failed. Error Code=incorrect password 11:10:36.972 1 EXTAUTH yoon@test.com(IMAP) plain password is incorrect 11:10:36.972 1 ACCOUNT(yoon@test.com) login(IMAP) from [192.168.13.221]:53512 failed. Error Code=incorrect password 11:10:44.091 1 EXTAUTH yoon@test.com(IMAP) plain password is incorrect 11:10:44.091 1 ACCOUNT(yoon@test.com) login(IMAP) from [192.168.13.221]:53512 failed. Error Code=incorrect passwor
Summary: Thunderbird attempts password 3 times on the mail server - Which locks out the account → Thunderbird attempts bad password multiple times on the mail server - Which locks out the account
this is pretty ridiculous why it attempts multiple times even though the password is incorrect.
Severity: normal → major
Component: General → Security
QA Contact: general → thunderbird
On thunderbird 2.X it attempted 2 times with bad passwords... which was semi-acceptable.
Attached file NSPR log with imap:5
Test procedure. With Tb 3.1.2. Clear password, restart Tb. No automatic connection by careful setting. Mac cache connections = 3, Gmail IMAP. Get Mail -> Password prompt -> Enter wrong password -> Dialog of "Retry, New Password, Cancel" -> Keep dialog open. Multiple logins are seen in log. It looks fall-back to other auth method. Because "reject of login due to wrong password" is impossible to know(protocol's spec), multiple logins can occur when multiple auth methods are usable. This case? Get IMAP log, and attach(not paste) log file to this bug after remove or replace of sensitive data, please. > https://wiki.mozilla.org/MailNews:Logging
Component: Security → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: thunderbird → networking.imap
Version: unspecified → 1.9.2 Branch
Multiple logins in my log were for different ProcessCurrentURLs. Internal automatic process looks to use already typed(wrong) password, even when dialog of "Retry, New Password, Cancel" is displayed.
The Server is only broadcasting clear text as the only available authentication method. Why is it trying other methods. Can't we have an option not to use these other methods? When I set an IMAP client to use plain text, i expect it to do just that. Non-encrypted & Clear text. Why would i expect it to do otherwise? I can see it doing this on the first time the account is setup, since users may not know what method to use. But once you have it set in place, there should be no reason to try and use any other methods. Will include logs on next test.
we won't try secure auth mechanisms unless the server advertises them and you've configured the client to use them. But we'll do both base64 and clear password, since they're both insecure...
I've configured my client to be plain text over imap 143. I understand that the server may be advertising those other methods, but if it is advertising plain text, why would you think the expected results would be any different trying another method. Here's the problem. My server supports all of those methods. And the client using all the methods will lock the account out. How can we fix this issue? At the least I would think you should have an option to disable that segment of it in advanced options.
Attachment #476273 - Attachment mime type: text/rtf → text/plain
(In reply to comment #7) > Here's the problem. My server supports all of those methods. And the client > using all the methods will lock the account out. How can we fix this issue? As you can see in Tb side log with Gmail I attached, only sigle login is tried by Tb at a conection if Gmail IMAP. Appropriate CAPABILITY response and appropriate IMAP server setup can force "single login attempt via a socket" is possible. So, "concecutive three login failures at a session" can easily be avoided. However, as you can see in Tb side log with Gmail IMAP, Tb tries to login via other sockets(default of max cached connection=5, trying of 5 pararel logins can happen) even while dialog of "Retry, New Password, Cancel" is displayed for first login failure at first connection/socket. If this kind of pararel login failures can cause account lock by your IMAP server, change/improvemen of Tb will be required. Confirming by attached server side log.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes, I could disable the mail server from announcing all of the available methods. But our mail server doesn't just do MAIL. There is a reason we need all those other methods available. Why can there at least be an option in thunderbird to disable these methods. Thunderbird is the only mail client that we have an issue with. Every other mail client we use never has this problem.
Robert, can you generate a client-side log, using the instructions at the top of the bug?
Attached file thunderbird client logs (obsolete) —
heres the thunderbird logs
Yeah, so there are three insecure auth mechanisms and we try them all, because historically one or more may be broken on the server. But I think you could argue that it's unlikely that the plain auth mechanisms would be broken, and we should only try one. Ben, thoughts?
> The Server is only broadcasting clear text as the only available authentication > method. Why is it trying other methods. First off, your server offers not just one, but 3 plaintext passwords methods: * old-style IMAP login (login command) * AUTH PLAIN * AUTH LOGIN I doubt you need the latter. > But our mail server doesn't just do MAIL. So, you are in control of the server. Can't you just allow more login attempts, given that you *know* that Thunderbird tries several times? Apparently, all ISPs do that as well, because we had no complaints so far. E.g. 9 or 6 (when disabling LOGIN), that would match 3 user attempts. It wouldn't significantly increase risk, as attackers usually need dozens or even thousands of password-guessing attempts. ---- bienvenu, I don't know why Thunderbird tries them all. I can only assume that you had cases where these methods were announced, but not implemented. Skipping that only for plaintext methods would complicate the code.
> I doubt you need the latter. More precisely: AUTH LOGIN is entirely deprecated in favor of AUTH PLAIN and can be safely disabled. It adds nothing to normal IMAP "login", which all clients should speak, so I don't follow your "other clients" argument. AUTH PLAIN is mildly useful, because it scambles the username and password, but no more. You could implement "login" and AUTH CRAM-MD5. That would actually be useful: Support all clients, and make it secure for Thunderbird clients.
...and Thunderbird would try only once, assuming you set either "insecure password" or "encrypted password" in the server settings. As for "our mail server doesn't just do MAIL": Most servers allow to set AUTH methods per server type. If your "CommuniGate Pro IMAP Server" can't do any of that, you can still increase the allowed login attempts to 9 (given that this is the first report I've seen) and that's it.
bienvenu, whether to change Thunderbird is a judgment call. If it's just very few internal servers like this one, I would not change it. If a considerable number of users run into it, I would change Thunderbird, because the error consequences are unpleasant. In other words, I think we should wait for more reports or information.
Ben: So my server offers 3 plaintext password methods. * old-style IMAP login (login command) * AUTH PLAIN * AUTH LOGIN Which non of are configurable on my server. So I cant disable one of them even if i wanted to. Secondly, in terms of password attempts, that is something I cannot change. Dont you think i would of done that by now? We are a company with strict security rules for specific reasons. So I cant change that policy unfortunately. I still dont see why it tries all 3 methods being advertised. We're offering 3 methods choose 1, not all 3. Why not use all the methods advertised and try everything. Why stop @ 3? Thirdly, the only methods we want to support are plain text. Either over plain text over IMAP or plain text over IMAPS, hopefully only the latter. The reason for this is that Communigate is using an external authentication script which does not support NTLM,TLS, or any other method other than plain text. I know you're gonna say fix this, but this is the hand i am dealt with. The external authentication script does LDAPS queries against active directory, and I don't think active directory support those authetication methods through ldap. The script they handed us expects plain text. Im really not asking for a whole overhaul of TB. All im asking is for the ability to have the option to make those decisions ourselves instead of the client automatically making those decisions. We have actually 2 different mail servers. One is Communigate and the other is Netscape. Both are running into this situation. This is for over 1000 users that we have. All of the other mail clients we use (Mac Mail, Outlook, Eudora) do not exhibit this 3 time failure. So why aren't they trying 3 times? Is it because they trust the server when it announces the different methods and just picks one? Why not just pick the securest of the 3 and stick with it, instead of trying all 3 of them.
I believe I explained why we try all three - we try them all, because historically one or more may be broken on the server. This is more true for the fancier auth mechanisms, of course.
Attachment #476367 - Attachment is obsolete: true
David: So you are making people whose methods work, suffer for those that don't have their methods in tact. I can see the reasoning behind it, but why don't other mail clients follow suit? They all fail only once. Is it because their product is inferior? I cannot change the plain text methods being announced. So what can i do? nothing?
Robert, I'm just explaining the reasoning so please try to be civil. There are always trade-offs and making everyone happy is very difficult
David: Sorry didn't mean to come off like that. Im just wondering what i can do to make this work. I dont know if this is really even considered a *bug*. Seems more like a decision that was made and stuck with. What should we do?
I do consider this a bug, mainly because the consequences are relatively painful. There are a few options - don't fallback on insecure auth at all, add a hidden pref to disable auth fallback (we used to have one, I thought), allow the user to specify which insecure auth mechanism to use and don't fallback. The last one is pretty much a non-starter since I don't think users should have to know how to choose between them. Ben certainly raises some valid points - lockout after three failures is pretty harsh; turning on a secure auth mechanism would sidestep the whole issue and be more secure...Netscape mail server is pretty obsolete, and I know from personal experience that it doesn't have to lock you out after three failures
Thanks for the logs, they surely clarify things. > why stop @ 3 Because your server offers exactly 3 methods: login (default), AUTH LOGIN, AUTH PLAIN. We try all (we happen to support them all), for reasons bienvenu explained. > that is something I cannot change. But somebody in *your* company can. If it's easier to change a world-wide software than your own companies' rules, there's something wrong, honestly. I do understand that enabling encrypted passwords can be hassle, yes. But you do have to admit (and can tell your security guys) that on the one hand allowing plaintext passwords and then OTOH having a strict rule on password attempts makes no sense - a sniffing attacker knows the password right the first time. Note that you can leave only plaintext passwords, but mandate SSL/TLS. Your log shows that STARTTLS is possible, but optional. I do not think this is strictly a bug, but indeed very unfortunate in your situation. But it did work for many millions of people with no complaints so far. I think that's a good idea: > allow ... to specify which [...] auth mechanism to use and don't fallback In fact, make a pref that specifies which exact auth method[s?] (any, not just insecure ones) to use and nothing else. That would not be particularly hard to implement, because it could be confined in InitPrefAuthMethods(() [1] where it logically belongs, and not a hack. It would be a hidden pref, with an uncomfortable value, and set by admins / support, and only for those few companies that have so strict rules or other reasons, so no problem with usability I think. I think that'd be a good, clean, generic solution that may help in entirely different situations, too. [1] http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#5445 > Im really not asking for a whole overhaul of TB. All im asking is for the > ability to have the option to make those decisions ourselves instead of the > client automatically making those decisions. Yes, this solution would offer that.
> I think that'd be a good, clean, generic solution that may > help in entirely different situations, too. In fact, if there are few enough server with broken AUTH method implementations, we could turn this around and mandate that *their* users set this pref to the working auth method, and disable the fallback. I don't think that's possible, though, IIRC we saw some big servers with failing AUTH methods. I don't remember details, whether it was only (the more complicated) secure methods or also AUTH LOGIN. I vaguely remember something with AUTH LOGIN, but I am not sure.
Hey! Reading the code, you could just set the pref to "old login", i.e. authMethod = 2. That would use IMAP login, none of the AUTH methods, and would make only one attempt. Given that you use insecure auth anyway, you're off no worse. It works with current code. Problem solved (hopefully) :). I still recommend that you disable login without SSL, and that you change your policy to be less strict :). That said, the pref proposed is general enough to help in other cases, too, so maybe it would still be worth to implement, when somebody has time.
Note that authMethod = 2 (old-style login) doesn't work for SMTP, as there is no native login mechanism. It does work for POP3. If this pref is implemented, it should be done for all protocols: http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsPop3Protocol.cpp#1607 http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#856 Sorry for the many comments each time. I hope I added some value at least :).
Ben: Cool. Where is that setting? I only have regular imap for testing/sniffing purposed. All users use SSL with plain text IMAPS. Obviously without any sort of password encryption its a security risk. Thats something I can work on doing. Not quite sure how im going to do it, but thats for me to figure out. (In reply to comment #27) Where can i find this pref setting? > Hey! Reading the code, you could just set the pref to "old login", i.e. > authMethod = 2. That would use IMAP login, none of the AUTH methods, and would > make only one attempt. Given that you use insecure auth anyway, you're off no > worse. It works with current code. Problem solved (hopefully) :). > Eventually I will be blocking regular imap logins. > I still recommend that you disable login without SSL, and that you change your > policy to be less strict :). > I would love to see this option in place. > That said, the pref proposed is general enough to help in other cases, too, so > maybe it would still be worth to implement, when somebody has time. We've been suffering with the double attempts for some time, but it was bearable. Even doubling or tripling my incorrect password policy could still lock users out potentially. 9 password failures to get 3 password attempts is excessive in my opinion. I'll give the options a try when you tell me where to do it. It could be easy enough to roll out for the entire company.
> Ben: Cool. Where is that setting? menu Edit/Toors | Preferences... | Advanced | General | Config Editor... Filter: server For the entire company, you probably want to automate that, by writing the prefs files manually.
Would there be a way to automate this?
Yes. Search the web, esp .mozilla.org sites (no, I don't have the doc handy). The file you want to mod is prefs.js.
Thanks for all the help. We would also appreciate it if these options were to be seriously considered for release in future versions of thunderbird. Thanks again.
Sorry to bring this topic back up again but I have a couple more things I'd like to bring up. I dont mind setting the setting to 2 for the default auth method, but apparently every upgrade, this setting is getting reset to 3. This is quite annoying and is still causing us problems. Do you think you guys can consider setting up a configurable setting in the advanced settings to uncheck the undesired methods instead of forcing it to use the old method 2? Also in regards to other mail clients not behaving this way, is there any reason you guys aren't doing the same thing in regards to auth methods? I know i indicated I could not disable the announcement of the 2 other methods, and that is still the case today. Also going from thunderbird 2 to 3, how come the number of auth attempts changed from 2 to 3? Was this to help with another problem users were seeing? Since you guys accommodated them by adding in other attempts, perhaps you guys can meet in the middle and offer both ways, but make it configurable? Thanks again
I wrote: > The file you want to mod is prefs.js. You wrote: > I dont mind setting the setting to 2 for the default auth method, > but apparently every upgrade, this setting is getting reset to 3. Try user.js.
Would the user.js be stored in the same location or could we place is somewhere more global? Thanks
It would be in the profile.
Summary: Thunderbird attempts bad password multiple times on the mail server - Which locks out the account → Thunderbird attempts bad password multiple times on the mail server - Which locks out the account (when multiple authentication method are available, if bad password is typed by user, all atempts of login by fall-back is done with the bad password)
The issue is still up to date. When a wrong password is entered, Thunderbird attemps to auth multiple times (>10times/s !), thus locking the IP address. Tested (unfortunately) with different accounts, IP addresses, and on Windows+Linux. The frequency of the authentication attempts should be drastically reduced !

Sounds like bug 516464. Do you still see this problem in version 60?

Flags: needinfo?(felix)

(In reply to Wayne Mery (:wsmwk) from comment #40)

Sounds like bug 516464. Do you still see this problem in version 60?

We no longer use the same mail server or Thunderbird for that matter.

Couldn't tell you without test, but that enviornment no longer exists. Sounds like u guys fixed it

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(felix)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: