okta vulnerability, grumbling about security
Another year, another critical vulnerability in Okta's infrastructure - an authentication bypass for users with long usernames, this time.
They ran up against bcrypt's input limit. You know, exactly the kind of footgun that causes people to recommend "don't try to roll your own authentication, outsource it to experts". Like... Okta. Who used bcrypt. And did it wrong.
I would really like for people to stop recommending external authentication providers. It's not actually *that* hard to implement authentication correctly for the vast majority of cases, if you take some time to read up on how to do it. Outsourcing isn't the answer here.
re: okta vulnerability, grumbling about security
@joepie91 Who told you Okta are experts?
Ever since they arrived on the scene, they have been doing crypto exactly like an amateur would.
re: okta vulnerability, grumbling about security
@riley I mean, this is true for basically every auth company I've seen, they're all snake oil, just some hide it better than others. But that hasn't stopped them from building an 'experts' reputation in the tech world.
re: okta vulnerability, grumbling about security
@joepie91 Yep. They're all hustlers, no hackers.
okta vulnerability, grumbling about security
@joepie91 Is it considered bad practice to use Bcrypt now? I've used it as part of homegrown authentication systems and wasn't aware of it being problematic to do so.
password hashing advice, re: okta vulnerability, grumbling about security
@AFriendlyBeagle Sort of. In and of itself, bcrypt is fine, in that it does what it says on the tin - but it has an input limit (72 bytes if memory serves) that is not widely known, and easily missed. Usually that's only a problem if you have a very long password (since it's essentially quietly truncated to 72 bytes), but if you're using it for a cache key like Okta was... 😐
My go-to recommendation for new systems nowadays is either argon2id, argon2i, or scrypt (in order of preference, depending on what your environment supports). They're more resistant to GPU cracking than bcrypt is. But as long as you aren't prone to the truncation issue (ie. you either restrict the input length or you just don't have such long inputs) there's no need to change what's already using bcrypt, the crypto itself is still considered sound.
Really the only things that warrant immediate change are anything using MD5, SHA1, and (due to the risk of incorrect implementation) anything homegrown using SHA256/SHA512. Third-party implementations of eg. PKBDF based on SHA256/SHA512 should be treated with scrutiny.
okta vulnerability, grumbling about security (2)
I will give Okta a tiny bit of credit for having used a cryptographic hash for their cache, which is something that many people get wrong. But that doesn't really help you if you then use the *wrong* cryptographic hash...