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
