Let me try that differently, is OAuth more vulnerable than email usage? If you hacked any email provider that's arguably a bigger goldmine than just ones protected by oauth. As long as sites are protected by email, oauth gives a more secure strategy. Most providers that accept email as authentication allow you to reset your password via email.
Going further, "email is insecure" because providers that send email can impersonate you. How about telecom companies, they can pretend to send SMS from you. Or the government, they could issue a new password in your name and pretend to be you. The horror. In all seriousness, it's about your threat modal more than anything. Concerned about your email, then that's your weak point, concern about oauth, we'll first be concerned about your email, and then you can be concerned about oauth. If we assume that everything was on oauth, then there's the question of why don't providers just implement a FIDO2 compliant strategy. Wouldn't that solve everything? On Thu, Aug 10, 2023 at 12:27 AM Matthias Fulz <mf...@olznet.de> wrote: > Thank you for the responses so far. > On 8/9/23 22:20, Warren Parad wrote: > > I can tell you I definitely read it. I actually read it multiple times. > But I don't know what to tell you. The problem you've identified exists, > but that doesn't necessarily mean it is a problem. In a way it is a bit > like, You create a bank account at a bank and you give them all your money. > They then decide to never give it back. > > Yep I know, but the difference is, that I've full control over my decision > to give my money to this bank or not. > > > While banks are regulated in most countries and things like GitHub are > not, in essence this interaction is based on trust. Of course solutions > like WebAuthn via FIDO2 used as a first party authentication can solve > this, and arguably this is the remit of the entire web3.0 domain. > > I don't think anyone would suggest this isn't a problem, just that it > isn't that big of a problem. I think realistically, in order for this > problem to have a closed form solution, it would need to start with a > suggestion on how to solve it, rather than a bunch of us agreeing that it > is. Because right now there doesn't seem to be any fundamental solution > available for this. And honestly, the bigger problem is the digital assets > at risk at the third parties is not due to impersonation, but just general > negligence. GitHub isn't trying to malicious log into my StackOverflow > account, and Google isn't trying to log into my bank. That's because these > organizations have supposedly bound themselves to not grant this ability to > their internal engineers to abuse. And they are spending tons of resources > attempting to stop external attackers. > > That being said, it's hard to know if this problem hasn't already > transgressed in the wild. While it is certainly possible, it seems internal > users are more likely to act maliciously on behalf of the user via their > owned data in their own company, rather than attempt to impersonate their > users at third party sites. > > These points are totally correct, but I think also about something like > official Authorities (ae. Patriot Act, etc.) that would definitely be > interested in such things (ok not on me personally), but this is another > topic. > > For me to be more safe, I'm using now a unique mail for Github, etc., > which is sufficient for now, but if you think into the future and > especially about oauth with more than a handful widely used trusted > Providers and that they could be hacked, infiltrated forced to grant > malicious access, etc. Than this could become to a huge problem in no time. > > As example: Think about one widely used trusted provider that's hacked, or > similar. You could access so many accounts on multiple sites, even if the > users are never used this oauth for these sites. > > > Sorry to insist here, but just because it is not an issue now, I can't > agree that this not a big deal in general. > > I mean in the above scenario even a unique mail wouldn't help because that > could send any mail, they want to these sites. Think about such provider > acting malicious and you would not even HAVE an account at any of them: > every site, that trusts them could be accessed under your account just by > knowing the user identifier, which is in 99% time the mail. > > > - Matthias > > > - Warren > > On Wed, Aug 9, 2023 at 10:06 PM mfulz <mf...@olznet.de> wrote: > >> Anyone read this topic or could tell if there is a better place to adress >> this? >> >> Sent from Nine <http://www.9folders.com/> >> ------------------------------ >> *Von:* mfulz >> *Gesendet:* Sonntag, 16. Juli 2023 03:38 >> *An:* oauth@ietf.org >> *Betreff:* [OAUTH-WG] OAuth Trust model >> >> >> >> Hi Together, >> >> I was thinking about some (at least I see it in that way) problem in the >> whole oauth/openid design: >> >> The problem is the following: >> >> The user has no control about what providers are accepted by the clients >> (websites, etc.) and this opens access to these providers without any way >> to protect against that. >> >> Example: >> >> I've created an account with email/password login at stackoverflow >> >> I've created an account with the same email at github >> >> -> logged out from stackoverflow >> >> -> logged in via github oauth -> working and connected to the email/pw >> account from stackoverflow >> >> >> Stackoverflow has the possibility to remove the github login now, but the >> main problem is, that I would be out of control, that some of these oauth >> providers >> >> (please don't go into the discussion WHY they or anyone should do it) >> could access my accounts, when such site would allow them as provider. >> >> >> In my opionion it would be good to avoid such issues, by including >> something in the standard, that the user MUST allow the connection on both >> sides on the client >> >> and on the provider. >> >> >> Yes for sso without any existing account that's some kind of an issue, >> but still it could be added some verification process like sending >> confirmation link >> >> That the user is accepting the oauth provider on the Client side. >> >> Then the oauth provider would also need access to my emails to access my >> account. >> >> >> Not sure if I'm wrong here but I think my description is correct. >> >> >> BR, >> >> Matthias >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
