Technical question about "app passwords"

Factual Questions
1

The reason for this question is the convoluted paradox of device-specific email app passwords being required for devices/applications that don’t support advanced authentication technologies like OAuth2, and simultaneously some providers first introducing the concept, and then abandoning it, recently causing all my Outlook-based email clients to suddenly stop working. There was no advance notice, and in fact even now, most of the support techs at the ISP are clueless about what’s going on. Email is being provided by Yahoo as a third-party service contracted by the ISP, so we’re dealing here with the combined incompetence of both the ISP and Yahoo.

This last bit of gross incompetence on the part of my cable ISP has resulted in some of the most egregious complications I have yet encountered in my dealings with these idiots, short of total outages – and believe me, I’ve had too.

They seem to be trying to drive their customers to using ONLY their web-based email, and not email client applications that they don’t control. For me, this is a major inconvenience, but for a friend who runs a busy and successful business from home, this is simply catastrophic and unacceptable. The idea that you should “use our webmail on your browser” is based on the simplistic notion that all that an email user ever does is check their email every couple of days, and maybe replies to one or two. NOT to someone who has tens of thousands of archived emails comprising some 100+ GB of storage that is organized and managed by a carefully configured local email client.

Fortunately, my friend is not in an emergency as she had the foresight to start using DNS forwarding from her business domain name, and a year or two ago switched the target to Gmail, which continues to work just fine.

Anyway, my point is that I am so incredibly pissed off at this sudden loss of a critical service and the absolute lack of either customer notification or even the most rudimentary information from customer support that I’m escalating this in a major way that will hopefully cause these idiots some grief and expedite a resolution. Specifically, aside from their useless “Office of the President” channel for internal voicing of complaints, I intend to document the circumstances to the ISP regulatory body in this country, the CRTC, which is more or less equivalent to the FCC in the US.

Well, that was a long preamble, but it’s the background to a couple of simple questions that I hope those more familiar with current internet security than I am might be able to answer.

  1. Why were “device-specific” (or “app-specific”) passwords introduced in the first place? I can see how having a separate password for one specific device might be considered more secure than having just one password for general login to your email account from anywhere, because maybe you’d be using your primary password less often, but that’s contradicted by the fact that they want you to use their webmail, which requires logging in with the primary password every single time!

  2. If device-specific passwords have some security vulnerability, why does Gmail continue to use them? The access rights only have to be confirmed once through two-factor authentication, and then you’re good to go with regular logins (using the app password) indefinitely.

Again, I’m trying to make the case to regulatory authorities that this is a case of gross icompetence and utter contempt for the customer. Any technical insights would be appreciated.

2

Google wants you to use 2-factor authentication. But that requires going through their services: namely, GMail. But they recognized that some people still use Thunderbird and other clients, and wanted something at least a little better than standard user-generated passwords for those clients, even if it wasn’t as good as 2FA. Hence, app-specific passwords. These limit the damage from an unintentional leak from an unrelated service, and Google can enforce their own strength requirements (hence why they’re long, random strings).

So in order from best to worst:

  1. User password + authenticator app (i.e., 2FA). User passwords are weak but the 2FA makes up for it. Something you know + something you have.
  2. App-specific passwords. Has some advantages of 2FA since you need to login to Google to even generate them. Long and impossible to brute-force. But with the disadvantage that if they are captured, they’re no better than a standard password. But hopefully you just enter them once on your local app.
  3. Normal user passwords. Easy to brute force, because users are dumb. Avoid if at all possible.
3

At the risk of a very dumb question, what the hell is an “app-specific password” or “device-specific password” in this context? It smells like the OP body is all about something device-specific, but the title is talking about “app-specific”.

As a general matter, most phone / tablet apps are effectively little more than single-purpose browsers locked to accessing a single DNS name. So the password for that service is app-specific no less than your password to Bank A’s website is specific to Bank A and your password to your other bank B’s website is likewise specific to bank B.

Or is the OP using “app” in it’s older more generic form of any executable program?

Whatever problem the OP (or friend) is having, I’ve never encountered it. Yet. So I have no context to even think about what we’re trying to talk about.

4

If you provide a service, like email, and you don’t trust either:

  1. the application the user is using to connect to your service
  2. or the device they are connecting from

You, the service provider, can deny their login attempts with their normal password and instead require them to use a special password that you create for them.

As @Dr.Strangelove said the benefits are:

  1. They have to login in once using the complete credentials and any extra security that entails.
  2. The service provider gets to create the actual password and they pick a good one.
  3. If the application or device leak this password the damage is limited.

If you are a multi-service provider like, Google, it limits the damage of the leaked password to one app on one device.

5

Thank you.

Funny how Google and Facebook and Microsoft clamored desperately to be your one and only universal online identity able to log into everything, then now they realize that that is a really bad idea given the reality of their user base. And the reality of the “keys to the kingdom” aggregation of authentication and therefore risk.

6

Not a dumb question at all, and the fault is mine for assuming that more people were familiar with this fiasco, which initially affected Gmail users and is now affecting my primary ISP email even more severely.

The problem ultimately arises because email providers like Gmail, Yahoo, and ISP email systems are notoriously paranoid about security. Why they care so much I have no idea – maybe they’re worried about liability implications – but they are definitely paranoid as all hell. The “proper” solution to this problem is to stop logging in with a password and use the OAuth 2 authorization protocol, which to the best of my understanding introduces a trusted entity called an authorization server which mediates between the client and the protected resource and grants access via access tokens. Whenever you try to access a resource that requires you to log in, and you see options like “log in with Google” or “log in with Facebook” or whatever, this uses the OAuth protocol with something like Google acting as the authorization server.

So what’s the problem? The problem is that this is all fine and dandy for accessing websites and the like, but when accessing email servers, a great many legacy email clients do NOT support OAuth. The biggest culprit is Microsoft Outlook, which did not incorporate support for OAuth 2 until quite recently. The obvious answer, “so upgrade”, is much easier said than done. This is taking us a bit off topic but upgrading an email client like Outlook starts creating a massive cascade of problems: the new versions will only run on the latest versions of Windows, and the latest version of Windows will only run on fairly recent hardware … you see where this is going. The simple fact that email providers no longer trust password logins essentially amounts to the legacy user – in my case perfectly happy until last Monday afternoon – having to throw their entire computer out the window and buy a new one and set up all new software, a process that can take months.

Even self-serving corporatocracy recognized this to be a problem, and so email providers introduced the concept of the “app password”. “App password” and “device password” mean the same thing, sorry for the confusion. Here is the description of how it works with Gmail.. The “device” to which an app password is assigned can be designated as “Windows email client” or “Android phone” or things of that nature.

It was never clear to me how this secondary password actually enhanced security, since it’s just a password, nor why password logins were ever a problem, since for a long time now all incoming and outgoing email connections were SSL encrypted. @Dr.Strangelove provided some info as to why providers would consider them more secure.

So that’s the background, and I was just trying to gain some insight into these various new security protocols, and trying to understand if there was some reason other than gross incompetence that my ISP’s email would suddenly discontinue and disable app passwords while super-security-conscious Google Gmail still uses them.

Yes, you just enter them once on the local app, so a keyboard logger isn’t going to capture it after that, but it’s transmitted each and every time you access the email server. I have Outlook set up to check email every five minutes, and it logs in each and every time. I was concerned when Gmail stated (per the link above) that using app passwords required two-factor authentication (2FA) to be turned on, but it only uses 2FA when generating an app password for a new device for the first time.

JFC, this is probably the root cause of all my problems, yet it’s so easily solved by establishing and enforcing standards for password length and complexity.

7

30 years in IT and I can tell you “some users are stupid, so are some IT requirements”. If I tell a user they have to change passwords every 90 days, damn right the password is getting changed from “MyDogsName1” to “MyDogsName2”.

Monitoring logins for my company, I can control device, geography, travel time between login locations, MFA, and many other factors to limit bad actors. Sometimes it doesn’t work and I have to intervene.

8

I think you may have thrown some light on a problem I had a couple of weeks (approximately) ago. Frontier email via Yahoo was refusing to let my email program connect and download mail. I could most of the time still get at my email via the webmail site. I hate the webmail site, which isn’t configured remotely the way I want it; plus which my internet connection’s very slow and sometimes nonexistent, so I want my email in my computer where I can get at the info in it even if the connection’s not working; not to mention that yes this includes some 20 years of business and town planning board as well as personal stuff and I want it under my control.

At one point briefly, in the middle of a weekend, the webmail wouldn’t work either.

But all of this was intermittent, and I kept thinking it might have fixed itself and I wouldn’t need to spend who knows how long trying to get on the phone with Frontier and then probably trying to deal with somebody who had no idea what was going on and/or didn’t speak Mac; plus which I needed to clear time in a day to do that. Just before I would have finally given up and done so, the problem did fix itself; and hasn’t recurred.

So as you say they introduced this without warning or information and then abandoned it – maybe that’s what was going on.

9

I’m not sure I quite understand. Are you complaining your ISP email does not support OAuth2, or that it only supports OAuth2?

Thunderbird supports oauth2, so that is potentially on option if people can’t upgrade to the newest Outlook. The big issue with wanting to stay static, is that security is a process, not a destination. Maintaining security can mean an evolving list of requirements, and inevitable obsolescence of old programs and methods.

Obviously this can be handled well or poorly, and even when handled well will annoy some users. When handled poorly it can be a disaster.

The way many things are setup, email is the golden access card, and people should be extremely concerned about how well it is protected. Access to someone’s email may allow resetting of passwords for lots of places, like banks. If you have access to someone’s email and SMS, you can probably access any of their online accounts.

I think the ability to revoke app passwords is the key feature. There’s no way for the provider to know how well or poorly some random email client or other stores passwords. Clear text in a world readable file is probably scarily common.

I doubt many users revoke app specific passwords, but at least it is an option. Occasionally on service I use that have them I’ll go through and clear them out for old phones or whatever.

Beyond the ability to revoke is the ability to be backwards compatible with things that can’t use oath2.

10

Two of the top recommendations for good password hygiene is to use unique passwords and to make them complex. By assigning you the password they are forcing both.

I don’t think the primary concern is that the password will leak when used to login, but will be leaked by an untrusted or unreliable app. Maybe Outlook is reliable, but Cletus Mail is not.

11

That doesn’t fully solve the problem. Even with strict requirements, users will reuse their passwords, and if they leak from some crappy site, then hackers will try them on more important sites, like email.

echoreply made another good point that app passwords are revokable. Really, they aren’t much different from OAuth2-like systems. You generate a secure token and then plug the token into the client app. Once done, the two programs are considered to be securely linked. The token can be revoked if there’s been some kind of breach.

12

The latter. I’m complaining that, without any prior notification, they disabled the workaround for those email clients that didn’t support OAuth2, which is quite a large number of them, in my experience, including all but the very latest versions of Outlook.

Yes, thank you, I’m aware that Thunderbird supports OAuth2, and this may indeed be my best hope. But I’ve been using Outlook since at least the days of Windows 9x, I’m very familiar with it, and I have a vast repository of emails going back decades. For me, switching to a client like Thunderbird may be a viable option despite being a major change and major nuisance. But for my friend running a business for which Outlook is the major organizational tool and essentially the business database, this would be a catastrophe if Gmail ever went the same way. She is also a subscriber to the same cable ISP – Rogers Communications – but recognized long ago that Rogers/Yahoo was a bunch of, well, yahoos, and notoriously unreliable both in service levels and customer support, so never uses it any more and is strictly on Gmail. Which itself is a travesty as we are all paying for the contracted Yahoo outsourcing, yet the free Gmail service is far better.

Which does not, however, offer any kind of explanation for why app passwords were irresponsibly and without notice discontinued. They seem like a fine compromise for legacy systems. I’m perfectly willing to live with them. But I have since discovered, on researching this bloody fiasco, that the Rogers email management site no longer supports the creation of any app passwords for anything, and furthermore that this was disabled nearly ten months ago, and that they’ve gradually, over time, been revoking the app passwords already created – without telling customers about any of this! And their CSRs still don’t know what’s going on. It tells you how much they value their customers (and, by extension, how much they value backward compatibility) – which would be somewhere beneath their valuation of the dog shit in their back yard.

13

Yes–that I have no explanation for beyond incompetence. But from everything I’ve heard about Rogers, they’re about as competent as Comcast is here in the US, which is to say I wouldn’t trust them to pour piss out of a boot when the instructions are on the heel.

14

This is exactly correct! :laughing:

15
  1. Rogers sucks and Yahoo Mail sucks more. I tried to get my parents off Rogers email years ago, no luck.
  2. Outlook works just fine with it using OAuth, as does Apple’s mail client. I don’t think I’ve had to create a Rogers App password for at least 3 years.
  3. Rogers still sucks.
16

Only the most recent versions of Outlook support OAuth 2.0, and specifically only Office 2021 or later or Office 365 support it, and only when using IMAP, not POP3. (This is yet another artificial restriction, this time from Microsoft – there is no reason that an email client can’t support OAuth2 with POP3. Thunderbird supports it just fine.)

This fiasco is why app passwords were created in the first place. Now, due to some machinations by Rogers and Yahoo, app passwords can no longer be created and are being systematically revoked. Unbeknownst to me previously, this revocation has been going on for months. My Outlook account stopped working last Monday (others lost their email access months ago); email on my phone still works but I expect it will stop working soon. (My phone does support OAuth2 but I initially configured it a couple of years ago with an app password.)

If you log in to your Rogers account where you can manage your email accounts, you’ll find that if you try to create an app password, it will tell you that “app password generation is currently not available”. They also fail to mention that the existing ones are being revoked. But for extra fun, you can check their help files where they tell you that the solution to all your email client access problems is to generate an app password! :grimacing:

17

See my point 3 :smile:

I spent an hour trying to get my mother’s Rogers home phone forwarded to her cell using the online manager. Kept getting 404 errors. Chat support told me to reboot my modem.

I’m on Bell fibre and while Bell customer support is equally crap at the least their product rarely requires support.

18

I don’t have anything to add to the technical discussion, but I wanted to announce that I’m stealing this for future meetings.

19

FYI for the curious – I just tried the latest version of Thunderbird, and I am now thoroughly perplexed and befuddled. It works, but it’s totally beyond me how or why it works. The only credentials I gave it – which was all it asked for – was the primary login password for my Rogers/Yahoo account – that’s it – nothing about Google or any other authorization server. But for years now that password is only supposed to be for access to the website to manage my email accounts, not for POP3 access by an email client – that’s why app passwords were created in the first place. Needless to say, that primary password does NOT work in Outlook, and neither does the (now revoked) app password.

How the hell is Thunderbird successfully accessing my email, armed only with that one useless password? I obviously don’t understand how OAuth2 actually works.

Anyway, my woes are very far from over. There is apparently a major bug in Thunderbird wherein it cannot import emails, calendars, and contacts from Outlook, despite having that feature, but that’s a whole other issue that is off-topic here.

20

It sounds like Rogers’ actual goal is to drive most of its email users to some other platform such as GMail or Live, so they can completely discontinue email service.

That form of passive aggressive customer herding abuse is real common in big business thinking.