Hi Brandon, password hijacking is a serious problem for everyone. That's why both MS365 and Google are deprecating basic auth...in their services only so far.
I might add that the OAUTH mechanism is better than application passwords due to the refresh mechanism, but not by much - it depends on the providers ability to detect token hijacking, which so far has proven to be as faulty as the good old login/plain mechanisms. : https://mrd0x.com/stealing-tokens-from-office-applications/ OAUTH helps with that, if a user is phished out of his password, the hacker will be faced with the 'New Device registration' page and he hopefully can't get past that, but if the hacker steals the token directly, we're back to square 1 pretty much. It's frustrating that both both MS & Google call LOGIN/PLAIN Insecure & old but do nothing to speed up the large-scale adoption of OAUTH, except for nudging users to move to their own services. I'm sure you know that Outlook has hardcoded OAUTH login through https://accounts.google.com/.well-known/openid-configuration but for no other provider. They probably did it either because of userbase size or through a direct deal with Google. [What if / when will] the Gmail app also decide to no longer support "Insecure auth" ? Both MS/Google have major interests to kill off their competition so what better way than to claim everyone is using insecure methods while only offering secure connections to their own servers through their client apps. That's what I meant by closing down the eco-system. So pretty much the original question remains: Why don't the popular client apps support 3rd party oauth implementations using the same mechanisms they use for themselves ? Cheers, Scott On Wednesday, 10/07/2024 at 02:36 Brandon Long wrote: On Tue, Jul 9, 2024 at 7:20 PM Scott Q. via mailop wrote: What exactly is missing for broad acceptance ? https://openid.net/specs/openid-connect-discovery-1_0.html defines some pretty clear ways to autodiscover the endpoints. MS & Google and Keycloak both offer this URL: https://login.microsoftonline.com/domain.com/.well-known/openid-configuration https://accounts.google.com/.well-known/openid-configuration I believe the latest Yahoo mobile app won't even connect to imap/smtp servers that don't have oauth2 support. It seems as if the big guys are closing down the eco-system... Or they have hundreds of millions of customers who routinely suffer from password hijacking attacks on a scale that's hard to imagine and regular password based login for smtp/imap has almost no mechanisms to use any of the advanced login behaviors that the eco-system has pushed, including 2FA, webauthn, and passkeys not to mention more advanced risk assessment and barriers to bots and hijacking attempts. Using OAUTHBEARER punts the actual login to the web (or OS built-in oauth login supports) to protect customers. I've seen arguments that some of these types of large scale attacks are only possible due to the large scale providers existence... or in some cases, the large scale attacks and responses still allow a lot of small stuff through and maybe a system with more providers of smaller sizes would suffer less... maybe it would mean a larger number of anti-hijacking folks spread across such an eco-system. Or maybe a more various set of defenses across a larger number of providers would make it more complicated for attackers to concentrate their attacks... I'm not sure that has proven true in the spam attack eco-system, though, so unclear that would work in the hijacking one. Another interesting case there would be APTs and high value targets, that number of attacks is much smaller and more targeted, so may only be up to larger systems to have the attack exposure necessary to justify spending on defense against it. Anyways, hijacking, the slow agonizing death of password based auth, and the solution for imap/smtp (that while open may be imperfectly so) certainly have legitimate justification, and tying that to "closing down the eco-system" seems odd... certainly other providers can still offer password based auth, and it seems more incumbent on them and the client folks to figure out discovery. Oh, and that's before you get the entire third party services thing where you don't want your users giving random services their password, oauth solve that problem... and then the client-id validation is used to try and solve the cambridge analytica / unroll.me [1] problem of problematic third party services. Honestly that issue is more of a problem for the open eco-system than the "big guys". Let me access your email to tell you which character trait you are from , what could go wrong... Brandon Links: ------ [1] http://unroll.me
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
