Hacker News Reader

Comment by staticassertion | Hacker News Reader

I wouldn't throw out the baby with the bathwater. I don't know how publicly it's acknowledged, but most people I know in security have always had a poor view of Okta's security.

On the other hand, I feel fine using GSuite for SSO because we have a much better view of their security.

That said, it sucks that everyone is so fucking bad at security. I maintain that it is not that hard.

View on HN

> but most people I know in security have always had a poor view of Okta's security.

What are their usual criticisms? Genuinely curious. I've always hated their UI, their docs, and lack of real support but felt that at least they had security going for them. The last assumption might have been proven wrong tonight.

Also, what would be a reasonable alternative to Okta now that their nearest competitor, Auth0, was acquired by them. Is GSuite a reasonable alternative for SSO with multiple different providers and supporting SAML, etc.? Thanks in advance.

A problem in infosec is information dissemination. Lots of their criticisms are based on backchannel information shared over drinks. It makes it difficult to discuss publicly.

I wouldn't want to make a recommendation, but I'll say that my company uses GSuite.

A typical opsec issue in many companies even to this day is doing ssh shell access to critical systems and doing so with ldap passwords or user-controlled authorised keys and without 2FA and without host key verification. There are trivial browser based local network attacks to gain reverse shell access with such setups. Just because those systems are behind firewall and VPN, people tend to falsely believe they are more secure.

> or user-controlled authorised keys and without 2FA and without host key verification. There are trivial browser based local network attacks to gain reverse shell access with such setups.

I'm struggling to see how that attack works without a copy of the private key.

Any pointers for what to search for to understand this better?

The key thing here is _user controlled_ private keys: this means that those can leak, and if they leak, you're in trouble.

A better solution is to use ephemeral SSH keys generated using an SSH CA. This kind of thing can be implemented with Hashicorp Vault, though I'm sure there are plenty of other solutions out there.

It simplifies key checking on servers too, as they just need to the details of the signer and there's no need to juggle keys in LDAP.

You'll still need a way to deliver those ephemeral ssh keys to a user controlled location, or make them indirectly usable by users (which amounts to the same thing).

In my company, we have a wrapper around `ssh` that handles that. That's the easy bit.

Jumpcloud seems to work quite nicely.

Security IS hard. Every single day there’s a zero day practically released.

Add in systems that were built for X and now doing Y. This is hard to get right. A single slip up will lead to you being compromised.

> Every single day there’s a zero day practically released

Yeah, people need to stop using memory unsafe languages. They choose not to.

> A single slip up will lead to you being compromised.

Not if you add multiple layers of security. Like sandboxing. Or mTLS. It's not hard to do that.

edit: Let me clarify. Security isn't hard generally, but it's hard individually, because you're drowning under everyone else making it artificially 10000x harder.

Log4j was memory safe. Tho I agree on mTLS and even would like most valuable networks to be connected only via an allow list of safe-ish destinations. It would make things a lot harder, and the logs of denied hosts would also be a nice warning.

Yep, after memory safety there's still work to be done. But it'll be a lot less work.

Converting the entire stack to memory-safe languages to save work is definitely in the “easier said than done” bracket.

Actually, the fact that memory safety bugs are more difficult to exploit seems to have increased the rate of vulnerabilities discovered and exploited, and the fact that these are now often higher-level bugs (think insecure feature design bugs rather than low level implementation bugs) - means that once something is discovered, it can often be exploited in a way that is either much more pervasive or far harder to detect. So no - safer languages won't stop security from being an issue. Secure design, implementation, configuration, and frequent red-teaming exercises are the only way to reduce your risk, and even then - expect to reduce the rate by some %, but never reach zero.

Just curious, what about the exploits targeting say Java VM?

> Yeah, people need to stop using memory unsafe languages. They choose not to.

Golang and Rust are not magic bullets that makes systems automatically secure.

Flaws in application logic have little to do with language choice.

Also consider the effort and money it takes to rewrite a multi million LOC system with several dependent apps. The new trendy languages introduce breaking changes, switch paradigms, and have less mature ecosystems.

I lost faith in Okta when we implemented OAG. They don't have an AWS marketplace version so if you want to run it there you have to manually convert their ESX appliance. Once it's up and running you can't login and get a shell. (Well, you can using Systems Manager on AWS...) and installing any agents on the box means support won't help you with anything.

Then their SNMP mib doesn't work properly. So you have a a box that is proxying some of your most critical systems that are so old that to integrate them with MFA requires OAG (think mainframes, old ERP systems etc) and you have to take Okta's word for it that the server is secure and not hacked.

They do thankfully support Syslog for logs, but again you have to take their word for it that you're getting all the logs, because you can't access the system to verify.

Having said all that. OAG solves a very real business problem and it is hard to find a competitor in the market with the level of integration it has to legacy platforms.

Interesting that you mention GSuite/Google.

I don't remember Google having any large-scale security incidens.

Have they been better at playing down their security incidents or are they doing something very right that the rest of the industry can learn from?

Aurora was the major incident. Google has invested heavily in a number of areas with regards to security, such as BeyondCorp, but I haven't talked to anyone from Google sec in a few years so I don't know how things have changed.

Google security is very well regarded in the industry for good reason.

> are they doing something very right

yes

> that the rest of the industry can learn from

unlikely

It's simple: they pay absurd amounts of money for top talent and let them work. Look: https://www.levels.fyi/company/Google/salaries/Software-Engi... can your company afford to pay 2-300K cash -- not to mention serious stock -- to bread and butter mid level engineers?

Yeah that's a fair point. As much as I badmouth Google in other areas like product longevity, I don't usually laugh at their security related offerings and initiatives.

A poster further up mentioned something that I think is often ignored.

Security isn't just about overflows and injections, outsider enemies vs insider allies. Any human with privileged access that can be compromised will eventually be compromised as the perceived value of his privilege increases beyond the cost of compromising him. Logging, distribution of privileges, and other such solutions aren't really solutions so much as just a sort of cat and mouse game.

I would claim that impenetrable security is not only hard, but ultimately impossible.

This comment won't age well.

You mean you expect GSuite to fall at some point? Could be, I don't have good insight into Google's internal security posture these days.

Reply on news.ycombinator.com