14 ms·

No, that's distinctively different. This is about distributing attack surface, not obscuring authentication infrastructure. Are we really at a point where not r

by 9dev 5y ago

No, that's distinctively different. This is about distributing attack surface, not obscuring authentication infrastructure. Are we really at a point where not relying on external account providers is considered unusual, or a bad practice? I'm not buying it.

berkes 5y ago
> something like Okta is an infinitely more attractive target than we are In my book that counts as "obscurity". "We are not an attractive target, hence we won't be targeted". You will be targeted, as long as your defence is weak. Only if you manage to set up a comparable defence to a large provider, this argument flies: because all things equal, attackers will attack the more attractive party. But all things are not equal. (Which I'm not certain about, it may very well be that Okta has a really poor defence in place, in which case my argument falls apart, because you'd be able to "make all things equal" much easier. I doubt this though). > Are we really at a point where not relying on external account providers is considered unusual, or a bad practice? No. I consider it reasonable to "build your own", but only in certain cases. Things like auth are not your core domain (unless you are an auth-provider, obviously), so all effort and time you spend on building the umpteenth login/auth-flow is not spent on building the stuff that sets you apart. Even if you drag in a standard library and only spend an afternoon: you're still maintaining it, testing it, etc. And with external parties, generally, you'll be following market best practices: fingerprint-login becomes standard? You'll get it almost for free, whereas in the diy-case you'll be designing, testing, building such progressing tech for ever. The economics for building are just wrong. As are the security: as pointed out above: I highly doubt you'll be able to match a level of defence a large, focused, experienced party can obtain. But there may very well be cases in which building your own login/auth makes sense and the tradeoffs in economics and security (and features) make sense. Maybe it has to integrate into some legacy; maybe (legal) requirements enforce you to keep it all in-house, etc.
- 9dev 5y ago
  > In my book that counts as "obscurity". "We are not an attractive target, hence we won't be targeted". You will be targeted, as long as your defence is weak. I find this point to require more subtlety; "we are not as much of an attractive target, so we likely won't be targeted by a sophisticated, human adversary" is more apt for the situation. The attack vector is just not comparable to Okta's scale, which is true for the majority of companies and platforms out there. That doesn't mean security should be taken lightly, just that the magnitude and frequency of bad things happening will be lower. > Things like auth are not your core domain That's a good point, but it depends on the situation. I wouldn't recommend spending lots of time on this yourself, but there are standard libraries or OSS solutions available. If you're optimising for reliability, it might be beneficial to keep auth within your own systems. If you're optimising for privacy under GDPR, for example, it might be beneficial to not trust your users' data to an external provider. And so on.
  - berkes 5y ago
    > I wouldn't recommend spending lots of time on this yourself, Unfortunately, this is in direct opposition to > That doesn't mean security should be taken lightly I agree about the subleties that, indeed, make the tradeoff more nuanced. You are less likely to be targeted. But, given that you "wouldn't recommend spending lots of time on this yourself" (my recommandation too), the trade-off balances dangerously into the "attractive target" too. > but there are standard libraries or OSS solutions available. Which, unfortunately is hardly different from "a centralized target". Look at, for example, WordPress. I used to have a WordPress hosting company: the constant battering on the entry-doors, by bots, and humans is real. The amount of successful breaches are staggering. I don't host anything WordPress anymore, yet IPs that haven't ever seen WP are hammered by bots trying to breach WordPress admin, XMLRPC, Woocommerce and so on. By your reasoning, none of the WP sites we hosted back then were "attractive". By that reasoning, the servers I run now, without WP, are even less attractive. Yet they are battered by attackers. 24/7. And breached (not my current servers, though) quite often. Small websites for coaches, mom-pop-shops, the garage around the corner, your local football fanclub, and so on. Breached. Because they were an attractive target, not by being centralized, but because they weren't. Exactly because they use (OSS) libraries, combined with very little resources for defence, they are attractive.

by 9dev 5y ago

berkes 5y ago

> something like Okta is an infinitely more attractive target than we are In my book that counts as "obscurity". "We are not an attractive target, hence we won't be targeted". You will be targeted, as long as your defence is weak. Only if you manage to set up a comparable defence to a large provider, this argument flies: because all things equal, attackers will attack the more attractive party. But all things are not equal. (Which I'm not certain about, it may very well be that Okta has a really poor defence in place, in which case my argument falls apart, because you'd be able to "make all things equal" much easier. I doubt this though). > Are we really at a point where not relying on external account providers is considered unusual, or a bad practice? No. I consider it reasonable to "build your own", but only in certain cases. Things like auth are not your core domain (unless you are an auth-provider, obviously), so all effort and time you spend on building the umpteenth login/auth-flow is not spent on building the stuff that sets you apart. Even if you drag in a standard library and only spend an afternoon: you're still maintaining it, testing it, etc. And with external parties, generally, you'll be following market best practices: fingerprint-login becomes standard? You'll get it almost for free, whereas in the diy-case you'll be designing, testing, building such progressing tech for ever. The economics for building are just wrong. As are the security: as pointed out above: I highly doubt you'll be able to match a level of defence a large, focused, experienced party can obtain. But there may very well be cases in which building your own login/auth makes sense and the tradeoffs in economics and security (and features) make sense. Maybe it has to integrate into some legacy; maybe (legal) requirements enforce you to keep it all in-house, etc.

9dev 5y ago
> In my book that counts as "obscurity". "We are not an attractive target, hence we won't be targeted". You will be targeted, as long as your defence is weak. I find this point to require more subtlety; "we are not as much of an attractive target, so we likely won't be targeted by a sophisticated, human adversary" is more apt for the situation. The attack vector is just not comparable to Okta's scale, which is true for the majority of companies and platforms out there. That doesn't mean security should be taken lightly, just that the magnitude and frequency of bad things happening will be lower. > Things like auth are not your core domain That's a good point, but it depends on the situation. I wouldn't recommend spending lots of time on this yourself, but there are standard libraries or OSS solutions available. If you're optimising for reliability, it might be beneficial to keep auth within your own systems. If you're optimising for privacy under GDPR, for example, it might be beneficial to not trust your users' data to an external provider. And so on.
- berkes 5y ago
  > I wouldn't recommend spending lots of time on this yourself, Unfortunately, this is in direct opposition to > That doesn't mean security should be taken lightly I agree about the subleties that, indeed, make the tradeoff more nuanced. You are less likely to be targeted. But, given that you "wouldn't recommend spending lots of time on this yourself" (my recommandation too), the trade-off balances dangerously into the "attractive target" too. > but there are standard libraries or OSS solutions available. Which, unfortunately is hardly different from "a centralized target". Look at, for example, WordPress. I used to have a WordPress hosting company: the constant battering on the entry-doors, by bots, and humans is real. The amount of successful breaches are staggering. I don't host anything WordPress anymore, yet IPs that haven't ever seen WP are hammered by bots trying to breach WordPress admin, XMLRPC, Woocommerce and so on. By your reasoning, none of the WP sites we hosted back then were "attractive". By that reasoning, the servers I run now, without WP, are even less attractive. Yet they are battered by attackers. 24/7. And breached (not my current servers, though) quite often. Small websites for coaches, mom-pop-shops, the garage around the corner, your local football fanclub, and so on. Breached. Because they were an attractive target, not by being centralized, but because they weren't. Exactly because they use (OSS) libraries, combined with very little resources for defence, they are attractive.