Live data from Hacker News

Updated Okta Statement on Lapsus$

okta.com

31–40 of 239 posts

Re: Updated Okta Statement on Lapsus$

#32
post #10

Earlier quoted context omitted.

> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

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 the password on an account to anything they wanted, but not retrieve an existing password.

This would be a big red flag to anyone who's observant and realizes that their password had been changed, but plenty of people would probably simply take it in stride and reset their password thinking they'd forgotten it. Either way the horse is out of the barn.

Re: Updated Okta Statement on Lapsus$

#33
post #10

Earlier quoted context omitted.

> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

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.

> What if they have access to some users' emails

Then those users are hosed anyway? They could always trigger a normal user-facing password reset email without any access to support systems.

Re: Updated Okta Statement on Lapsus$

#34
post #9

I mean, ultimately, it is now up to Lapsus$ to confirm this. If everything they say (and the Cloudflare post, also) is true then I don't think anyone should be worried.

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.

Re: Updated Okta Statement on Lapsus$

#35

> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit. What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned…

what I don’t get is, if support can’t do anything but “reset” which doesn’t expose the ability to gain access… how is support helping users? If a user can access their email, then they can reset themselves — surely? The idea that support can just trigger a reset email makes little sense. Perhaps Okta has some complex mechanisms that I am not aware of, but if this was any system I’ve ever worked on, an employee could…

[deleted]

Re: Updated Okta Statement on Lapsus$

#36
post #10

Earlier quoted context omitted.

> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

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.

Re: Updated Okta Statement on Lapsus$

#37

> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit. What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned…

It is not ambiguous. Facilitate means help. If a user cannot trigger the reset, support engineers can (help them) do it.

In what way would a Okta user be unable to trigger the reset while a support engineer could? If they are unable to access the Okta website where the password reset gets initiated, they are also unable to access the very same Okta website where the new password would be set.

And why use the more general word of "facilitate" when they could have been specific and say "trigger reset password flow" or similar.

Hence their statement is ambiguous.

Re: Updated Okta Statement on Lapsus$

#38
post #10

Earlier quoted context omitted.

> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

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.

Can't you request a reset without any special access? Many (but not all) applications have a publicly accessible log in page with a "Forgot your password?" link that takes an email as input.

Re: Updated Okta Statement on Lapsus$

#39
post #10

Earlier quoted context omitted.

> This means they could have reset anybody’s credentials and logged in Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.

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.

If they have access to some users' emails, they wouldn't need access to okta to reset the password and take control of the account. If a hacker has access to your email then you've already been pwnd.
Post reply on HN