Hacker News Reader

I usually very much agree with you. But this is a case where I'll "beg to differ".

At least we agree on the baseline of not charging for 2FA.

The fact is, it's very difficult to fight "shadow IT". SaaS companies penalizing early adopters for access to acceptable security only incentivizes employees, at large and small companies, to bypass IT vendor management and security policies. And once you've had to make an exception for "the CROs favorite SaaS tool", it's going to be fair game and an uphill battle to taken seriously.

As an industry, as a society, we need to make some of these security features easier to implement, easier to adopt, and not a penalty.

As I noted in a sibling comment, I also think that running a protection racket is lazy product management and marketing.

Frankly, if you are telling me that I have to pay extra for protection, that tells me that you don't take security seriously, since you are basically operating an insecure environment as your default practice.

The companies listed on the sso.tax site include many that self-evidently take security extremely seriously, far more so than most of their customers, so I don't know where that leaves your argument.

It sounds like you're just not happy that SSO gets used for market seg. I'm not "happy" about it either. That doesn't make it a dark pattern or an indicator that companies "don't take security seriously".

The status quo is the problem here. So pointing to the status quo doesn't invalidate my argument. Taking security seriously means you take the security of your customers and your users seriously--not just yourself. I'm sure a lot of those companies take their own security seriously. That doesn't mean they shouldn't be doing a better job for their customers, their users, and the rest of society.

It's not just that my feelings are hurt, it's that I personally view this as a societal issue. Our tremendous reliance on this internet thing, and our lax day-to-day security practices and expectations, puts us at serious risk--individually and as a society.

You regularly post about the overcomplexity of security protocols and their poor implementation. I'm sure you're more than just "unhappy" about those things.

SSO shouldn't be hard to implement relative to, say, MFA--especially since so many use SMS. Auditing should be incredibly straightforward to implement, especially if you are using tools like Rails or Django.

Charging money for SAML integration is simply not a "societal issue".

Nor are either JWT or DNSSEC--on their own.

But we aren't having a discussion amongst the general population. We're having a discussion amongst people who plan, design, and build these systems and who, as professionals and practitioners, society looks to for input on policy choices.

The fact that SSO--and let's be honest, it'd be nice if it weren't always SAML, just like it'd be nice if Google/et.al. didn't force us all to use JWT--is so broadly taxed should be viewed the same way we used to view storing passwords in plain text or not supporting 2FA.

DNSSEC and JWT are far more important security issues than the SSO tax; like, it's not even close. None of these are societal issues though; "things that annoy me" are not per se societal issues. "How much a service costs to use properly" simply isn't a societal issue. Just pay what they expect you to pay and move on. Or don't, and don't use the service. I don't see what's complicated about this.

It's an indicator that the company favors profits over security.

Literally every commercial entity, including the ones with the actual best security teams on the planet, favors profits over security in multiple ways.

Yes! Their behavior in public is one of the few signals we have to assess the degree to which they take security seriously behind the scenes. Hence, the SSO tax is an issue to us, we do evaluate companies by their behavior in this regard.

That's silly, since there are powerful business reasons for companies to charge for SSO integration (see above), and companies routinely make far more important compromises in favor of profits without comparable justification. But you do you.

And this is why it is a societal issue.

Individuals and companies will do what makes sense for their bottom line in the short-term, even if it is lazy or even self-defeating in the long-term.

But if it is bad for society, then it's a societal issue and requires society to intervene.

Just pay for the service or don't use it. Society will be fine.

> As an industry, as a society, we need to make some of these security features easier to implement

They're very easy to implement - it just costs money. If you've got enough employees that you need SSO, it's time to move off the free tier.

As an industry, as a society, we need to stop expecting developers to deliver services to huge multinationals for $0

In the general case I think it's a perverse segmentation, security is the right default and obviously we can't really force people to stop offering inadequate security for a lower price, but we should discourage it.

Remember when bulk hosts segmented on HTTPS? Want to host dog.example, cat.example, and sheep.example? That'll be $10 per year. Oh you want SSL for them? That'll be $50 per month per domain. Sure, you get better performance and whatever else, but there is no option to go without those and just pay $10 per year for the basic service but with HTTPS.

They had very similar excuses to what you've offered, it's a clear market signal, it actually does cost us money to do this (but nowhere near what they were charging usually, these might be "$100 SSL certificates" but if the bulk host wasn't getting a good deal directly they were buying from a "discount" reseller for less than sticker price anyway), we can subsidise our cheap offering knowing serious customers will buy the expensive one and so on.

If there are people out there who have less security because that cost less money when in reality it was just a feature toggle that's a bad thing.

Security is different the same way safety systems are different. You don't really want the investigators of a child's death to conclude that the $500 extra "Premium" version of your product had safety interlocks that would have prevented the death, shame the "Family Economy" version lacked those. And likewise, when investigators conclude the successful attack on Customer X was because they had your "Basic" package lacking the optional security features for "Premium" customers, do you think other customers buy Premium or do they leave for a product which doesn't have your terrible press?

The really nice pies I sometimes buy have a nicer pastry, and a richer gravy, but in common with the cheaper pies I also sometimes buy they don't have shards of metal or glass, expired or diseased ingredients, and so on. The Premium product is nicer but the cheap product is up to a minimum standard for safe food, and I feel like way too many software products aren't reaching a minimum standard for secure software.

Actually, SSO is usually a requirement for even basic security audits. So SSO is essentially required for companies operating in specific sectors, regardless of their size. Healthcare and military contracts are two obvious ones, but any company dealing with sensitive information, going through SOC compliance, or similar will likely need to enforce SSO to enforce and audit access policies.

Besides, SSO is a major convenience. Assuming that SSO = large company is a flawed perspective, although, I understand the reasoning you're conveying. I believe, however, that only very small companies (less than four people) can easily avoid SSO, because it is complicated to deal with on/off-boarding employees, SSO helps.

And I agree with OP in most regards, for most services, advanced security controls should be available. I think it is far more likely that most companies segregating their security features are not secure by design, so the functionality they're offering is poorly implemented, and by restricting access they limit the amount of support they need to provide to those features.

I don't know which security audits you're referring to. PCI doesn't require SSO for all SAAS apps. There's no standardized HIPAA/HITECH audit at all. SOC2 is probably the primary driver for SSO adoption, and even SOC2 doesn't actually require SSO (SSO is just the easiest way to meet a bunch of SOC2 security scope requirements). SOC2 is also the price-insensitivity threshold product managers are relying on for segmenting: most sane companies don't SOC2 until they're past product-market fit and are reliably closing sales (anybody who tells you to speculatively SOC2 before then is selling you something).

Again: it's obviously an inconvenience, or the sso.tax wouldn't be super annoying. I would of course prefer it if SSO were free everywhere.

This is another comment that makes insinuations about the competence of companies that tax SSO. But you can just look at the sso.tax site and see several companies with world-class security teams, so that argument doesn't work so well.

Do you really believe that these world-class security teams have the authority to influence this detail of the pricing models of their organizations, or the political naivete to fight this fight?

In some of these places, yes. It's a seller's market for this kind of talent, for whatever that's worth to you to know.

Ok this is a _fascinating_ comment. (thanks for the discussion as always by the way!)

Is there a link between the market for security engineering talent and the leverage that the security engineers have within their organizations? Are you seeing anecdotes play out in the industry that inspire hope that the balance of power in business decisions is shifting toward the engineers?

I don't think engineers automatically agree with you that organizations should pay less money for the services they're working on, is the issue here. It feels like a lot of people on this thread are convinced that Very Annoying Things are, per se, moral catastrophes. But they aren't. Services cost what they cost.

A literally equivalent way to look at the SSO tax is "the no SSO rebate". As a security engineer, I'm not prepared to launch a moral crusade over SMBs who don't adopt SSO on all their random SAAS apps; meanwhile, we're SSO on everything, and it costs us extra money, and that's life in the National Foosball League.

I’m the commenter that’s not on a moral crusade, or even annoyed, I just question the business justification for gating SSO in this day and age :)

See above: companies with SSO's are overwhelmingly less price-sensitive than companies without them, which tend to be smaller.

Times are changing though. Smaller companies increasingly have SSO portals. At what tipping point will the industry embrace SSO for everyone?

Since the whole point of the SSO tax is to segment out small companies from larger ones, mass adoption of single signon by small companies is a problem that will solve itself, as SSO stops being a good segmentation signal.

Are we talking past each other? It seems like we just disagree on when segmentation on SSO will no longer be prudent - I believe we’ve crossed that point, and you believe it’s in the future. Seems like we agree in substance though.

I don't think Thomas has an opinion on the "when". He's just saying it's being used that way. If it's being used that way, then it's still a good signal (in the markets where it is being used in that manner).

If it's actually true that we have crossed the point where it is no longer prudent for companies to segment their customers this way, then there are a whole lot of companies making unsound business decisions, and the problem will solve itself.

> There's no standardized HIPAA/HITECH audit at all.

HITRUST is the standardized audit for companies that care about HIPAA/HITECH, but your argument certainly holds there as well (everything you can say about SOC2 is just multiplied by an order of magnitude or two for HITRUST).

I have worked for a few small price sensitive companies and we very much still relied on SSO.

Yes, obviously, the sso.tax wouldn't be super annoying if that weren't the case.

Yes, but also a bit of muddled.

Let's take SSO for example. In the early days of Okta/Ping/OneLogin - Lets call it 2015. SAML was a big cost add-on to almost every service. At the time most services (with a few exceptions like Zendesk and Salesforce) charged you a decent proserve fee for setting it up, because it was a manual setup process for them. It was hard/time consuming/etc.

For the time, that makes total sense. But since then SAML libraries and usage have matured. You can write less than 100 line python/flask application that supports SAML. So while SAML was, at one point, actually expensive (by person hours, both engineering and PS) to implement ... it no longer is. Companies are just continuing to charge for it in most cases... because they can get away with it.

The real problem with SSO in general, at least currently, is that it's not viewed as a necessity for all businesses (even though it is). A company a decade ago could sign up for the cheap Slack edition and be happy with that through 100+ employees. Now a company of 5 or 10 may already have SSO and therefor need to goto a Slack edition that is twice as expensive - simply for that one feature.

SAML libraries are still pretty unsafe. But I agree with you: the cost of actually delivering SSO features has nothing to do with why they're taxed.

> I absolutely understand why SAAS companies tax SSO.

You don't mention all advantages to the SAAS company to have their customers using SSO, though: improved customer stickiness, happier end users, and no more liability for stored password hashes. Charging for SSO is false economy.

I think that's potentially the difference between social sign on and enterprise SSO.

Login with Google etc. achieves most of those advantages, while still leaving SSO against an organisation's SAML provider etc for enterprise.

That solves password hashes, yes. But the end users face the scenario "this is one of those apps that's missing from my company's SSO portal, how do I get into it again?", which nobody likes. And does nothing for stickiness.