Hacker News Reader

Comment by jeroenhd | Hacker News Reader

Oauth isn't that hard to implement. It requires a WebView as part of the setup process, but after that the mail app just needs to store a token as a password and it'll keep working.

Oauth for email is part of the various RFCs pertaining to email authentication and has been around for years.

Thunderbird and various mobile apps support Gmail just fine using Oauth. I think the bigger problem is that many desktop apps seem to have stopped implementing changes to IMAP and SMTP about ten years ago.

If you have an email app that's no longer maintained, use app passwords (generated per-app passwords), like Google is indicating in the linked article. Those will still work. It's just the hardcoded username/password for the main account that's going away.

This will be a major pain for the Office 2016 users, as 30 september is still about nine months before their Outlook goes out of support, but for most users this will be quite a easy fix.

View on HN

> It requires a WebView as part of the setup process

Why does it require a WebView, btw? Is there a good technical reason for that, or is it just what they happened to do?

They want the power to add arbitrary extra steps in the login flow.

For example, maybe they want to force the user to change a compromised password, or hand over their phone number, or complete a captcha, or accept a load of legalese.

You can do this without a webview in your application, but it usually means giving the user an URL to open in their own browser.

Doesn't google explicitly forbid a WebView for oauth?

The point is to not have users entering their google credentials into third-party apps, and a WebView is still entering your credentials into a third-party app. The app has to open the google login page in a real browser, not a WebView.

Oh, I see. BTW don't hardware keys (e.g. Yubikey) solve that problem entirely?

No.

Hardware keys are a second factor. But if you allow passwords to be compromised just because there is a second factor, then you're back down to one-factor auth and you've solved nothing

Fido keys can also be used without password or even an account name (but with pin which becomes the second factor in that scenario). They are very resistant to phishing because they do a challenge response every time that's bound to the domain name of the requesting site. So typosquatting tricks won't work. The private key is generated and stored in the token and they are very resistant to extraction.

In general it's way safer than a password that can be intercepted and reused by anyone who knows it.

but we're talking about google's implementation here, where fido keys are only a second factor. and in google's implementation, allowing passwords to be compromised means compromising your security, because their authentication flow is based around having more than just one factor.

Well. Hardware keys are just hardware keys. They can be used as a second factor, they can be used as a third factor, they can be used as the only factor. It's not immediately obvious that using only a password is less secure than using only a hardware key.

Don't passkey's just use the hardware key as the only factor (or at least that's how I've seen it implemented)?

I would say that if you use your fingerprint to unlock the hardware key on your smartphone, then you have two factors: one needs to both steal your smartphone (for the hardware key) and copy your fingerprint.

Or am I missing something here?

Passkey's don't strictly require 2FA sources.

Some hardware keys like yubikey's generally only prove physical presence of the key. And software implementations exist too.

I suppose it technically doesn't require a WebViee, but that's the easiest solution in most cases.

I'm not sure how you're going to implement Google's 2FA in a non-WebView solution, but if you can get the right UI and data flows to work, I'm sure you can do without.

> Why does it require a WebView, btw?

So you can't read your mail from a platform that doesn't have a web browser installed...

Edit: to be more clear: so you can't read your mail from a platform that can't run or embed a modern web browser. For example... a command line only system without a GUI.

App passwords still work. There's no need to be hyperbolic.

... for how long?

Sure you can, you just have to complete the OAuth2 login on a different device (e.g. phone) and then forward the token to the device which has no web browser.

On the phone itself the WebView limitation is worked around via deep linking (start Browser from App and once logged in start App from Browser with token).

There are tons of different ways how to do this actively being used.

What's the point of an app password?

It's a long, random password, that you generate anew for each application that needs it: one compromised app can be revoke quickly without affecting other.

But more importantly, app password can only be used for email, not other Google's service, so even if it gets leaked, the impact is severely reduced.

Your account password is too powerful, for example, it allows anyone who knows it and can provide the 2FA to change non-email settings, such as the preferred languages, the list of bank cards attached to the account, see the places visited, read and modify Google docs, or change the password. The app-specific password has a scope attached to it, and can thus be used only to do what the app needs to do, without any possibility to take your entire account over.

It's a password that allows access to email, but not to the "change my Google password" page, or to push app installation to the Play Store, or to invite other people into Google Meet links. These passwords are contained to very specific APIs surrounding email and Caldav and such.

That means you're not completely screwed when your Outlook password database gets stolen by malware.

As a user, it also allows you to revoke an application remotely without having to change your password and log in to every device again. One click of a button and new emails won't appear on a lost laptop or phone, even if they manage to bypass the screen lock. It's all about risk management.

Reply on news.ycombinator.com