I've never worked at Okta, but I've worked with several production ticketing systems at big and small companies, and all of them contained critical information about customers and operations. Including credentials.
Updated Okta Statement on Lapsus$
131–140 of 239 posts
Re: Updated Okta Statement on Lapsus$
#132Wondering if this is related.
Re: Updated Okta Statement on Lapsus$
#133Earlier quoted context omitted.
8600 channels? Wouldn't that overwhelm you? I'm trying to think up scenarios where an org would need so many, but I can't. Is this normal?
You're not going to be even aware of the majority of the channels. In my experience having ~1.5 channels per employee sounds right across the company. I've started channels for: specific incidents, personal huddle, lunchtime game organisation, limited notifications target, etc. Also we don't know if they count archived channels or not.
Re: Updated Okta Statement on Lapsus$
#134Or was that all bluff and lapsus didn't have anything
Re: Updated Okta Statement on Lapsus$
#135>The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers. despite an overwhelming preponderance of damning evidence from twitter (as well as the hacker themselves) you've somehow managed to find yourselves secure instead? Christs whiskers thats some impressive doublethink. Its also an excellent opportunity to fall on a sword that giv…
If there is one thing you want from a 3rd party auth provider, it's trust - this is not the time to play word games. I'd have far more faith in them if they were transparent about what had happened, what they're doing about it, and how they will make sure it can't happen again. Instead, they are being weasels - I for one, will not be using their services again, and this behaviour is the reason why. Here's another exa…
There are pros and cons both ways. You're centralizing the risk, but also centralizing the effort for quality. Perverse incentives however causes loss of quality: saying you fucked up will lose you customers, and some of that sweet, sweet stock value.
The fact that you can work for these companies without security clearance seems a bit insane. The more they grow and centralize, the more of a national security risk they become. It's not hard to get hired at Okta, and when you're in, you're in. At what point is not solving a security bug at Okta that you've discovered and selling it for monero more lucrative than actually fixing the bug? I realize that not everyone is like me and has a strong values that prevents them from doing so, and that scares me. If you're talented, it's super easy to backdoor a system and get around code-review
I'm torn
Re: Updated Okta Statement on Lapsus$
#136Earlier quoted context omitted.
The text is a bit ambiguous (and probably on purpose, I'm sure it passed through multiple layers where multiple lawyers have reviewed it too). Okta says Lapsus$ were unable to "obtain" the passwords, but they didn't say they were unable to set their own passwords (for example). Neither is the MFA tokens mentioned, although they do mention MFA in the text.
Then they'd have obtained it, no? It seems pertinent a support engineer could trigger a password reset if they were worried a password had been compromised for a user.
If you change a password, then you didn't "obtain" the previous password. Weasel words but there you go.
Re: Updated Okta Statement on Lapsus$
#137Earlier quoted context omitted.
If somebody uses my laptop, my Gmail account is not compromised; I'm being dolphined. Of course 5 days is quite a long time, but this is just to clarify what you didn't understand.
If I use your laptop to get access to your Gmail isn't your Gmail account compromised? I might not have access to your Gmail username and passwords (and MFA), but I can read your email, I can send email as you, etc etc. I feel like I have compromised your gmail account. If I steal your secure token and log into you through a cloned browser session and access your gmail have I compromised your gmail? It feels like it.…
The access is transient and you remain in ownership over the credentials and account, because the credentials were not compromised (just the programs/browsers with pre-existing auth). Though with physical access it's probably only a mater of time before local admin passwords are brute forced and access to keychain/browser saved logins is inevitable?
> If I steal your secure token
It's more like you just logged in using your secure token then someone stole the device and took advantage of that. I think we can all agree there's a difference between having access to the laptop and access to the account without the laptop.
Re: Updated Okta Statement on Lapsus$
#138Earlier quoted context omitted.
they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...
8600 channels? Wouldn't that overwhelm you? I'm trying to think up scenarios where an org would need so many, but I can't. Is this normal?
Re: Updated Okta Statement on Lapsus$
#139Earlier quoted context omitted.
What if they have access to some users' emails and then can selectively fire off password reset emails to them? It's probably less likely, but could be a vector.
They wouldn't need to have an Okta CSE account for that, since anyone can go to *.okta.com and fire off a reset password email for any account. (Then again it does look like that's not available for every org. There's not a "reset password" option on cloudflare.okta.com for instance. Why give a CSE the option to do a password reset in those cases, though?) It still sounds to me like they're saying that they could set…
Re: Updated Okta Statement on Lapsus$
#140Earlier quoted context omitted.
They wouldn't need to have an Okta CSE account for that, since anyone can go to *.okta.com and fire off a reset password email for any account. (Then again it does look like that's not available for every org. There's not a "reset password" option on cloudflare.okta.com for instance. Why give a CSE the option to do a password reset in those cases, though?) It still sounds to me like they're saying that they could set…
I don't understand all these crazy assumptions being made. A support engineer being able to set a password on any account is unthinkable, there is zero chance this is actually the case. Especially for a security company. It would be the equivalent of giving the doorman a key that opens everyone's apartment. Obviously support can trigger a reset, that you have to complete from your own e-mail account.
Anyway I agree it would be bad practice but that doesn't mean it's not done.