7 ms·

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

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.

bushbaba 5y ago
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.
- staticassertion 5y ago
  > 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.
  - lanstin 5y ago
    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.
    - staticassertion 5y ago
      Yep, after memory safety there's still work to be done. But it'll be a lot less work.
      - Closi 5y ago
        Converting the entire stack to memory-safe languages to save work is definitely in the “easier said than done” bracket.
      - int0x2e 5y ago
        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.
      - hnthrowaway0315 5y ago
        Just curious, what about the exploits targeting say Java VM?
  - rank0 5y ago
    > 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.
hangonhn 5y ago
> 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.
- staticassertion 5y ago
  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.
- vinay_ys 5y ago
  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.
  - porker 5y ago
    > 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?
    - talideon 5y ago
      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.
jiveturkey 5y ago
This comment won't age well.
- staticassertion 5y ago
  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.
keewee7 5y ago
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?
- staticassertion 5y ago
  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.
- ikiris 5y ago
  Google security is very well regarded in the industry for good reason.
- chx 5y ago
  > 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-Engineer/ 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?
  - politelemon 5y ago
    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.
zwayhowder 5y ago
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.
somenameforme 5y ago
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.

bushbaba 5y ago

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.

staticassertion 5y ago
> 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.
- lanstin 5y ago
  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.
  - staticassertion 5y ago
    Yep, after memory safety there's still work to be done. But it'll be a lot less work.
    - Closi 5y ago
      Converting the entire stack to memory-safe languages to save work is definitely in the “easier said than done” bracket.
    - int0x2e 5y ago
      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.
    - hnthrowaway0315 5y ago
      Just curious, what about the exploits targeting say Java VM?
- rank0 5y ago
  > 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.

hangonhn 5y ago

> 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.

staticassertion 5y ago
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.
vinay_ys 5y ago
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.
- porker 5y ago
  > 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?
  - talideon 5y ago
    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.

jiveturkey 5y ago

This comment won't age well.

staticassertion 5y ago
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.

keewee7 5y ago

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?

staticassertion 5y ago
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.
ikiris 5y ago
Google security is very well regarded in the industry for good reason.
chx 5y ago
> 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-Engineer/ 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?
- politelemon 5y ago
  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.

zwayhowder 5y ago

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.

somenameforme 5y ago

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.