Live data from Hacker News

Updated Okta Statement on Lapsus$

okta.com

131–140 of 239 posts

Re: Updated Okta Statement on Lapsus$

#131

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.

Not putting secrets and sensitive data in bug reports / tickets has been a thing for at least 20 years, so you worked at some crappy run places.

Re: Updated Okta Statement on Lapsus$

#132
My booking.com account was hacked and someone from China booked a hotel using my account (Im in UK). Managed to cancel it for free, changed password, logged out of all sessions, turned on 2FA and removed all cards.

Wondering if this is related.

Re: Updated Okta Statement on Lapsus$

#133

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

Yep, same here. I create many topical channels to discuss some narrow-ish topic and archive them after the matter is concluded. Some of those channels just live a few days or even just hours - other live for several weeks but with several days of silence in-between messages. If I need to look something up I can grab the channel from the archive and won't have messages for unrelated topics in-between.

Re: Updated Okta Statement on Lapsus$

#135
post #82
post #59

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

Monoculturing the west's authorization/identity stack - Is that something we want to do? Authz/Authn as a service is great, until it isn't.

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$

#136

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

> Then they'd have obtained it, no?

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$

#137
post #17

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

> your Gmail account compromised

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$

#138

Earlier 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?

This blew my mind as well

Re: Updated Okta Statement on Lapsus$

#139
post #32

Earlier 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…

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.

Re: Updated Okta Statement on Lapsus$

#140
post #32

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

Confusing analogy, doormen frequently do have a key to every apartment in the building.

Anyway I agree it would be bad practice but that doesn't mean it's not done.

Post reply on HN