Lapsus has responded https://img.guildedcdn.com/ContentMedia/e4149dc99f447074cb2c...
Updated Okta Statement on Lapsus$
31–40 of 239 posts
Re: Updated Okta Statement on Lapsus$
#32Earlier 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.
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$
#33Earlier 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.
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$
#34I 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.
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…
Re: Updated Okta Statement on Lapsus$
#36Earlier 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.
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.
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$
#38Earlier 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.
Re: Updated Okta Statement on Lapsus$
#39Earlier 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.
Re: Updated Okta Statement on Lapsus$
#40There it is.