Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Updated Okta Statement on Lapsus$

okta.com

Post reply on HN
Print view View original

141–150 of 239 posts

Re: Updated Okta Statement on Lapsus$

#141

Post by zerkten »

phphphphp wrote: post #50
mdoms wrote: post #41

Earlier quoted context omitted.

You should do a stint in support. You'd be amazed how many people would rather interact with support than click the Forgot Password link.

As much as I’d like to forget, I’ve done a lot of support and much of that was authentication issues. I can certainly imagine in a corporate environment that some contingent of users would prefer to be hand-held through the reset request process, but all of them? My expectation (and experience of other similar systems) was that Okta would not allow password resets by anyone but the organization administrators. Howeve…

It's easy to find a large segment of enterprise customers where handholding password resets is the only option because of an enterprise policy which is getting misapplied. Further, these support requests are probably unlimited in support contracts raking in significant income for Okta, so it becomes the default for customers not to worry about it. Any time companies are selling a product plus enterprise offerings, it becomes much more opaque as to what the complete product is.

When organizations make the on-prem to cloud jumps they frequently are trading off oversight and experience. Many tenured internal teams have been broken apart by these types of migrations because they are ultimately sold to management as cost saving endeavors. These folks would make your observation about organizations admins controlling resets, but they are gone.

Re: Updated Okta Statement on Lapsus$

#142

Post by hughrr »

maldeh wrote: post #119
templapsusread wrote: post #31

Earlier quoted context omitted.

they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...

A more poignant elegy to the modern landscape of compliance theater I have never seen: > Security Standards. Okta's ISMP includes adherance to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: > a) Internal risk assessments; > b) ISO 27001, 27002, 27017 and 2701…

Yep. All these standards are tick boxing for liability. Nothing more.

They are not effective security controls and never will be and should never be a measure of that.

Re: Updated Okta Statement on Lapsus$

#143

Post by hughrr »

intunderflow wrote: post #55
intunderflow wrote: post #51

Earlier quoted context omitted.

To note in some of the earlier screenshots you can see they have the EC2 Instances menu open in their tabs - that's a bit concerning, why does a support engineer need AWS EC2 access?

Can you open the web console with just an access key? My impression was you could only use that to act through a CLI tool, at least officially you need to have powers or act as a user with powers to use the web console directly?

You can add users with console access from the IAM API if you have enough reach.

Re: Updated Okta Statement on Lapsus$

#144

Post by Spooky23 »

politelemon wrote: post #79
templapsusread wrote: post #31

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?

Channel sprawl is very normal. While my day job has a broad scope in the org, I’m a “member” of over 900 MS Teams. I’d guess that 3% are active and i interact with 0.

Re: Updated Okta Statement on Lapsus$

#145

Post by [deleted] »

indigodaddy wrote: post #24
jgrahamc wrote: post #2

Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...

I thought that a CF person (can’t remember if it was Prince or not) said in the main HN thread yesterday, that CF uses their own homegrown SSO internally, and Okta externally, but this blog article seems to infer the opposite… Anyway, I likely misinterpreted yesterday’s comment..

[deleted]

Re: Updated Okta Statement on Lapsus$

#146

Post by 0x0000000 »

indigodaddy wrote: post #24
jgrahamc wrote: post #2

Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...

I thought that a CF person (can’t remember if it was Prince or not) said in the main HN thread yesterday, that CF uses their own homegrown SSO internally, and Okta externally, but this blog article seems to infer the opposite… Anyway, I likely misinterpreted yesterday’s comment..

I think you're referring to this tweet:

https://twitter.com/eastdakota/status/1506148082194386949

I believe @eastdakota is saying that Cloudflare has their own homegrown SSO internally, but they do not make that available externally to their customers (it's not a public product that one can buy). I don't think that the tweet was saying that they use Okta externally.

Re: Updated Okta Statement on Lapsus$

#147

Post by Johnny555 »

lnxg33k1 wrote: post #63
Johnny555 wrote: post #34

Earlier quoted context omitted.

It's an interesting world we live in if the word of an organization that earns a living by stealing data and extorting companies is trusted more than the word of a public company.

I would say it's more about what each entity has at stake, the public company could be read as "An entity which sold something that didn't have the capability to offer and has a lot to lose if the issues are uncovered" Against "Someone that what has to lose at this point?"

"Someone that what has to lose at this point?"

What to lose? Their reputation?

Both sides have incentive to stretch the facts. But Okta has more accountability since if an Okta customer comes forward and says "We had credentials of several of our users maliciously reset during that time period and have the logs to prove it", then Okta is going to have a hard time of it.

If Okta comes up with proof that Lapsus didn't have the access they said they did, Lapsus is not going to have many "customers" complaining "you didn't crime that other company as much as you said you did"

Re: Updated Okta Statement on Lapsus$

#148

Post by Ozzie_osman »

tofuahdude wrote: post #11

> Okta service has not been breached and remains fully operational > highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop These are some impressive mental gymnastics!

Not saying this is what happened or defending Okta, but these two statements could be true. Assuming the support engineer had ACCESS to allow him to do some bad stuff, but they have audit logs to prove his account didn't use that access (except to take screenshot), both statements could be true. It's unlikely but possible.

Re: Updated Okta Statement on Lapsus$

#149

Post by disillusioned »

hughrr wrote: post #142
maldeh wrote: post #119

Earlier quoted context omitted.

A more poignant elegy to the modern landscape of compliance theater I have never seen: > Security Standards. Okta's ISMP includes adherance to and regular testing of the key controls, systems and procedures of its ISMP to validate that they are properly implemented and effective in addressing the threats and risks identified. Such testing includes: > a) Internal risk assessments; > b) ISO 27001, 27002, 27017 and 2701…

Yep. All these standards are tick boxing for liability. Nothing more. They are not effective security controls and never will be and should never be a measure of that.

I don't know if tick boxing was a spoonerism or intentional or a real thing but I love it and am stealing it.

(Upon further review, it appears to be the more UK way of saying it! Ha!)

Re: Updated Okta Statement on Lapsus$

#150

Post by horsawlarway »

gkop wrote: post #118
lalopalota wrote: post #45

Earlier quoted context omitted.

User's laptop is lost / stolen. User notifies supervisor. Supervisor (with admin authority on the account) notifies okta support and asks that the password be reset.

In this scenario, it’s more secure to require the user to request their own password reset via their registered email address.

There are cases where this is impossible.

Ex - You have gmail gated behind okta using MFA, and the lost device is the user's MFA (ex - phone using TOTP).

If the user has no session currently logged in on another device, they won't be able to create a session without their MFA device, and therefore won't be able to access their email.

How likely you are to hit this depends on org settings, like gmail session time, okta session time, mfa requirements, etc.

Ideally - they'd have backup codes somewhere... but most users won't (or they'll do things like store them in their email...)

Post reply on HN