Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security IT

Okta Fixes Login Bypass Flaw Tied To Lengthy Usernames 32

Identity management firm Okta said Friday it has patched a critical authentication bypass vulnerability that affected customers using usernames longer than 52 characters in its AD/LDAP delegated authentication service.

The flaw, introduced on July 23 and fixed October 30, allowed attackers to authenticate using only a username if they had access to a previously cached key. The bug stemmed from Okta's use of the Bcrypt algorithm to generate cache keys from combined user credentials. The company switched to PBKDF2 to resolve the issue and urged affected customers to audit system logs.
This discussion has been archived. No new comments can be posted.

Okta Fixes Login Bypass Flaw Tied To Lengthy Usernames

Comments Filter:
  • This is a 2005 era bug.

    • Re:Amateurs (Score:5, Insightful)

      by krazee ( 10397245 ) on Friday November 01, 2024 @10:58PM (#64914015)

      This is a 2005 era bug.

      Seriously! How did the idea of hashing username + password with a hash function that truncates the input get pass any sort of security review, not alone testing?

      • There's a large company who switched from another method to Okta for its main, heavily used, web site and then 3 years later switched from Okta to another method due to the problems.

        Nothing was said publicly at the issues and costs, I guess for the same reason companies don't come out and say our 10 year SAP implementation failed at the cost of 45 million dollars.

        • I don't know the internals of that company, but my previous company did switch to Okta. I would be surprised if it cost too much money, it wasn't that hard to switch.
      • In their defense, there's a lot of security standards that are pretty vague, if they even mention it, of what to do when the input exceeds the compression function input size, and test vectors for that are more or less nonexistent. For an example, look at some of the stuff that TLS 1.3 feeds into its keep-hashing-everything-until-it-cries-uncle processing.
        • by gweihir ( 88907 )

          There is _no_ actually useful security standard that does not mandate full input validation. None at all. And all of them mandate that your data processing must be fit to deal with anything that pases the input validation.

          Seriously, this is amply covered. And as somebody that teaches application security and secure coding, I can assure you it is taught in these classes.

      • by gweihir ( 88907 )

        Simple: No security review, no meaningful testing and gross developper incompetence. At the very least 3 people utterly disgraced themselves here: The tester, the manager and the coder. Probably need to add the person that hired these clowns too. And then up the ladder.

    • If you are a security company, it's extra important to audit your code and do everything you can to make it secure. Okta doesn't do that.

      If you use Okta, you need to accept that their code is insecure, and you may get hacked in the future as a result. If you are ok with that, then keep using Okta.
    • by gweihir ( 88907 )

      A frigging buffer overflow? That is 1972!

      And in an authentication input. Negligence and incompetence does not get any more gross.

      • It's not even a buffer overflow.
        It's max len on the input being greater than the max len of the backend process, and the back end process having zero validation.

        Hell punch card era validation handled this.

  • by Mirnotoriety ( 10462951 ) on Friday November 01, 2024 @10:31PM (#64913995)
    Why wasn't this picked-up in testing? Is it because their was no testing. Release and wait for the end user to find the bugs and fix in the next version.
    • by gweihir ( 88907 )

      No testing, no review, no coder skills, no management skills. As fuckups go, this one is very hard to top. Well, Clownstroke qualifies on the same level of utter incompetence. Oh, and look, they _also_ pretend to do security software.

      Oh, and _every_ actually useful secure coding standard covers this as important.

      Something like this should cause unlimited liability for these idiots.

    • Why wasn't this picked-up in testing? Is it because their was no testing. Release and wait for the end user to find the bugs and fix in the next version.

      On the bright side, now they can use AI to create the code so nobody needs to even look to see if it is doing something so obnoxious. Crowdstrike and Okta are really showing us their security chops here.

  • by dohzer ( 867770 ) on Friday November 01, 2024 @11:45PM (#64914069)

    ForThoseWonderingHowLongA52CharUserNameIsHereYouGo69

    • Either limit usernames in both front end and back end, or accept that some users will enter more than you guess they should.

      Your app should be able to handle ANY allowed inputs.

      There is no exception to this rule, other than pure unadulterated incompetence.

      • The fact that bcrypt, which is generally held in high regards, has this issue is not a good one. The limit is 72 characters, so the quick and dirty workaround would be to hash the username+password using sha256 or even better, SHA-512, and use something other than hex to allow more than four bits per character. From there, use the bcrypt algorithm as usual.

        However, going to pbkdf2, argon, or yescrypt just seems like the best solution overall... algorithms that don't have this issue. However using a hash

        • by gweihir ( 88907 )

          Bcrypt is obsolete and should not be used anymore. Same for PBKDF2 and scrypt. To do this actually competently, use Argon2.

          • Thanks. Argon2 is, IIRC, the default for KeePass now, and is pretty simple to use:

            echo -n "hashthis" | argon2 "usethisassalt" -l 32 -t 1000

            Now the issue becomes how many iterations, the -t option. the above completes in about two seconds on my rickety old ARM CPU.

            This sure beats doing a FOR or WHILE loop running a bunch of sha512 rounds.

      • by gweihir ( 88907 )

        There is no exception to this rule, other than pure unadulterated incompetence.

        Exactly. There is no excuse for this. None. There will be explanations, but they will look really bad.

  • by Malay2bowman ( 10422660 ) on Saturday November 02, 2024 @12:18AM (#64914097)
    So my username that is a full copy/paste of "War and Peace" is going to cause problems?
  • My last security conscious company switched to PBKDF2 at least 10 years ago. wtf is wrong with these guys who are -supposed- to be super security pros??

    • by gweihir ( 88907 )

      There is a growing problem: Enterprises making security software that cannot even get basic coding and testing right. These clowns here, Clownstroke, many others. Just look at the weekly list of vulnerable firewalls, IDS systems, etc.

      My personal take is that the reason is that there is a large number of IT security "experts" that cannot code for shit, cannot do system administration and, on top, cannot do IT risk management and essentially have no business at all even being in this industry.

      • Fucking ridiculous.....

        When my company grew big enough to get serious about security I hired separate people for compliance, network, OS, application, and an experienced security team leader. I still recall the trigger for us to use PBKDF2 was an early customer's security team asking us about stuff like that before we had a security team and we were like, "Oh, uh, yeah, you're right, we'll upgrade to that". We were a fucking nobody startup, not a security company.

        Jfc, this is really mind blowing. Yes I k

  • ... concerning amateur level security flaws collected by Okta is nothing other than comical. This is a professional SaaS Indent/Auth/Auth service listed as some high level investment in stock and they're stumbling along like some amateur club struggling to manage some low-grade WordPress installation. This wouldn't be believeable as some piece of fiction let alone reality.

    Absolutely hilarious.

    • by gweihir ( 88907 )

      They probably have excellent marketing to be able to sell that utter crap engineering. Same as, for example, Clownstroke, Microshit, and many others.

    • The headlines about a well known organization are prominent because the organization is well known.

      There are vast numbers of cases where a roll-your-own solution was deployed to one instance and failed immediately, whereupon it was quietly deleted and never mentioned again. No one writes articles about a one-off failure, nor are multiple such failures ever collected into a larger narrative.

      tl;dr: selection bias

  • 2 critical breaches in less then 2 years, now a bug from 2005 ~finally~ gets fixed. This all from a company who's mission is to provide secure authentication. Colossal fail on all fronts. This is absolutely intolerable. This exceeds Equifax debacle of having a music major as their CIO... and ultimately flushing him after the infamous Equihacks breach. https://en.wikipedia.org/wiki/... [wikipedia.org]
    • by gweihir ( 88907 )

      The mission og Okta is not to provide secure authentication. Its mission is to separate the gullible from their money. The "secure authentication" stuff is just a means to do that and gets done just "good enough" for that. They are not the only rich peddler of crappy software by far. Look at Microsoft, Cloudstrike, and many others. When the customer is incompetent and there is no manufacturer liability, things tend to go that way.

  • Some 'security' company. Charlatans.

FORTUNE'S FUN FACTS TO KNOW AND TELL: A black panther is really a leopard that has a solid black coat rather then a spotted one.

Working...