Open Bug 634078 Opened 13 years ago Updated 2 years ago

[autoconfig] should be more forceful about asking for a password so we can verify logon

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Type:
defect

Tracking

(Not tracked)

People

(Reporter: Bienvenu, Unassigned)

References

Details

If the user doesn't enter a password in the first screen of the autoconfig dialog, we don't/can't verify the user's user name or logon, and we generally guess wrong, but we act exactly as if we did verify the logon. I think we should either require the password on the first screen, or warn the user if they don't enter a password that we can't verify their username or ability to logon, *or*, prompt for a password when trying to do logon verification.

There are cases where the user doesn't have a password (auth external) but that's an edge case, and they can put junk in. If the user has forgotten their password, or are offline, they can go into account settings to finish the account setup.

The *only* advantage I can see to prompting for the password when doing logon verification is that the user can see what username we're trying, and it's our normal password prompt.
> There are cases where the user doesn't have a password (auth external) but
> that's an edge case, and they can put junk in.

Agreed.

> If the user has forgotten their password

Then they shouldn't set up the account, because it's useless.

I think we should just plain out force the user to enter the password. They can uncheck [ ] Remember, but they'll have to enter it at least once during setup.

To clarify why this bug is important:
If the user does *not* enter the password, we have no way to verify the config. Neither do we have a way to guess the login configuration, e.g. username form and SASL auth method. In other words, the account wizard *breaks* in important ways, if we don't have a password, and we're likely to create non-working configs. They won't work even if the user enters the password later on, and then we can't fix it automatically anymore. We're creating broken configs this way. I don't think that's an acceptable tradeoff.
Blocks: 632755
I would also add that this is a common complain on Get Satisfaction and up until today, I didn't understand how so many users ended up with the wrong username, but now I think I do. And generally users always blame the password, not the user name.
> And generally users always blame the password, not the user name.

Yes, that's the big danger and time sink for users (hunt the wrong end..).

In fact, IIRC we *tell* them that the password is wrong. During mail check, we (rightfully) assume the config is correct, ask them for the password, and that fails. Of course they think the password is wrong, because that's what they entered.
Severity: Major
Severity: normal → major
OS: Windows 7 → All
Hardware: x86 → All
Bug 753516 is yet another case where an advanced user stumbled over this, causing things to fail later.
Severity: major → normal

I think we can close this as well.

  • The password is not required to create an account, which is correct as users might need to set things up without executing a first login.
  • As soon as the account setup completes, we prompt for a password if we don't have one since we're trying to connect to the server for the first time.
  • Enforcing to enter data that we don't actually need to complete the initial process is bad UX and unnecessarily slows down the configuration experience.
  • We also do a login test in case of Exchange selection if I'm not wrong, so in some cases we're enforcing the necessity of a password.
  • This bug has been opened for 11 years and the duplicates are not 100% related, so this is definitely something that our user base doesn't need/expect.
Flags: needinfo?(vseerror)

I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections per folder on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different password UI, which causes additional complexity in the code. The user might think that it's the same to enter the password in the beginning or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup again, to get the emails in the inbox, and then again when he sends an email, because we were not able to store the password for SMTP.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.

I don't have strong opinion. But I do have most of my passwords saved, many of which were provided when I added the account.

Some support folks might have an opinion.

Flags: needinfo?(vseerror)

I am seeing a group of users who change the password to none because they have forgotten it, or have never been asked for it before, so assume they don't need one. When that does not work they seek support.

My feeling is if folks are setting up their account that should know their password, otherwise all we get is a non-working account.

We don't have to save the password, but should insist on it being presented sop the account can be verified. These are also the same group who will tend to try and add it again and again if it does not work. Not only should we insist on a password, we should refuse to add the same email address again with the same protocol. Instead, pointing out the account exists, perhaps they would like to review those settings in the wizard instead of adding the account again. There is a user approach of add it again to fix it, which serves folk very badly on POP accounts in particular.

I can already hear the folk wanting the V2 everything is what you put in account setup back. The bottom line, I really can not think of a mainstream use case where you would set up your account in a nonworking state deliberately. Especially with the removal of mailspool.

I too fail to see the use case or point in setting up an email account that's not going to work or successfully connect to a mail server because the wizard allowed them to skip providing a valid password or because they took Thunderbird offline. What purpose is such an account going to serve? If there still are cases that do not required a password and it is decided to not enforce input of the password during account setup, then perhaps the outcome of the login verification process should be accorded greater emphasis and maybe even determine whether the account setup process can be completed or not. Allowing the setup to "complete" despite a failed authentication will simply be postponing an unaddressed problem to a further and more confusing stage to the clueless user. I like Outlook's connectivity test approach that demonstrates to the user whether their newly setup account is going to be of any use or not if it can't successfully authenticate with the server and send a test message while at it.

I've also seen a few questions at SUMO whereby the owner is setting up an account (in some cases after buying a domain via Tbird's help), but they did not know which password Tbird's account setup wizard was asking for! The same case for folks who forgot or just don't know which password specifically is being asked for. I would rather see these questions asked BEFORE they could "complete" the account setup minus a verified login. In my opinion, a user who doesn't know or has forgotten the password to their account will just dig themselves deeper into quicksand if allowed to complete the setup process minus a verified login. Not knowing what they've been up to in trying to fix a "broken Thunderbird" in their futile attempts at establishing a connection with the servers just makes it even harder to try and fix their problem after they've passed that account creation stage with what they think is the correct information. They'll most likely try to add the same account again and again (not knowing how to delete an account) and by the time they ask in SUMO, they won't have kind words for the community which just doesn't help things. All that can be avoided if they aren't allowed to complete the account setup without a verified login.

If it's a case of users not wishing to store their passwords in Tbird, they should be able to access the password vault and delete what was saved during the account setup and opt out of storing them when Tbird issues the prompts in future. They are a minority and have that option to suit their use case, so their special needs should not dictate Tbird's default behaviour which suits the majority just fine. Users ought to know the correct information, not just passwords or usernames, to use for accessing their email accounts in any client via whichever protocol. It's honestly not too much to ask for. They don't even have to memorise this information. We link email providers' support pages having the correct server settings all the time, and guide users with Tbird-specific settings if need be, so I don't see the need to try and simplify the account setup process to a point of encouraging/permitting non-fruitful outcomes.

Just an important side note, whatever automatic attempts you make, please NEVER send a plain text password to a server using an unencrypted connection.
(I don't know if this is ever done, I hope it isn't. Please just keep this in mind when working on the code.)

(In reply to Kai Engert (:KaiE:) from comment #13)

Just an important side note, whatever automatic attempts you make, please NEVER send a plain text password to a server using an unencrypted connection.
(I don't know if this is ever done, I hope it isn't. Please just keep this in mind when working on the code.)

I believe the configurations given/entered in the wizard are used. That's what I would use in the code. After all, is it not the goal of the automatic attempt to verify that the given settings do work? I don't see which alternative set of settings would be used instead of the ones the user intends to use for the account being setup. If it so happends that the email provider is still using insecure authentication methods, then there's nothing that can be done about it in Thunderbird. Unfortunately, there still are providers out there using insecure methods and that's exactly what Thunderbird would use IF the user wants to use Thunderbird successfully. A client doesn't dictate which authentication method a server uses. It's exactly the other way around.

I recommend to not send an unencrypted password automatically. In my opinion, if Thunderbird couldn't detect any working login mechanism that protects the password, then Thunderbird should show a prompt: "No secure authentication mechanism found. Should Thunderbird attempt to login using insecure mechanisms, which may potentially leak your password?"

That prompt is all good if the user knows or understands what it means, and they will most likely allow Thunderbird to proceed with the insecure method regardless. (I wonder why such a knowledgeable user would still be using an email provider that doesn't support secure methods, but I digress). However, the kind of users that BenB, Matt and I are referring to are likely to disallow Thundebird to proceed with the insecure mechanism without a second thought. The mere mention of potentially leaking their password might alarm them into making the very mistake we are trying to avoid here; they'll omit the password altogether because they obviously don't want it to be leaked, then end up with a useless account.

The prompt could work, though, if additional information about insecure login is linked to, say with a "learn more" link in the prompt explaining what it's all about. A link to a KB article would serve the purpose well, or a brief explainer in a pop-up modal dialog, with the KB article linked for those that wish to read more about it. I like the idea of the prompt; it's a functional way of showcasing Tbird's emphasis on security.

I think the user wants a mail setup that works. They also do not want to know anything about the process other than it works. Spend some time in support and learn about our users attitudes before making sweeping statements about security or passwords.

One thing is clear, they can not cope with mismatched certificates for wrong server/certificates, the general support request is about annoying dialogs that prevent them getting mail and how to make them go away. The user requesting support is not in the slightest interested in what might be the problem, or why the problem might lead to a man in the middle hack. Even if it is routinely by their antivirus product and it is their certificate that is the problem. It is a Thunderbird problem because it is not working how they expect.

So now we get to the crux. Is Thunderbird going to be a user-friendly and easy to use and just does email for the user in a manner something like they expect, or is it to be a nice product that has these evangelical ideals and therefore simply does not deliver on usability at all withers on the vine.

If the POP mail server only answers on port 110 without any form of encryption, then it is clear that anything else is not going to be a successful setup. They are rare enough now with more than 50,000 failed setup a week according to telemetry without placing locks on what can or should be done based on security principals held by developers.

https://stats.thunderbird.net/#telemetry

While it might be Ok to set a simple No encrypted connections found, try unencrypted option in the flow, there is no need for a "learn more" link. What do we tell them anyway? Seriously, in two paragraphs make a statement that allows the user to make a fully informed decision without unnecessarily alarming them. Need more space? Then the information density is too high for an account setup wizard. Can we guarantee that their password will not be hacked using TLS? I certainly would not be saying that. We used to think SSL3 was secure.

(In reply to Matt from comment #17)

I think the user wants a mail setup that works. They also do not want to know anything about the process other than it works. Spend some time in support and learn about our users attitudes before making sweeping statements about security or passwords.

One thing is clear, they can not cope with mismatched certificates for wrong server/certificates, the general support request is about annoying dialogs that prevent them getting mail and how to make them go away. The user requesting support is not in the slightest interested in what might be the problem, or why the problem might lead to a man in the middle hack. Even if it is routinely by their antivirus product and it is their certificate that is the problem. It is a Thunderbird problem because it is not working how they expect.

So now we get to the crux. Is Thunderbird going to be a user-friendly and easy to use and just does email for the user in a manner something like they expect, or is it to be a nice product that has these evangelical ideals and therefore simply does not deliver on usability at all withers on the vine.

If the POP mail server only answers on port 110 without any form of encryption, then it is clear that anything else is not going to be a successful setup. They are rare enough now with more than 50,000 failed setup a week according to telemetry without placing locks on what can or should be done based on security principals held by developers.

https://stats.thunderbird.net/#telemetry

While it might be Ok to set a simple No encrypted connections found, try unencrypted option in the flow, there is no need for a "learn more" link. What do we tell them anyway? Seriously, in two paragraphs make a statement that allows the user to make a fully informed decision without unnecessarily alarming them. Need more space? Then the information density is too high for an account setup wizard. Can we guarantee that their password will not be hacked using TLS? I certainly would not be saying that. We used to think SSL3 was secure.

I couldn't agree more!

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.