Conversation

Notices

1. Embed this notice
   Edward Dore (edward@social.spheron.one)'s status on Saturday, 09-Nov-2024 05:34:42 JST Edward Dore

   in reply to

   • V is for...

   @VModifiedMind Okta were concatenating the user ID, username and password, then feeding that string to bcrypt, the output of which was then used as the cache key.
   bcrypt will only take 72 bytes as the input, so presumably the user ID and delimiters were taking up 20 bytes and thus any username longer than 52 bytes was pushing the password completely out of the cache key.

   For a company who specialise in authentication, it's amazing the number of times that Okta have had major security incidents!

   • Embed this notice
     V is for... (vmodifiedmind@know.me.uk)'s status on Saturday, 09-Nov-2024 05:34:44 JST V is for...

     Sure there’s a great reason why the code was written such that regardless of length of username you may allow some length can magically skip the password phase.

     And these are the companies people sit in the middle doing SSO and MFA with. Or in other words. They’re a bloody vulnerability you’re adding to your stack you thought were helping you with identity and security management.

     Rocketman repeated this.