Hacker News Reader

Comment by ltratt | Hacker News Reader

For those of us with Unix-y mail setups the move to OAuth2 can be a bit tricky, but there are now several different programs to help (spurred, I suspect in no small part, by Microsoft/Exchange's stance). The ones I know about are:

Email OAuth 2.0 Proxy <https://github.com/simonrob/email-oauth2-proxy>; mailctl <https://github.com/pdobsan/mailctl>; mutt_oauth2.py <https://gitlab.com/muttmua/mutt/-/blob/master/contrib/mutt_o...> (some suggestion that it might not always work these days?); pizauth <https://github.com/ltratt/pizauth>; oauth-helper-office-365 <https://github.com/ahrex/oauth-helper-office-365>. Disclaimer: I wrote pizauth and it's just about to move into the alpha stage.

View on HN

Not only it’s tricky and user-hostile, but it also severely decreases security by forcing people to use fundamentally insecure mechanism to obtain the authentication token.

God forbid you actually have functioning token rotation and revocation alongside 2FA. So insecure. /s

What does oauth have to tho with authentication (let alone 2FA)?

Besides being used for authentication?

https://learn.microsoft.com/en-us/exchange/client-developer/...

You can use 2FA with static password authentication. Remember the “password” here only means “character string”, it can easily carry an OTP.

Right, just as with XOAUTH2, the "password" sent to the server is actually the (encoded) OAuth token.

So what does it improve then, that would justify the incompatibility and added technological debt (dependencies)?

Well the question I responded to was "What does oauth have to tho with authentication".

I fully agree with the move away from plain passwords in this case, given that it's no longer "just" the password to a mail account, but to much, much more.

Now while I think OAuth adds some features that can be useful in certain settings, I'll be inclined to agree that requiring OAuth isn't the best move.

However the alternatives would probably require a lot of extra work on Microsoft's behalf, like being able to set up device-specific passwords or similar.

So, given the need to move away from plain account passwords, I can understand why they wouldn't want to do that and just use what they already had.

More like authorization. Authentication is completely opaque for most people using gmail. (except for those very few using service accounts and signing their own authorization tokens)

Or maybe you can enlighten me how you can get the token for XOAUTH2 from just your gmail email address and password without involving any opaque google service.

Authentication is happening completely outside of OAuth inside some google black box. 2FA has nothing to do with OAuth at all. It's just another feature of the google's black box which decides whether to give you the access/refresh tokens or not.

Could you expand on that? How is OAuth 2.0 fundamentally insecure in this setting?

It makes it necessary to use a browser to obtain the token. That browser is a huge attack surface. With web, it doesn’t matter, since you need to be using it anyway, but for mail it’s just additional cruft.

That's just for certain flows, like the common authorization code flow. The client credentials flow does not require a browser, for example.

Not sure about Google, but Microsoft supports client credentials for IMAP/POP3[1], but not for SMTP yet. IIRC it was supposed to be rolled out this January but is still missing. Hopefully they can get that deployed ASAP.

[1]: https://learn.microsoft.com/en-us/exchange/client-developer/...

Reply on news.ycombinator.com