Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to the Power Users community on Codidact!

Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.

Post History

60%
+1 −0
Q&A Understanding OAuth(2) security: what's a realistic threat model?

I don't believe this addresses the question at all, because the question is asking about threat to the user. I personally suspect that adopting 3rd party authentication is often not driven by threa...

posted 4mo ago by matthewsnyder‭  ·  edited 4mo ago by matthewsnyder‭

Answer
#2: Post edited by user avatar matthewsnyder‭ · 2024-07-19T18:13:52Z (4 months ago)
  • I don't believe this addresses the question at all, because the question is asking about threat *to the user*. I personally suspect that adopting 3rd party authentication is often not driven by threat to the user, but threat *to the operator*. I am posting this since the OP said he'd prefer it as an answer, so 🤷
  • I claim that this benefit is not specific to OAuth, but applied to using any 3rd party auth service, for which OAuth is one model. So, it's not about OAuth per se, but just outsourcing the auth to some other entity. From the operators point of view, the threat model of DIY auth is:
  • * If accounts get hacked and users complain, they can send them straight to the third party rather than dealing with the issue themselves
  • * Note - sometimes, the "hack" is entirely the user's fault, due to using guessable passwords or sharing it too much, but they blame the site anyway and it takes time to deal with it
  • * If accounts get hacked and there's a media scandal, they can immediately blame the third party, and avoid losing their reputation and brand value
  • * Note - when handling PR scandals, it's important that your "defense" is not just credible but also short, sweet and quick. Otherwise, even if the scandal is not your fault, your response won't reach many people and they will continue blaming you. Saying "it was X third party's fault, they do our logins" can be deployed very rapidly.
  • * It is also much more convincing to say "we were paying XYZ to do our Auth and they dropped the ball, we have now fired them and switched to ABC" than to say "our programmers fixed the issue, won't happen again, trust us".
  • * If accounts get hacked and there's a lawsuit, the liability can be deflected to the third party
  • * When users, and more importantly investors, business partners and regulators, question the professionalism of your security strategy, it is much easier to say "we use industry standard XYZ service" which everybody has already learned to trust, while convincing them that your DIY solution is just as good requires a lot more time and effort
  • * This is because the third party auth provider, given that it's their core business, has invested a lot of money and effort into PR/marketing to make everyone believe that they're secure, whether it's true or not, whereas to you, the "security marketing" budget is just something that competes with the "my product/service is best" marketing budget.
  • * When the third party requires unreasonable compromises in the name of security, such as phone verification or excessive personal data, users question it less, and they certainly don't blame your organization for the poor experience
  • * When the 3rd party messes up, there does not appear to be a culture of blaming their customers for choosing their service. Our society seems to find it acceptable that your org simply took the auth provider's marketing (where they have the nice padlock clip art and the "secure" green checkmarks) at face value without trying to look past the marketing. The org is not blamed much for choosing to use a service that turns out to do a bad job.
  • * The org does not have to spend money employing engineers knowledgeable about security so they can build an auth system. (such people usually command a premium on compensation)
  • * The org does not have to learn how to screen candidates for knowledge about security. (such skills are a notorious case of the pathological "employee knows far more than the boss" pattern)
  • In short, the decision to use third party auth is not a transaction where the reward is improving user security. Rather, it is a transaction where the reward is reducing financial and legal risk to the organization. The security and experience of the user may even be degraded, but this can be viewed as just part of the cost.
  • You might gather from my tone that I disagree with much of this on the grounds of ethics and I have few qualms about co-opting my answer into a platform to whine about it :). But it's hard to deny that there are many business advantages for a website operator that comes from outsourcing a tricky bit of work (account security) to someone else.
  • You will also have to pardon me for not providing any hard evidence to back this up. Business decisions and strategy tends not to be accessible to the public where it can be easily cited. I am appealing to the reader's capacity for reasoning logically and to ask "cui bono".
  • I don't believe this addresses the question at all, because the question is asking about threat *to the user*. I personally suspect that adopting 3rd party authentication is often not driven by threat to the user, but threat *to the operator*. I am posting this since the OP said he'd prefer it as an answer, so 🤷
  • I claim that this benefit is not specific to OAuth, but applied to using any 3rd party auth service, for which OAuth is one model. So, it's not about OAuth per se, but just outsourcing the auth to some other entity. From the operators point of view, the threat model of DIY auth is:
  • * If accounts get hacked and users complain, they have to deal with them (which takes time and energy) instead of sending them straight to the third party
  • * Note - sometimes, the "hack" is entirely the user's fault, due to using guessable passwords or sharing it too much, but they blame the site anyway and it takes time to deal with it
  • * If accounts get hacked and there's a media scandal, it becomes "your fault" and you can lose reputation and brand value rather than just blaming the third party
  • * Note - when handling PR scandals, it's important that your "defense" is not just credible but also short, sweet and quick. Otherwise, even if the scandal is not your fault, your response won't reach many people and they will continue blaming you. Saying "it was X third party's fault, they do our logins" can be deployed very rapidly.
  • * It is also much more convincing to say "we were paying XYZ to do our Auth and they dropped the ball, we have now fired them and switched to ABC, trust us again" than to say "our programmers fixed the issue, won't happen again, trust us again".
  • * If accounts get hacked and there's a lawsuit, there's no one to shift the liability to, except at best your employees
  • * When users, and more importantly investors, business partners and regulators, question the professionalism of your security strategy, you may have to undergo lengthy audits and endless meetings trying to satisfy someone who doesn't know what they want. Whereas it is much easier to say "we use industry standard XYZ service" which everybody has already learned to trust, while convincing them that your DIY solution is just as good requires a lot more time and effort
  • * This is because the third party auth provider, given that it's their core business, has invested a lot of money and effort into PR/marketing to make everyone believe that they're secure, whether it's true or not, whereas to you, the "security marketing" budget is just something that competes with the "my product/service is best" marketing budget.
  • * Whenever you introduce something which improves security but harms the convenience or privacy they will blame you. But with a third party users are less critical. There is a sort of diffusion of responsibility because your org can't help the bad UX/privacy because now they delegated that to the third party, and the third party can't change things for this one case because they need to have a service secure enough for everybody.
  • * When the 3rd party messes up, there does not appear to be a culture of blaming their customers for choosing their service. Our society seems to find it acceptable that your org simply took the auth provider's marketing (where they have the nice padlock clip art and the "secure" green checkmarks) at face value without trying to look past the marketing. The org is not blamed much for choosing to use a service that turns out to do a bad job.
  • * This is reminiscent of "nobody gets fired for buying IBM".
  • * You need to hire engineers knowledgeable about security, and such people command much higher compensations currently.
  • * You need to screen candidates for knowledge about security, but this might be difficult because your managers are themselves clueless about it.
  • In short, the decision to use third party auth is not a transaction where the reward is improving user security. Rather, it is a transaction where the reward is reducing financial and legal risk to the organization. The security and experience of the user may even be degraded, but this can be viewed as just part of the cost.
  • You might gather from my tone that I disagree with much of this on the grounds of ethics and I have few qualms about co-opting my answer into a platform to whine about it :). But it's hard to deny that there are many business advantages for a website operator that comes from outsourcing a tricky bit of work (account security) to someone else.
  • You will also have to pardon me for not providing any hard evidence to back this up. Business decisions and strategy tends not to be accessible to the public where it can be easily cited. I am appealing to the reader's capacity for reasoning logically and to ask "cui bono".
#1: Initial revision by user avatar matthewsnyder‭ · 2024-07-19T18:04:09Z (4 months ago)
I don't believe this addresses the question at all, because the question is asking about threat *to the user*. I personally suspect that adopting 3rd party authentication is often not driven by threat to the user, but threat *to the operator*. I am posting this since the OP said he'd prefer it as an answer, so 🤷

I claim that this benefit is not specific to OAuth, but applied to using any 3rd party auth service, for which OAuth is one model. So, it's not about OAuth per se, but just outsourcing the auth to some other entity. From the operators point of view, the threat model of DIY auth is:

* If accounts get hacked and users complain, they can send them straight to the third party rather than dealing with the issue themselves
    * Note - sometimes, the "hack" is entirely the user's fault, due to using guessable passwords or sharing it too much, but they blame the site anyway and it takes time to deal with it
* If accounts get hacked and there's a media scandal, they can immediately blame the third party, and avoid losing their reputation and brand value
    * Note - when handling PR scandals, it's important that your "defense" is not just credible but also short, sweet and quick. Otherwise, even if the scandal is not your fault, your response won't reach many people and they will continue blaming you. Saying "it was X third party's fault, they do our logins" can be deployed very rapidly.
    * It is also much more convincing to say "we were paying XYZ to do our Auth and they dropped the ball, we have now fired them and switched to ABC" than to say "our programmers fixed the issue, won't happen again, trust us".
* If accounts get hacked and there's a lawsuit, the liability can be deflected to the third party
* When users, and more importantly investors, business partners and regulators, question the professionalism of your security strategy, it is much easier to say "we use industry standard XYZ service" which everybody has already learned to trust, while convincing them that your DIY solution is just as good requires a lot more time and effort
    * This is because the third party auth provider, given that it's their core business, has invested a lot of money and effort into PR/marketing to make everyone believe that they're secure, whether it's true or not, whereas to you, the "security marketing" budget is just something that competes with the "my product/service is best" marketing budget.
* When the third party requires unreasonable compromises in the name of security, such as phone verification or excessive personal data, users question it less, and they certainly don't blame your organization for the poor experience
* When the 3rd party messes up, there does not appear to be a culture of blaming their customers for choosing their service. Our society seems to find it acceptable that your org simply took the auth provider's marketing (where they have the nice padlock clip art and the "secure" green checkmarks) at face value without trying to look past the marketing. The org is not blamed much for choosing to use a service that turns out to do a bad job.
* The org does not have to spend money employing engineers knowledgeable about security so they can build an auth system. (such people usually command a premium on compensation)
* The org does not have to learn how to screen candidates for knowledge about security. (such skills are a notorious case of the pathological "employee knows far more than the boss" pattern)

In short, the decision to use third party auth is not a transaction where the reward is improving user security. Rather, it is a transaction where the reward is reducing financial and legal risk to the organization. The security and experience of the user may even be degraded, but this can be viewed as just part of the cost.

You might gather from my tone that I disagree with much of this on the grounds of ethics and I have few qualms about co-opting my answer into a platform to whine about it :). But it's hard to deny that there are many business advantages for a website operator that comes from outsourcing a tricky bit of work (account security) to someone else.

You will also have to pardon me for not providing any hard evidence to back this up. Business decisions and strategy tends not to be accessible to the public where it can be easily cited. I am appealing to the reader's capacity for reasoning logically and to ask "cui bono".