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

Okta’s Investigation of the January 2022 Compromise

okta.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Okta’s Investigation of the January 2022 Compromise

#91

Post by athenot »

philjohn wrote: post #36

"were taken from a Sitel support engineer’s computer upon which an attacker had obtained remote access using RDP. This device was owned and managed by Sitel. The scenario here is analogous to walking away from your computer at a coffee shop" It really is not analogous at all. That RDP was enabled, let alone could be accessed from outside the network is worrying. To me this would appear that, to save a buck, they outs…

Maybe they meant:

The scenario here is analogous to walking away from your computer at a coffee shop... with your computer unlocked and logged in to various things

Re: Okta’s Investigation of the January 2022 Compromise

#92

Post by philjohn »

athenot wrote: post #91
philjohn wrote: post #36

"were taken from a Sitel support engineer’s computer upon which an attacker had obtained remote access using RDP. This device was owned and managed by Sitel. The scenario here is analogous to walking away from your computer at a coffee shop" It really is not analogous at all. That RDP was enabled, let alone could be accessed from outside the network is worrying. To me this would appear that, to save a buck, they outs…

Maybe they meant: The scenario here is analogous to walking away from your computer at a coffee shop... with your computer unlocked and logged in to various things

We can extend that - "after we've promised our customers that a computer would never be left unlocked and logged in to sensitive things in a public place, but would instead be behind multiple locked doors."

It's really not the "see, this is something you might do! It's not so bad!" out they thought it would be.

Re: Okta’s Investigation of the January 2022 Compromise

#93

Post by snowwrestler »

EMIRELADERO wrote: post #34
oxfordmale wrote: post #27

As communicated in stern words to Okta, my company unnecessarily spend many people hours on this. IT had to investigate if we were impacted by this, and on top of that issued a password reset for the entire company. A swift communication by Okta could have avoided this all together. It seems they care more about their shareholders than their customers.

> It seems they care more about their shareholders than their customers. isn't this how publicly-traded companies are supposed to work ? I agree on critizicing that approach and capitalism model, but I don't understand how that isn't common knowledge here.

No, it is not how publicly traded companies are supposed to work.

Publicly traded companies can set whatever priorities they want; the law only requires certain levels of accurate reporting. If shareholders think a company is too focused on customers, or not enough on shareholders, their options are simply to complain or sell the stock, or both.

Re: Okta’s Investigation of the January 2022 Compromise

#95

Post by staticelf »

nstart wrote: post #40

The entire message has a tone of being entirely true but not representative of the entire truth. And that just leaves us all hanging with more questions because it doesn't tell us what we really need to know. 2.5% of all customers were accessed by all Sintel employees for the period in question. How many customers did the particular affected Sintel employee access? They assessed all the actions that took place by the…

> 2.5% of all customers were accessed by all Sintel employees for the period in question. How many customers did the particular affected Sintel employee access?

Most likely, they don't write it because they may not know themselves. It is not certain that it gets logged perhaps?

Re: Okta’s Investigation of the January 2022 Compromise

#96

Post by Jxl180 »

thematrixturtle wrote: post #45

> The sharing of these screenshots is embarrassing for myself and the whole Okta team. It speaks volumes that their embarrassment is so important that it was the second sentence of the whole investigation, while there is literally not a single word of apology to the actual customers who were compromised .

They are individually reaching out to the actual customers who were compromised. You are making quite an assumption without seeing the individual emails.

Re: Okta’s Investigation of the January 2022 Compromise

#97

Post by thematrixturtle »

Jxl180 wrote: post #96
thematrixturtle wrote: post #45

> The sharing of these screenshots is embarrassing for myself and the whole Okta team. It speaks volumes that their embarrassment is so important that it was the second sentence of the whole investigation, while there is literally not a single word of apology to the actual customers who were compromised .

They are individually reaching out to the actual customers who were compromised. You are making quite an assumption without seeing the individual emails.

I'm not assuming anything, I'm commenting on the public post here.

Re: Okta’s Investigation of the January 2022 Compromise

#98

Post by sascha_sl »

kasey_junk wrote: post #85
sascha_sl wrote: post #69

Earlier quoted context omitted.

From circulating screenshots, and the omission in the listing here, it looks like they used this account to reset user passwords and MFA on a bunch of tenants. Not being able to create or delete users is meaningless.

Why is it a meaningless distinction to prevent account creation but allow password reset? Most commercial services allow unauthenticated password reset just by hitting a web form. It would send a password reset link to the correct place and the person would either ignore it, follow through and have a new password or report it. It doesn’t impact the service access at all. Meanwhile creating an account would allow new…

Apparently the "password reset" is more of a "password set" feature.

Re: Okta’s Investigation of the January 2022 Compromise

#99

Post by kasey_junk »

sascha_sl wrote: post #98
kasey_junk wrote: post #85

Earlier quoted context omitted.

Why is it a meaningless distinction to prevent account creation but allow password reset? Most commercial services allow unauthenticated password reset just by hitting a web form. It would send a password reset link to the correct place and the person would either ignore it, follow through and have a new password or report it. It doesn’t impact the service access at all. Meanwhile creating an account would allow new…

Apparently the "password reset" is more of a "password set" feature.

Where was that outlined? All of the screen dumps I saw showed what looked like a reset.
Post reply on HN