Okta fixes a flaw present since July 23, 2024, that let users log in under specific circumstances with any password if the account's username had 52+ characters
The vulnerability is fixed now, but Okta said that for three months it could've been used to access accounts with usernames stretching at least 52 characters long.
The VergeRichard Lawler
Context & Ripple Effects
This fix lands after Okta's 2023 support-system breach exposed files from 134 customers, with some subsequently targeted in session-hijacking attacks. Its later review also identified a badly configured service account as the breach's biggest contributor, underscoring how implementation details can become identity-security failures.
First-order effects
The authentication bypass is closed for affected long-username accounts, ending a condition under which an arbitrary password could authenticate.
Okta customers must treat the roughly three-month exposure window as a targeted identity-risk question, particularly for accounts meeting the username-length condition.
Second-order effects
Security teams using Okta may prioritize review of authentication activity for qualifying accounts and validate that unusual username formats do not create overlooked policy exceptions.
Identity providers are increasingly judged not only on preventing credential theft but on whether edge-case behavior in their authentication paths is found and remediated quickly.
If similar disclosures persist, enterprise buyers may place more weight on identity-platform testing, incident transparency, and configuration controls when selecting a central access provider.
The trend: Identity security is shifting toward continuous scrutiny of authentication edge cases and operational controls at the platforms that mediate enterprise access.
@mhoye@mastodon.social
@mhoye@mastodon.social on mastodon
Thirty six years almost to the day after the release of the Morris Worm, OKTA announces they've just patched a bug where you can just log in with no password if your username is too long. — Could we please, before the Morris Worm turns forty years old, make a habit of, god help…
@sitnik_en@mastodon.social
Andrey Sitnik on mastodon
The bcrypt hash function uses only the first 72 characters of the input. — So if you take the hash from name+password, the long name will truncate the password. — I think argon2 is better and you should switching to it. — https://trust.okta.com/... [image]
@deadparrot@mastodon.social
Stefan Baumgartner on mastodon
Wild: If your username has 52+ characters on Okta, there's a good chance it will bypass password checks 😬 — https://trust.okta.com/... [image]
@kmcquade3
Kinnaird McQuade on x
Okta allowing login bypass for any usernames with 52+ characters is insane Official Security Advisory: https://trust.okta.com/... [image]
@martin_heinz_
Martin Heinz on x
A friendly reminder that bcrypt has input character limit, so if you do ‘bcrypt(username + password)’ with sufficiently long username (~52+ chars) then you will effectively strip away the whole password.
@vicvijayakumar
Vic on x
My preliminary guess is that they create the password hash using username + salt + password and pass it to something with a max input limit that doesn't check it. Example: Bcrypt has a max input length of 72 bytes (anything longer is truncated). I'd love to read this PIR.
@bcrypt
Yan on x
reminder that the bcrypt hash function ignores input above a certain length! so if you do bcrypt(username || password) for some reason, a sufficiently long username will make it accept any password. to fix this you can sha256 the input first.
@lucasarruda
Lucas Arruda on x
Caching can also present security breaches: They used a simple ‘userId + username + password’ for the bcrypt cache key... Obviously, for big usernames, this is a security issue as the password is probably cut off of the cache key due to overflow / too many chars.
@sitnikcode
@sitnikcode on x
The bcrypt hash function uses only the first 72 characters of the input. So if you take the hash from name+password, the long name will truncate the password. I think argon2 is better and you should switching to it.
@gergelyorosz
Gergely Orosz on x
This is the third serious security breach at Okta in ~2 years. Okta sells security as a service: and yet it cannot secure itself. In the past we know it did not follow security 101. Yet another inexplainable incident. Who can trust Okta after all this?
@davideborall
David Eborall on x
I'm a regulation minimalist but it does feel like the IAM industry gets away with a lot of easy mistakes. Why are there no consequences? This ‘flaw’ is a pure lack of QA in the code.
@ahmadalfy
Ahmad Alfy on x
Honestly, if someone can remember a 52 character username, they should be allowed to login without a password
@mcstempel
@mcstempel on x
We made an April Fools' joke of shipping a “Log in with username” feature ( https://stytch.com/...) And Okta actually shipped it...
@andrewmohawk
@andrewmohawk on x
This okta bug is interesting since its specific on the length. My best guess is: SHA384 produces a 384bit (48-byte) hash. If it's URL-safe Base64 encoded without padding, it results in exactly 52 characters. (64 with non url safe) Any other ideas? https://trust.okta.com/...
@gergelyorosz
Gergely Orosz on x
This reads to me that Cloudflare dropped Okta after last year's unacceptable response from Okta. As a reminder: back then Okta did not act on a security breach for ~3 weeks its customers reported. And let it spread, not even warning other customers. Just... no words.