525083 - [autoconfig] "Secure Authentication" not properly detected

Status: RESOLVED WORKSFORME

(Thunderbird :: Account Manager, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

From bug 491202 comment 41, which the patch there didn't fix:

I was using autoconfig wizard to test my school's IMAP server. It can work on
both STARTTLS and SSL for the IMAP server, but it's preferred to use SSL.

autoconfig, upon detecting STARTTLS support, greenlights it, but I switch to
SSL. It then greenlights on SSL, but when I click Create Account, it gets
"stuck", the Create Account gets greyed out (makes sense since I already
clicked it), and the wizard fails to create the account, it goes into some sort
of attempted authenticating loop before eventually asking me to recheck my
username/password (which are definitely correct)

Later I realize when I click Manual Setup, the Use Secure Authentication
checkbox was ticked. No wonder it doesn't work! However, there wasn't any way
for me to explicitly specify "Don't use Secure Authentication" in the
autoconfig wizard.

Comment 1

[Blake Winton (:bwinton) (:☕️)]

So, could you set "mail.wizard.logging.dump" to "All", and send me the log, so that I can try to figure out what's happening?

Thanks,
Blake.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5pre) Gecko/20091028 Shredder/3.0pre

Argh, I think I had pressed "Manual Setup" previously while retesting, but the log seemed ok if I clicked Continue.

That said, this might indeed been fixed by bug 491202...


2009-10-28 15:24:12     mail.wizard     INFO    show status title failure, msg: Checking password&
2009-10-28 15:24:12     mail.wizard     WARN    username setting icon and tooltip hidden:
2009-10-28 15:24:12     mail.wizard     WARN    usernamespinner start checking_password
2009-10-28 15:24:12     mail.wizard     INFO    Starting to test username
2009-10-28 15:24:12     mail.wizard     INFO      username=true
2009-10-28 15:24:12     mail.wizard     INFO      secAuth=true
2009-10-28 15:24:12     mail.wizard     INFO      savedUsername=false
2009-10-28 15:24:16     mail.wizard     INFO    tryNextLogon()
2009-10-28 15:24:16     mail.wizard     INFO      username=true
2009-10-28 15:24:16     mail.wizard     INFO      secAuth=true
2009-10-28 15:24:16     mail.wizard     INFO      savedUsername=false
2009-10-28 15:24:16     mail.wizard     INFO      Changing username to email address.
2009-10-28 15:24:16     mail.wizard     INFO    Starting to test username
2009-10-28 15:24:16     mail.wizard     INFO      username=false
2009-10-28 15:24:16     mail.wizard     INFO      secAuth=true
2009-10-28 15:24:16     mail.wizard     INFO      savedUsername=true
2009-10-28 15:24:19     mail.wizard     INFO    tryNextLogon()
2009-10-28 15:24:19     mail.wizard     INFO      username=false
2009-10-28 15:24:19     mail.wizard     INFO      secAuth=true
2009-10-28 15:24:19     mail.wizard     INFO      savedUsername=true
2009-10-28 15:24:19     mail.wizard     INFO      Re-setting username.
2009-10-28 15:24:19     mail.wizard     INFO      Changing useSecAuth to false.
2009-10-28 15:24:19     mail.wizard     INFO      password=true
2009-10-28 15:24:19     mail.wizard     INFO    Starting to test username
2009-10-28 15:24:19     mail.wizard     INFO      username=true
2009-10-28 15:24:19     mail.wizard     INFO      secAuth=false
2009-10-28 15:24:19     mail.wizard     INFO      savedUsername=false
2009-10-28 15:24:23     mail.wizard     INFO    show status title success, msg: Password ok!

Comment 3

[Blake Winton (:bwinton) (:☕️)]

Okay, so based on that, I'm going to remove it from the potentially blocking list, and slightly change the description.  Does this new version of the bug work for you?

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #3)
> Okay, so based on that, I'm going to remove it from the potentially blocking
> list, and slightly change the description.  Does this new version of the bug
> work for you?

Yup, that works too - so the autoconfig doesn't have to test the other option if the user specifies either to Use or Not To Use secure authentication. I'd differ to your opinion as to whether it should remain auto-detected or not.

Comment 5

[Magnus Melin [:mkmelin]]

If it's a secure connection i'd say secure authentication should be off by default even if it's supported. Why would anyone want to use that if it works without?

Comment 6

[Ben Bucksch (:BenB)]

Because encrypted passwords are safer than clear passwords, e.g. when the server gets hacked. Some systems make a point of never having the password in the clear.

Comment 7

[Ben Bucksch (:BenB)]

See e.g. http://www.zeroshell.net/eng/kerberos/Kerberos-definitions/ , heading "1.3.4.2  Encryption key" and "Salt" for background. This text is about Kerberos, but it applies just as well to CRAM-MD5.

Comment 8

[Ben Bucksch (:BenB)]

Changing back summary, because we want to autodetect it, not users select it.

Comment 9

[Magnus Melin [:mkmelin]]

I see. But that would mean almost nothing if secure auth is optional. If someone has such a policy they should disable insecure auth, no?

Comment 10

[Ben Bucksch (:BenB)]

Servers can do that, by simply not offering plaintext password auth (no LOGIN or PLAIN in AUTH CAPABILITIES).
And we as client do that, by checking whether encrypted passwords are offered and work, and if so, set this in the account prefs, and therefore force encrypted passworts during logins.

Comment 11

[Ben Bucksch (:BenB)]

And even if a server accepts cleartext passwords, it can then immediately encrypt them. At least a cracker wouldn't get all the passwords in the database, just those of the people who log in with cleartext passwords. Those users who log in with MD5 would still be more secure, even with SSL. (Unless the cracker has rainbow tables and the user a weak password, yadayada...)

Comment 12

[Blake Winton (:bwinton) (:☕️)]

I'm not really working on these, so I'm freeing them up for a community member to take.
(Filter on [ossifrage] to delete all the notifications.)

Comment 13

[rsx11m]

Ben, this was filed and has seen the last action before bug 549045 redesigned autoconfig, is this issue still applicable or can this bug just be closed WFM if not?

Comment 14

[Ben Bucksch (:BenB)]

This should be long fixed. If you still see it, please reopen with a concrete server hostname(s) and reproduction. Without hostnames, there's nothing actionable here anyway.