Sven Slootweg @joepie91@pixie.town

@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.

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...

@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.

@Scmbradley Probably nothing illustrates this better than Stormpath, a now-acquired "security and authentication company" that published an article about JWTs, half of which was outright factually incorrect and would never pass even cursory review by a security expert.

@Scmbradley Oh, certainly, and this holds true in that case. But in the past few years it's become a bit of a Thing for people in tech circles to say "authentication is too hard to get right, you should outsource it", which ignores that a) this is outsourcing to a company, not a library, which has wildly different consequences, b) none of these companies are actually competent or trustworthy, and c) you're more likely to fuck up the integration with their (usually overly complex) system than you are to fuck up a simple "hash the password" implementation.

@brucelawson And not the first time I've seen a stalebot close an accessibility issue because nobody in a dev team assigned it to themselves, either...