No, Okta, senior management, not an errant employee, caused you to get hacked

Comments

• otter@lemmy.ca ⁨1⁩ ⁨year⁩ ago

  Title seems correct but confusing

  No Okta, it was senior management, not an errant employee, that caused you to get hacked.

  source

  • Earthwormjim91@lemmy.world ⁨1⁩ ⁨year⁩ ago

    You still need the comma before Okta to be grammatically correct.

    More correct would be to just use multiple sentences.

    “No, Okta. It was senior management, not an errant employee, that caused you to get hacked.

    source

    • otter@lemmy.ca ⁨1⁩ ⁨year⁩ ago

      That makes sense! I sometimes leave out commas that are probably necessary but feel excessive. I should just work on rephrasing things in a way such that commas aren’t necessary to begin with

      source

      • -> View More Comments
    • Instigate@aussie.zone ⁨1⁩ ⁨year⁩ ago

      You could use a semicolon rather than a fullstop as well:

      “No, Okta; it was senior management, not an errant employee, that caused you to get hacked.”

      That may help elucidate the meaning better while maintaining a single sentence, as is par for the course with headlines.

      source
  • scarabic@lemmy.world ⁨1⁩ ⁨year⁩ ago

    This is a case where I’d actually use parentheses.

    No, Okta, it was senior management (not an errant employee) that got you hacked.

    source

    • otter@lemmy.ca ⁨1⁩ ⁨year⁩ ago

      I like this one

      source
  • Coach@lemmy.world ⁨1⁩ ⁨year⁩ ago

    No, Okta; senior management caused you to get hacked, not an errant employee.

    source
• CriticalMiss@lemmy.world ⁨1⁩ ⁨year⁩ ago

  2. Blocking the use of personal Google profiles with Google Chrome (Complete) Okta has implemented a specific configuration option within Chrome Enterprise that prevents sign-in to Chrome on their Okta-managed laptop using a personal Google profile.

  This is one of the simplest things to achieve but it gets so much pushback from C-level it’s frustrating. I tried to push this, once the personal @gmail.com accounts got revoked all hell broke loose, despite being a clear security vulnerability. It also doesn’t help that they have these “sync” features nowadays that re-download all the extensions you have on other devices so only god knows what type of malware you’re letting into your environment.

  source

  • TheBat@lemmy.world ⁨1⁩ ⁨year⁩ ago

    What s bunch of C-units

    source
• Pxtl@lemmy.ca ⁨1⁩ ⁨year⁩ ago

  I mean if you’re on GSuite, fundamentally isn’t a loss of control of your personal Gmail account just as likely as a loss of control of your professional account?

  It does show how browsers offering cloud-synched password vaults without mandating 2FA to use that feature is grossly irresponsible.

  2FA is, in my experience, the thing that would be blocking 99% of this kind of attack. Which shows how if you’re regularly using something that doesnt have 2FA that should be a red flag. In this case it was 2 layers of that:

  Their google account probably didn’t have 2FA, and neither did that service account. Now obviously a service account generally won’t have 2FA, but if you’re regularly keying in service account credentials into a web browser something has gone wrong.

  source

  • HoornseBakfiets@feddit.nl ⁨1⁩ ⁨year⁩ ago

    1. Not necessarily 2fa only secures you from direct attacks to the google login, but attackers can gain access another way: session cookie stealing.
    2. 2fa only really exists because people aren’t using better & unique passwords

    source

    • asdfasdfasdf@lemmy.world ⁨1⁩ ⁨year⁩ ago

      #2 isn’t true. I could choose a super strong password, but if the company chose to roll their own security and the dev chose to store user passwords in plain text, then their database is hacked, my password is out in the open.

      That cannot happen with MFA since the password never leaves your hardware key.

      source
• vin@lemmynsfw.com ⁨1⁩ ⁨year⁩ ago

  If anyone here is a security expert, can you tell me of the following should have been done be default

  4. Binding Okta administrator session tokens based on network location (Complete)

  Okta has released session token binding based on network location as a product enhancement to combat the threat of session token theft against Okta administrators. Okta administrators are now forced to re-authenticate if we detect a network change. This feature can be enabled by customers in the early access section of the Okta admin portal.

  source

  • whoisearth@lemmy.ca ⁨1⁩ ⁨year⁩ ago

    Not infosec but work with them closely this makes sense. If my laptop gets stolen or compromised it’s more likely to occur outside of the office or a VPN session. If I have sessions established with admin I 100% want them to forcefully logout if my network changes. This would prevent a common scenario of bad actors from using a pre existing admin session.

    source

    • vin@lemmynsfw.com ⁨1⁩ ⁨year⁩ ago

      Yes, it makes sense. Can not doing it be considered gross negligence?

      source

      • -> View More Comments
• idefix@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

  Using my company’s network, access to Google (Gmail) authentication is blocked by the firewall. Why haven’t they done similarly if employees aren’t supposed to do so?

  source

  • kill_dash_nine@lemm.ee ⁨1⁩ ⁨year⁩ ago

    Based on a few DNS lookups, I see that Okta likely uses GSuite. Would it still be possible the block non-work related Google logins at the firewall level? Seems that would complicate things quite a bit.

    source

    • idefix@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

      It would indeed. “Problematic by design” then?

      source