Why the long name? Okta discloses auth bypass bug affecting 52-character usernames
- Reference: 1730719687
- News link: https://www.theregister.co.uk/2024/11/04/why_the_long_name_okta/
- Source link:
But why is that bad news for those with long usernames? Well, it's because the bug could be exploited only when a series of conditions were met, one of which being a username that was 52 characters or longer.
That condition is arguably the most unusual out of them all, although not entirely out of the realm of possibility if a user's work email address is used as a username, for example.
[1]
The exploit would also only work when the targeted account already had a successful login attempt stored, including the associated cache key generated by the bcrypt algorithm. Okta said that key would comprise a hashed string of a user's userId, username, and password.
[2]
[3]
That cache would also have to be used first, which Okta said in its advisory "can occur if the AD/LDAP agent was down or cannot be reached, for example, due to high network traffic." And yet another caveat was that multi-factor authentication (MFA) would also have to be disabled/never implemented for the bug to be active.
Okta discovered the issue on October 30 and fixed it the same day, although by that point it had been lingering for just over three months.
[4]
The security company advised customers to check their logs for any authentication attempts using 52 or more-character usernames all the way back to July 23. It didn't mention whether or not it was aware of any successful exploitation attempts.
[5]Amazon adds MFA to its enterprise email service ... eight years after launch
[6]Russian spies use remote desktop protocol files in unusual mass phishing drive
[7]Emergency patch: Cisco fixes bug under exploit in brute-force attacks
[8]FortiManager critical vulnerability under active attack
"Furthermore, Okta recommends all Okta customers implement [9]MFA at a minimum," the company added. "We also strongly encourage customers to enroll users in phishing-resistant authenticators (such as Okta Verify FastPass, FIDO2 WebAuthn, or PIV/CAC Smart Cards) and to enforce [10]phishing resistance for access to all applications."
Weighing in, Brave security engineer Yan Zhu [11]said that due to the bcrypt algorithm ignoring input after a specific length, if bcrypt is used to hash a username and password pair, then a sufficiently long username will mean any [12]password is accepted.
Passing the input through the SHA-256 algorithm can mitigate this, she said. ®
Get our [13]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zyj9t9FJjItPH3TcefDVTAAAAM8&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zyj9t9FJjItPH3TcefDVTAAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zyj9t9FJjItPH3TcefDVTAAAAM8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zyj9t9FJjItPH3TcefDVTAAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2024/10/31/amazon_mfa_workmail/
[6] https://www.theregister.com/2024/10/30/russia_wrangles_rdp_files_in/
[7] https://www.theregister.com/2024/10/24/cisco_bug_brute_force/
[8] https://www.theregister.com/2024/10/23/fortimanager_critical_vulnerability/
[9] https://www.theregister.com/2024/09/03/uk_trio_pleads_guilty_mfa_bypass/
[10] https://www.theregister.com/2024/10/30/russia_wrangles_rdp_files_in/
[11] https://x.com/bcrypt/status/1852575080989257893?s=51&t=lrK2ZKecQGyknpvtZGsKdQ
[12] https://www.theregister.com/2024/04/29/uk_lays_password_legislation/
[13] https://whitepapers.theregister.com/
I wonder...
...how many Okta customers don't have MFA implemented.
I'm filing this under "Reasons why passwords suck and you shouldn't rely on them", funny bug but no big deal at the end of the day.
Re: I wonder...
File it instead under "Reasons why email addresses are crap user IDs". Two other reasons are:
1. Email addresses are likely to be widely known. If I email people as fred@example.com then anyone who I've emailed, or has seen a forwarded email with that address can guess that that's my login on example.com's systems and possibly at other online sites then part of their work is done for them.
2. If I use fred@example com because example.com is an email provider, or even worse, an ISP, I'm stuck with them however I might wish to migrate because it's going to be a nightmare trying to change user IDs with every service where I've used that; it's even going to be a nightmare trying to remember all the places where I might have to change it.
Double hashing?
> Passing the input through the SHA-256 algorithm can mitigate this, she said.
Unless your sha256'ed password happens to end up starting with a null, in which case you're in for a world of pain : https://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html
Summary: your bcrypt implementation perhaps uses null-terminated strings to know when to stop, as is traditional. Hashing algorithims like sha256 can end up returning a raw byte string, and so a sha256 hash might end up starting with a null byte. Thus, re-hashing the hash might mean you're really calling bcrypt(\0MySuperSecretPasswordHash) might be functionally equivalent to bcrypt(\0MyTotallyDifferentPasswordHash), or indeed just bcrypt(\0)
Re: Double hashing?
I guess I should have dug in to bcrypt when I notices the mind-boggling character limit two and a half years ago. \o/
Okay, so here's the fix: sha256 has 32 byte. Take the output of that and run it through a Base64 encoder. That will have 44 characters. Run that through bcrypt.
Dumb hash implementation
Sounds like the hash is made with
generate_bcrypt(username + password)
Had it been done with
generate_bcrypt(password + username)
everthing would have been fine. Passwords are almost never 52 characters long, and even if the username is truncated, the most changeable bit (the name part) would survive the longest.
The most interesting part of this was the revelation (on Xittier) that Cloudflare have dropped Okta and have developed their own identity service.
Work Experience Cryptography
Some kid from the local Comprehensive on work experience, given an old edition of Bruce Schneier's Applied Cryptography * and told to cobble together some password hashing code.
Only reason this is farfetched is that arguably the kid would have done a better job. :)
Given Okta, and fellow travellers in this line of snake oil, literally hold the keys if a good many kingdoms one would have hoped, even expected, the critical code would have been subjected to some very rigorous scrutiny.
* curiously bcrypt() is based on blowfish which was devised by Schneier in the early 1990s.The scary bit is that bcrypt passphrases are constrained to [8..56] characters which given the vulnerability suggests how Okta were (mis)using bcrypt.
"... Yan Zhu said ..."
This browser is no longer supported. Please switch to a supported browser...