• testgoatpleaseignore@lemm.ee
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

    Kinda related but unrelated

    We negotiated last year for our employer to do something this month. All confirmed in written contract.

    Now everyone’s up in arms because it didn’t happen, and is blaming the staff who were supposed to implement it… when management didn’t hire any new people to do it

    I havent heard anyone actually say out loud, gee maybe we should be blaming their senior management for not actually working out the resources for what they agreed to…

    And of course not a fucking peep out of that departments managers about the situation. They will suffer no consequences for their failure.

  • Otter@lemmy.ca
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    Title seems correct but confusing

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

    • halfeatenpotato@lonestarlemmy.mooo.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      For real, had to read it like 3x to understand. The amount of commas in the OP title is just unnatural. I might even do:

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

      If that’s wrong, then I have no idea what hyphens are for lol.

    • Coach@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

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

  • Pxtl@lemmy.ca
    link
    fedilink
    English
    arrow-up
    4
    ·
    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.

      • asdfasdfasdf@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        Number 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. This happens all the time, even with huge tech companies.

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

  • vin@lemmynsfw.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    If anyone here is a security expert, can you tell me if the following should have been done by default? Is it not a prevalent design practice?

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

    • whoisearth@lemmy.ca
      link
      fedilink
      English
      arrow-up
      2
      ·
      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.

        • whoisearth@lemmy.ca
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          What negligence? If I read the policy change by Okta they’re ensuring that security of killing an admin session if the network changes.

          Edit - unless you mean not mandating the feature by default? As a SaaS solution Okta is set to provide the tools for any company to use which they’re doing. They provide the ability to enable tighter security but it’s not their problem to solve. They could argue successfully that a company can and should enable their own security provisions that may overlap.

          To use non-IT terms, Okta is providing a box of knives to a teacher. The expectation is the teacher ensures if the kids can use the knives or not. Okta can take out the sharpest knives if you ask them to but you have to ask.

  • idefix@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    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?

    • kill_dash_nine@lemm.ee
      link
      fedilink
      English
      arrow-up
      1
      ·
      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.