Why the long name? Okta discloses auth bypass bug affecting 52-character usernames In potentially bad news for those with long names and/or employers with verbose domain names, Okta spotted a security hole that could have allowed crims to pass Okta AD/LDAP Delegated Authentication (DelAuth) using only a username. But why is that bad news for those with long usernames? Well, it's because the bug could be …
What browser are you using? It worked for me on Firefox/Linux.
Though if Twitter is going to start limiting support for browsers it is probably time to just directly quote the entire thing and not link to the site at all. And for people who distribute information via that platform to consider switching to Threads or Substack.
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.
Neither of which is very important because:
1. The email address is easily guessed: for most users, the username they pick is not going to be any harder to guess, and it's likely it will be the same one they use on any other site that demands one. For anyone who wants to have unique usernames, they can stick something on the end, fred+randomstring@example.com, and then it's unique again and still sends emails to the right place.
2. Almost every service is going to have an email anyway, they're just going to have a separate username. You still need to update that email any time you decide to stop having the previous email, because it's going to be used for notifications, auth checks, and various other important things. That is a good reason to switch all accounts whenever you know you're losing an email and not to rely on an email you could easily lose by changing ISP.
Failing when a username is longer than 51 characters is the problem here. Moaning about the use of email addresses as user ids misses the point. If it's supposed to support names longer than 51 characters it should have been tested with them.
Email addresses are often bad user ids but if your system only supports names of 50 characters do some basic validation on your inputs before you let people in.
> 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)
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.
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.
I routinely use passwords longer than 52 characters, whenever they are not limited to less. Same goes for usernames. Both are randomly generated and stored in a password manager. I also use TOTP or U2F token if supported. My password manager master password is longer than 52 characters.
So, OKTA would have likely trashed my attempts to be more secure than average. Nice, NOT.
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.
One has too wonder why nobody wrote a few unit tests for one of the most important parts of the system integrity.. eg tests for user + password combos from small to 100 chars or whate er the system limit for u/p in octa is.
Its also sad that bcrypt allows inputs greater than the hash length of 52. It shoudl force the callers to truncate their input to 52 chars, so they are actively aware of this hard limit instead of just "silently continuing".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
