Allowing less secure apps to access your account
Google may block sign in attempts from some apps or devices that do not use modern security standards. Since these apps and devices are easier to break into, blocking them helps keep your account safer.
Some examples of apps that do not support the latest security standards include:
... Some Desktop mail clients like Microsoft Outlook and Mozilla Thunderbird
Therefore "Goozilla" considers Mozilla Thunderbird as less secure!? Really "Goozilla"?
Allegedly, on or about 05 February 2015, poma sent:
Therefore "Goozilla" considers Mozilla Thunderbird as less secure!? Really "Goozilla"?
This rather depends on *why* you're encountering this. A great many applications logon to servers by sending your username and password, unencrypted. Anyone else on the same network can see them. By refusing unencrypted plain text logons, the server will be stopping your application before it sends out the password. However, some dumb implementations of this protection don't interrupt the logon process, and fail you after the password has already been sent out, in the clear.
This issue has been around since the internet sprang into existence, yet even now it's a pain to get encrypted logons working, as little effort has been put into standardising them. There's a plethora of different ways to do it, none of which can be considered a default, and not all methods will be supported on either side.
You do see, now, some applications attempting to do a secure logon as the first thing, instead, then falling back to other methods.
On 06.02.2015 01:35, Tim wrote:
Allegedly, on or about 05 February 2015, poma sent:
Therefore "Goozilla" considers Mozilla Thunderbird as less secure!? Really "Goozilla"?
This rather depends on *why* you're encountering this. A great many applications logon to servers by sending your username and password, unencrypted. Anyone else on the same network can see them. By refusing unencrypted plain text logons, the server will be stopping your application before it sends out the password. However, some dumb implementations of this protection don't interrupt the logon process, and fail you after the password has already been sent out, in the clear.
This issue has been around since the internet sprang into existence, yet even now it's a pain to get encrypted logons working, as little effort has been put into standardising them. There's a plethora of different ways to do it, none of which can be considered a default, and not all methods will be supported on either side.
You do see, now, some applications attempting to do a secure logon as the first thing, instead, then falling back to other methods.
Send Message Error
Sending of message failed. The SMTP server smtp.gmail.com does not seem to support encrypted passwords. If you just set up this account, please try changing to 'Normal password' as the 'Authentication method' in the 'Account Settings | Server settings'. If it used to work and now suddenly fails, please contact your email administrator or provider.
$ dbus-monitor type=method_call | grep IMAP -B1 string "Thunderbird" string "The IMAP server <Account Name> does not seem to support encrypted passwords. If you just set up this account, please try changing to 'Normal password' as the 'Authentication method' in the 'Account Settings | Server settings'. If it used to work and now suddenly fails, please contact your email administrator or provider."
Am 06.02.2015 um 05:31 schrieb poma:
Send Message Error
Sending of message failed. The SMTP server smtp.gmail.com does not seem to support encrypted passwords. If you just set up this account, please try changing to 'Normal password' as the 'Authentication method' in the 'Account Settings | Server settings'. If it used to work and now suddenly fails, please contact your email administrator or provider.
AFAICT, what recent Thunderbird versions call "encrypted password" does mean that some challenge-response authentication mechanism (like CRAM-MD5) is used, so that the client can prove to the server that it really knows the correct password, without sending it in plain text. These mechanisms were useful, when no encrypted connection to the server was available. BUT, if you use a TLS-secured communication channel to the server (as you should!), the use of challenge-response mechanisms is pointless (and not supported by gmail), since the communication is already encrypted. Therefore, choosing "Normal password" is the way to go.
On 06.02.2015 11:56, Markus Schönhaber wrote:
Am 06.02.2015 um 05:31 schrieb poma:
Send Message Error
Sending of message failed. The SMTP server smtp.gmail.com does not seem to support encrypted passwords. If you just set up this account, please try changing to 'Normal password' as the 'Authentication method' in the 'Account Settings | Server settings'. If it used to work and now suddenly fails, please contact your email administrator or provider.
AFAICT, what recent Thunderbird versions call "encrypted password" does mean that some challenge-response authentication mechanism (like CRAM-MD5) is used, so that the client can prove to the server that it really knows the correct password, without sending it in plain text. These mechanisms were useful, when no encrypted connection to the server was available. BUT, if you use a TLS-secured communication channel to the server (as you should!), the use of challenge-response mechanisms is pointless (and not supported by gmail), since the communication is already encrypted. Therefore, choosing "Normal password" is the way to go.
I followed up on what Tim wrote. ;)
OK read it for yourself what it's all about: Log in to Google Talk (XMPP) and Gmail (IMAP/SMTP) using OAuth https://bugzilla.mozilla.org/show_bug.cgi?id=849540
On 07.02.2015 00:15, poma wrote:
On 06.02.2015 11:56, Markus Schönhaber wrote:
Am 06.02.2015 um 05:31 schrieb poma:
Send Message Error
Sending of message failed. The SMTP server smtp.gmail.com does not seem to support encrypted passwords. If you just set up this account, please try changing to 'Normal password' as the 'Authentication method' in the 'Account Settings | Server settings'. If it used to work and now suddenly fails, please contact your email administrator or provider.
AFAICT, what recent Thunderbird versions call "encrypted password" does mean that some challenge-response authentication mechanism (like CRAM-MD5) is used, so that the client can prove to the server that it really knows the correct password, without sending it in plain text. These mechanisms were useful, when no encrypted connection to the server was available. BUT, if you use a TLS-secured communication channel to the server (as you should!), the use of challenge-response mechanisms is pointless (and not supported by gmail), since the communication is already encrypted. Therefore, choosing "Normal password" is the way to go.
I followed up on what Tim wrote. ;)
OK read it for yourself what it's all about: Log in to Google Talk (XMPP) and Gmail (IMAP/SMTP) using OAuth https://bugzilla.mozilla.org/show_bug.cgi?id=849540
Tim, Markus care to comment? :)
poma:
OK read it for yourself what it's all about: Log in to Google Talk (XMPP) and Gmail (IMAP/SMTP) using OAuth https://bugzilla.mozilla.org/show_bug.cgi?id=849540
poma:
Tim, Markus care to comment? :)
My eyes glazed over less than half way through that page. Pithy comments aside, I have, by then, forgotten what the hell the most of that page was trying to discuss.
I shall diverge, and relate a tale about Yahoo mail. Some time ago Yahoo changed something so that if you wanted to send a message to a group managed by Yahoo (their name for one of their mailing lists, as if it were a newsgroup), and send it from a Yahoo address (like I'm doing right now), you had to send it through their own SMTP server, not your own (or your ISPs), and their SMTP server requires you to log in. Hence, emails sent to their group are authenticated (albeit poorly). Alternatively, you could post to the group from some other email address that gets (similarly) authenticated by whatever other SMTP server you post through (I had no SMTP server available to me that has that log-in before sending feature), so that you're not a completely anonymous spammer, just semi-anon... All it wanted was an SMTP server to say johndoe@example.com is known to example.com, there's nothing further to say that example.com has actually verified whomever claims to be johndoe.
Previously, you could enter any email address in the "from" field (as long as it had been previously signed up to the mailing list), and send through any SMTP server.
They made /that/ change as an anti-spam effort (which has failed, by the way, spam still gets though), rather than tighten up their "join the group" mechanism to make it a real nuisance for hit and run spammers. However, it falls apart in numerous places:
Firstly, spammers still get spam through.
Secondly, not everyone has an SMTP server that authenticates them before allowing mail to go through. Whether that be their usual SMTP server doesn't do it, or a lack of access to any server that they can find.
Thirdly, for me to set Yahoo as my SMTP server for that posting address required me to, also, connect to it using a "secure" method. But which secure method? I'm using Evolution, and I had to go through an annoying trial and error poke-it-and-see try out of different combinations of things before I got one that worked. Then months later they changed something, and I had to go through that mess again.
There are three different TCP/IP ports that I could try, 25 is the old unencrypted one, so it ought to be either 465 or 587. Then there was the security technique, no encryption (doesn't seem the right choice,) or STARTTLS after connecting, or SSL on a dedicated port. Then there was six different authentication types (PLAIN, NTLM/SPA, GSSAPI, DIGEST MD5, CRAM MD5, Login, and POP before SMTP). And, although, there's a test button next to it, to help narrow it down by crossing out types that the server doesn't support, that function doesn't always work.
Much of that stuff I'd never used or heard of, just about all of it is completely foreign to a typical computer user, much of it is named differently than the peculiar error message you get back from Yahoo when your post fails to be accepted, likewise with trying to read through Yahoo's help pages.
It's an utter nightmare. There is no tick box to "make it secure" and have it just work, because there's a plethora of wildly different and inappropriate options. There's a plethora of different help pages, because each mail client is different, and you're screwed if they don't have a help page for your client. It's well past the days where a service provider can simply tell you SMTP and POP/IMAP addresses, and leave you to find the places for them in your client, and you'd be able to work that out for yourself, because you only had three standard things to look for. Now you've got to look for some feature that's named differently on different clients and services, despite being the same thing, or you've got to sort through different security choices between the server and yourself, to find ones that are supported by both sides.
Back to google/gmail... When I tried them out, long ago, you could log into their web interface, using a familiar process of providing your email address and a password. Years of prior experience of various web and mail services has been that if you wanted to use an email client, instead of a web browser, you'd simply use that same email address and password, and fill in the mail server addresses, and you were done. But google doesn't want that, because mail clients typically send out the password in the clear. Their approach, instead of fighting with a gazillion security options in the client config, was to make you get an extra different password for your account, put that into your email program, and run the lesser risk (in their opinion) of losing a password that would only let you read mail, keeping the other password that lets you do things with your account, separate (of course, if the user sends out the wrong [master] password in their mail logon attempt, snoopers have grabbed it anyway). There's some logic in having two passwords, but it's a still a pain for people to deal with, just a *different* kind of bastard. And they extend it further, with google recognising different clients as you try to connect to your google account and requiring you set up individual passwords for each different client you use (because your google account gives you a mail service, and an instant messaging service, on the same account, but with different passwords).
Of course you're still screwed if you get one of those secondary passwords captured by nefarious types, even if you're only partially screwed. So some services offer the two-step logon, where you log on in the way that you'd normally expect, but before you can continue, you have to authenticate with something completely separate, as well. Such as, as you connect up, you're SMSed a one-time password to enter, as well. Or, you need to visit some webpage, before you can email. (I think this is the kind of issue that long-winded bugzilla link is about.)
Now you've got a new nuisance to contend with: You've got to have some alternative option to your initial need available, and you've got to have it with you at the time. So much for nipping down to the library to use their computers to email something, if your phone is at home.
And a new security flaw to deal with: Steal my phone, try to log in to my mail, and it fails because you don't know my password, click the "I've forgotten my password" link, and the stupid service uses my mobile phone to confirm something, and now you're into my mail. Or, steal my phone and throw it away, and I've been locked out of my mail. Or, for some reason I have to change my phone number, I get locked out of things.
Security is flawed. Many security practices have stupid holes in them, many of them have been known about for many years, yet are still being employed (even on new things). And many practices are really annoying to have to deal with.
I hate those "enter your mother's maiden name, pet's name," etc., security questions. Much of the time, what they ask is information easily available to other people. There's the personal option about providing bogus information, but you've got to write that down to remember it. And whatever you typed in it the first time around, you have to be able to retype the answer verbatim.
On Tue, 2015-02-10 at 00:27 +1030, Tim wrote:
And a new security flaw to deal with: Steal my phone, try to log in to my mail, and it fails because you don't know my password, click the "I've forgotten my password" link, and the stupid service uses my mobile phone to confirm something, and now you're into my mail. Or, steal my phone and throw it away, and I've been locked out of my mail. Or, for some reason I have to change my phone number, I get locked out of things.
I'm afraid my eyes also glazed over reading your very long post Tim, but just to cherry-pick this specific point: Gmail 2FA allows you to print a list of 10 authentication codes for use in case you lose your phone or change the number (and of course changing the number just means registering the new one when logged in). You can of course also lock your phone and disable it remotely. It may not be perfect but it's a long way better than any practical large-scale alternative anyone has thought of so far. There is no magic bullet for security.
poc
On Mon, 2015-02-09 at 16:44 +0000, Patrick O'Callaghan wrote:
I'm afraid my eyes also glazed over reading your very long post Tim,
I kind of did that on purpose, since pomo referrred me to a ridiculously long thread and asked me to comment on it. Hopefully his eyes ran out of breath, too. :-\
but just to cherry-pick this specific point: Gmail 2FA allows you to print a list of 10 authentication codes for use in case you lose your phone or change the number (and of course changing the number just means registering the new one when logged in).
While that's good to know, my objections to things like that aren't just about Google. Other systems do some annoying authentication routines, and it's going to be a real pain having to deal with yet more schemes, each different.
You can of course also lock your phone and disable it remotely. It may not be perfect but it's a long way better than any practical large-scale alternative anyone has thought of so far.
While I can set my simple phone to lock the keypad, that is a nuisance I'd rather not do. And I have no way to remote lock it. I have a barebones phone, not a smart phone.
A lot of these attempts at security make a number of presumptions about people. My objections are mostly technical. The average internet user just is not going to comprehend them, at all. Mind you, though, they'll probably just do everything through a web browser (email, IM, stalkbook, I mean facebook), and be unaware that there was any other way of doing it, and completely unaware that email is not hotmail or yahoo.
There is no magic bullet for security.
I said something similar, in my huge post, too.
On Wed, 2015-02-11 at 00:07 +1030, Tim wrote:
but just to cherry-pick this specific point: Gmail 2FA allows you to print a list of 10 authentication codes for use in case you lose
your
phone or change the number (and of course changing the number just means registering the new one when logged in).
While that's good to know, my objections to things like that aren't just about Google. Other systems do some annoying authentication routines, and it's going to be a real pain having to deal with yet more schemes, each different.
Several attempts have been made to unify authentication system (OpenAuth being one). They all have problems. A recent one that looks very interesting is a proposal from IBM (https://idemixdemo.mybluemix.net/). Unfortunately it means entrusting your security to a central authority. The trade-off is that services needing authentication only get to see the minimum information they need to make a decision.
poc
poma:
OK read it for yourself what it's all about: Log in to Google Talk (XMPP) and Gmail (IMAP/SMTP) using OAuth https://bugzilla.mozilla.org/show_bug.cgi?id=849540
& poma, again:
Tim, Markus care to comment? :)
My eyes glazed over less than half way through that page. Pithy comments aside, I have, by then, forgotten what the hell the most of that page was trying to discuss.
I shall diverge, and relate a tale about Yahoo mail. Some time ago Yahoo changed something so that if you wanted to send a message to a group managed by Yahoo (their name for one of their mailing lists, as if it were a newsgroup), and send it from a Yahoo address (like I'm doing right now), you had to send it through their own SMTP server, not your own (or your ISPs), and their SMTP server requires you to log in. Hence, emails sent to their group are authenticated (albeit poorly). Alternatively, you could post to the group from some other email address that gets (similarly) authenticated by whatever other SMTP server you post through (I had no SMTP server available to me that has that log-in before sending feature), so that you're not a completely anonymous spammer, just semi-anon... All it wanted was an SMTP server to say johndoe@example.com is known to example.com, there's nothing further to say that example.com has actually verified whomever claims to be johndoe.
Previously, you could enter any email address in the "from" field (as long as it had been previously signed up to the mailing list), and send through any SMTP server.
They made /that/ change as an anti-spam effort (which has failed, by the way, spam still gets though), rather than tighten up their "join the group" mechanism to make it a real nuisance for hit and run spammers. However, it falls apart in numerous places:
Firstly, spammers still get spam through.
Secondly, not everyone has an SMTP server that authenticates them before allowing mail to go through. Whether that be their usual SMTP server doesn't do it, or a lack of access to any server that they can find.
Thirdly, for me to set Yahoo as my SMTP server for that posting address required me to, also, connect to it using a "secure" method. But which secure method? I'm using Evolution, and I had to go through an annoying trial and error poke-it-and-see try out of different combinations of things before I got one that worked. Then months later they changed something, and I had to go through that mess again.
There are three different TCP/IP ports that I could try, 25 is the old unencrypted one, so it ought to be either 465 or 587. Then there was the security technique, no encryption (doesn't seem the right choice,) or STARTTLS after connecting, or SSL on a dedicated port. Then there was six different authentication types (PLAIN, NTLM/SPA, GSSAPI, DIGEST MD5, CRAM MD5, Login, and POP before SMTP). And, although, there's a test button next to it, to help narrow it down by crossing out types that the server doesn't support, that function doesn't always work.
Much of that stuff I'd never used or heard of, just about all of it is completely foreign to a typical computer user, much of it is named differently than the peculiar error message you get back from Yahoo when your post fails to be accepted, likewise with trying to read through Yahoo's help pages.
It's an utter nightmare. There is no tick box to "make it secure" and have it just work, because there's a plethora of wildly different and inappropriate options. There's a plethora of different help pages, because each mail client is different, and you're screwed if they don't have a help page for your client. It's well past the days where a service provider can simply tell you SMTP and POP/IMAP addresses, and leave you to find the places for them in your client, and you'd be able to work that out for yourself, because you only had three standard things to look for. Now you've got to look for some feature that's named differently on different clients and services, despite being the same thing, or you've got to sort through different security choices between the server and yourself, to find ones that are supported by both sides.
Back to google/gmail... When I tried them out, long ago, you could log into their web interface, using a familiar process of providing your email address and a password. Years of prior experience of various web and mail services has been that if you wanted to use an email client, instead of a web browser, you'd simply use that same email address and password, and fill in the mail server addresses, and you were done. But google doesn't want that, because mail clients typically send out the password in the clear. Their approach, instead of fighting with a gazillion security options in the client config, was to make you get an extra different password for your account, put that into your email program, and run the lesser risk (in their opinion) of losing a password that would only let you read mail, keeping the other password that lets you do things with your account, separate (of course, if the user sends out the wrong [master] password in their mail logon attempt, snoopers have grabbed it anyway). There's some logic in having two passwords, but it's a still a pain for people to deal with, just a *different* kind of bastard. And they extend it further, with google recognising different clients as you try to connect to your google account and requiring you set up individual passwords for each different client you use (because your google account gives you a mail service, and an instant messaging service, on the same account, but with different passwords).
Of course you're still screwed if you get one of those secondary passwords captured by nefarious types, even if you're only partially screwed. So some services offer the two-step logon, where you log on in the way that you'd normally expect, but before you can continue, you have to authenticate with something completely separate, as well. Such as, as you connect up, you're SMSed a one-time password to enter, as well. Or, you need to visit some webpage, before you can email. Or, even if you're doing something on the web, you have to authenticate via a second webservice (such as the old Microsoft Passport debacle, I think this is the kind of issue that long-winded bugzilla link you provided is about), which offered central authentication for numerous services, and suddenly you find that you're unexpectedly logged in while browsing some third or forth website because they share authentication authorities, or you have users falling for the "enter your hotmail address and password" trick while they're browsing some completely unrelated website, and they do exactly what it says, instead of giving them an email address and a password for /this/ website.
Now you've got a new nuisance to contend with: You've got to have some alternative option to your initial need available, and you've got to have it with you at the time. So much for nipping down to the library to use their computers to email something, if your phone or password notebook is at home.
And a new security flaw to deal with: Steal my phone, try to log in to my mail, and it fails because you don't know my password, click the "I've forgotten my password" link, and the stupid service uses my mobile phone to confirm something, and now you're into my mail. Or, steal my phone and throw it away, and I've been locked out of my mail. Or, for some reason I have to change my phone number, I get locked out of things.
Security is flawed. Many security practices have stupid holes in them, many of them have been known about for many years, yet are still being employed (even on new things). And many practices are really annoying to have to deal with.
I hate those "enter your mother's maiden name, pet's name," etc., security questions. Much of the time, what they ask is information easily available to other people. There's the personal option about providing bogus information, but you've got to write that down to remember it. And whatever you typed in it the first time around, you have to be able to retype the answer verbatim.
-
Markus Schönhaber -
Patrick O'Callaghan -
poma -
Tim