I'm trying to explain my concern more deeply, please try to follow my
thinking.
First: Everything you've written is correct and I fully agree.
But: The difference is: I'm deciding, that I'm using email from xy, I'm
deciding, that I'm using this email to register at some site or anything.
Anything of these services could be hacked of course, and then they can
use my mail to reset password, use the accounts, etc.
Now think from the other side:
Some site, which I'm registered in is trusting some oauth provider I'm
not even knowing about. I'm not registered at this provider. If this
provider is (independent how or from whom) is used in a malicious way,
they can access my account, without my knowledge by sending a valid
token including my email.
I'm not sure how to explain the main concern about this in more detail
and of course I can avoid services providing these type of logins
without my permission, but as said what about the future?
On 8/10/23 00:40, Warren Parad wrote:
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?
Don't get me wrong: I'm not telling everything is on oauth as far (I'm
not so deep into the protocol) it's acting only as authorization not as
authentication, than it is anyway the wrong point to address this issue.
But if it would be possible to eliminate this specific issue inside the
protocol directly, it would be the best solution to not even run into
this situation at any later point of time.
As total naive approach I could about something like:
Client is trusting Provider for user authentication/authorization
Client must set some random verification token (normally requested / set
by the user)
User is registering this token under the provider
Only if this token is valid the token is accepted by the client
If something like this would be included in the protocol itself, it
would be working in all situations like companies because they can
control both sides and generate such tokens automatically
And yes if the site is working together with the provider than it's
over, but that's exactly the point: Than the target itself must be
included not only the single provider, where the user might not even
have an relationship with.
Further I could think of extended security, by using signed tokens with
user provided public key, so it's technically secured to just fake tokens.
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
