background ========== For the past few days, most every step of using yahoo e-mail in Thunderbird is taking minutes rather than seconds. Examples: log in, selecting a folder, selecting a message. I've changed nothing. I looked at Thunderbird help. I saw in a different, very recent problem that the user was advised to change his authentication method.
The authentication methods that Thunderbird offers for IMAP, SSL/TLS are Normal password, Encrypted password, Kerberos / GSSAPI, NTLM, TLS Certificate, OAuth2.
I do not have a cell phone or any texting or social networking accounts, so I cannot use 2-factor.
questions ========= 1. Am I correct is believing that nothing that I did in the "unwanted checks for updates." thread would cause these problems? 2. What are the advantages, disadvantages, and security risks of each of the 6 authentication methods offered by Thunderbird for yahoo e-mail?
Allegedly, on or about 24 December 2018, home user via users sent:
- What are the advantages, disadvantages, and security risks of each
of the 6 authentication methods offered by Thunderbird for yahoo e- mail?
You can only use the options that the ISP supports as well. Which probably means only one or two out of the list. Look them all up on Wikipedia, if you want mostly understandable explanations of each of them.
Normal password is the common plain-text/unencrypted username and password logon scheme as used with POP/IMAP for many years. Though, when you enable secure logon features (like TLS), an encrypted connection is set up, first, and the transmitted data will go through it *ALL* encrypted.
Kerberos is an authentication scheme that's probably only going to be available within an office LAN. NTLM was a Microsoft scheme. GSSAPI and OAuth2 are processes of how to handle logons. I've never used any public mail system that uses any of them (or advertises that they do).
SSL/TLS will use encryption to log on (your username and password will not be sent in the clear), and for transmitting the message (the connections are encrypted). TLS is supposed to be better than SSL. But what you're doing is sending unencrypted content through a secured channel, either side of the connection between yourself and your mail server, the message is readable by anybody who can manage to look at it.
Remember that most mail goes unencrypted between the different mail servers in the world. If you require privacy, then you need to encrypt your messages using something like GPG/PGP. Both sides of the conversation need to understand how to use it.
Certificates (depending on context) will either use a certificate instead of username and password, or will simply be the verification of the encryption used by the server (like when using HTTPS on the WWW) before the logon process starts, or used for encrypting the entire message.
Some schemes simply encrypt the logon procedure, for user security, but the actual transmission of messages isn't encrypted. So, if you were working in an insecure LAN, for instance, messages could be read by snooping on the data.
Be aware that it's possible to configure encryption, or not, separately for receiving and sending mail. If you require it, pay attention to what you're configuring.
Thank-you, Tim.
... Look them all up on Wikipedia, if you want mostly understandable explanations of each of them.
I used to think Wikipedia is great. Lately, my opinion of it is declining. It's not always authoritative, it's not very stable (article contents change too much, too often), and other faults. I'm almost certain I'm not the only member of this list with this view.
Normal password is the common plain-text/unencrypted username and password logon scheme as used with POP/IMAP for many years. ...
No mention was made of OAuth2. Wikipedia did not tell me enough about it. Is it likely to be available for logging in to yahoo, gmail, and the other common free commercial e-mail services? If yes, what are its advantages, disadvantages, and risks relative to Normal password, which is what I'm using now?
On 12/26/18 11:05 AM, home user via users wrote:
Thank-you, Tim.
... Look them all up on Wikipedia, if you want mostly understandable explanations of each of them.
I used to think Wikipedia is great. Lately, my opinion of it is declining. It's not always authoritative, it's not very stable (article contents change too much, too often), and other faults. I'm almost certain I'm not the only member of this list with this view.
Normal password is the common plain-text/unencrypted username and password logon scheme as used with POP/IMAP for many years. ...
No mention was made of OAuth2. Wikipedia did not tell me enough about it. Is it likely to be available for logging in to yahoo, gmail, and the other common free commercial e-mail services? If yes, what are its advantages, disadvantages, and risks relative to Normal password, which is what I'm using now?
OAuth2, despite its name, has nothing to do with two-factor. It essentially gets credentials from a third party log-in mechanism and passes those credentials along with the transaction it's trying to do.
The most common thing is logging into a site using, say, your Facebook account. The site you're using into doesn't know anything about your account, but passes the authentication stuff off to Facebook. If Facebook says you're OK, then you're in and the token you get back from the site must be included in any future transactions. The token is typically only valid for a short period of time...the site can revalidate when it expires if it wishes to. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - I don't suffer from insanity...I enjoy every minute of it! - ----------------------------------------------------------------------
Allegedly, on or about 26 December 2018, home user via users sent:
I used to think Wikipedia is great. Lately, my opinion of it is declining. It's not always authoritative, it's not very stable (article contents change too much, too often), and other faults. I'm almost certain I'm not the only member of this list with this view.
While that's true, I still find it a good starting point for looking things up. There's mostly understandable explanations of technical stuff, and references to sources of information. And because the site gets reviewed, things get improved.
No mention was made of OAuth2.
My first port of call is usually Google, though. And you can try doing a search using just the keywords of OAuth2 and yahoo, then try OAuth2 and gmail, etc.
Plain text passwords are just bad news anywhere. Inside your own LAN, where nobody else connects, not so much of an issue. But if you do anything that allows an outsider to connect to it, then they're bad.
A lot of mail servers don't allow plain text passwords any more. If you try to connect using one, the logon process refuses before it even starts and your system never even gets as far as sending your the password, and probably even before you even send a username.
Encryption is only as good as the encryption is. But it's the best choice, and any security failure is limited to that particular bad service.
Various third party authenticators, where you authenticate with one service, and it authenticates you with other services that listen to it, have their own set of problems. Kerboros, GSSAPI, OAuth2 are examples of that kind of scheme, and things that allow Facebook or the old Microsoft passport to authenticate you. While they have the convenience of login once, and not have to do it again for other things, most things let you save your password, so you only ever had to enter it once when configurating the program, anyway.
The problems they have are being a central point of exploitation: Someone cracks that and you're instantly vulnerable in multiple places. And they know everything that you're up to, so you're trackable and databasable, privacy goes right out the window with any authenticator who doesn't give a damn about you. And they're a central point of failure, it goes down and you lose everything. And you may face the same situation if you decide you don't want to use them any more.
I'd say to use encrypted connections or logons, hope that as a vulnerability in particular encryption scheme is discovered it gets removed from your applications and services. Use good, different, and unrelated, passwords for every service.
It's probably going to be the easiest thing to do, too. Other authentication schemes are obscure. With little use or useful help.
The problem that motivated this thread seems to have (magically!) disappeared. Perhaps the problem was on the verizon-yahoo end.
I use Thunderbird almost exclusively (>99%) for my e-mail. All accounts are set to "SSL/TLS" and "Normal password". If I understand Tim and Rick correctly, authentication is already encrypted, but the messages themselves are not (or does SSL/TLS also apply to the messages being passed between yahoo and me?). So, these are the best settings for my situation. Encryption of messages would be great, but with multiple accounts and I-don't-know-how-many-correspondents, that seems like a logistical nightmare.
So I consider this issue SOLVED. Thank-you Rick and Tim.
I'm curious: in the HyperKitty version of this list, if I click "Sign In", I get a page with 10 choices of ways to log in. Is this (9 of those 10 choices) an example of OAuth2?
Happy New Year everyone!
On 12/28/18 12:43 PM, home user via users wrote:
The problem that motivated this thread seems to have (magically!) disappeared. Perhaps the problem was on the verizon-yahoo end.
I use Thunderbird almost exclusively (>99%) for my e-mail. All accounts are set to "SSL/TLS" and "Normal password". If I understand Tim and Rick correctly, authentication is already encrypted, but the messages themselves are not (or does SSL/TLS also apply to the messages being passed between yahoo and me?). So, these are the best settings for my situation. Encryption of messages would be great, but with multiple accounts and I-don't-know-how-many-correspondents, that seems like a logistical nightmare.
The _connection_ is SSL-encrypted, so anything going over that link is SSL-encrypted (including your username/password). You could use an encrypted password (if your provider supports it), but it's sorta redundant in this case. If you were using no encryption on the connection, THEN you'd probably want an encrypted password, but the mail itself wouldn't be encrypted.
Note that the encryption only covers the transport over the Internet between your machine and the server. The content of the mail is not stored encrypted once it hits the server or your machine. If you want the _content_ encrypted as well, you'd need to GPG-encrypt it and share your public key with the recipient so they could decode it.
So I consider this issue SOLVED. Thank-you Rick and Tim.
You're welcome.
I'm curious: in the HyperKitty version of this list, if I click "Sign In", I get a page with 10 choices of ways to log in. Is this (9 of those 10 choices) an example of OAuth2?
If you mean the buttons at the top (Fedora, Google, Twitter, GitLab, etc.), yes, that's OAuth2 stuff which permits you to use your account on one of those systems to authenticate.
Happy New Year everyone!
You too, buddy! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Diplomacy: The art of saying "Nice doggy!" until you can find a - - big enough rock. - ----------------------------------------------------------------------
On Fri, 2018-12-28 at 13:43 -0700, home user via users wrote:
The problem that motivated this thread seems to have (magically!) disappeared. Perhaps the problem was on the verizon-yahoo end.
That does happen.
Also, if you've had a few unsuccessful connections, a server may lock you out for a prolonged time. Trying out a few different connection configuration options in a too short timespan may be enough to put you on the naughty list.
-
home user -
Rick Stevens -
Tim