Okta-gebruikers met lange gebruikersnaam konden inloggen zonder wachtwoord

Authentiecatieplatform Okta heeft een kwetsbaarheid in zijn systemen opgelost waardoor gebruikers in specifieke situaties zonder wachtwoord konden inloggen. Het probleem trad op als de gebruikersnaam langer dan 52 tekens was en er al eerder succesvol was ingelogd.

Okta schrijft in een blogbericht dat de kwetsbaarheid zich voordeed tijdens het genereren van een cache key voor het AD/LDAP DelAuth-authenticatieprotocol. De kwetsbaarheid speelde volgens het bedrijf op als de agent niet te bereiken was of als er sprake was van veel internetverkeer. Het systeem viel bij gebruikers met een gebruikersnaam van meer dan 52 tekens dan terug op een oude opgeslagen inlogsleutel van een eerdere succesvolle inlogpoging. Hierdoor konden de gebruikers inloggen zonder hun wachtwoord in te voeren. De kwetsbaarheid was sinds 23 juli aanwezig in de authenticatiesystemen van het bedrijf en werd op 30 oktober gepatcht. Okta raadt klanten aan om logbestanden uit deze periode na te kijken.

Update, 12.00 uur: Inleiding aangepast en informatie aan het artikel toegevoegd om duidelijker te maken in welke specifieke situaties de kwetsbaarheid zich voordeed. Met dank aan de reactie van EnigmA-X.

Reacties (58)

[EnigmA-X]

Het probleem trad alleen op als de gebruikersnaam langer dan 52 tekens was en er al eerder succesvol was ingelogd.

Dit is niet helemaal accuraat. Dit gebeurde alleen als de delauth-cache werd gebruikt in bepaalde scenario's, dus niet altijd.

Zoals ook in het gelinkte report staat:

Severity Details

The vulnerability can be exploited if the agent is down and cannot be reached OR there is high traffic. This will result in the DelAuth hitting the cache first.

[Aerophobia1]

Een inlognaam van 50 karakters is op zich ook best moeilijk te raden.

[Cybje]

Behalve dan dat bij Okta gebruikersnamen standaard gewoon een e-mailadres zijn

[wica]

Dus ruime 3 maanden, kon je inloggen zonder password?
De track record van Okta is nou niet bepaald gerust stellend.

[Ryunoru]

Ligt eraan hoe lang ze er van af wisten en gewacht hebben om gebruikers te informeren over het probleem.

[Voutloos]

Het ontdekken en fixen was allebei op 30 oktober. Dus de reactietijd kan niet beter.

[wica]

Op tijd, ze hebben het misschien op de 30ste ontdekt en gefixit. Maar ik denk hadden ze hadden kunnen weten, wat de limieten van bcrypt zijn.

Wat op zijn minst sinds 2017 bekent was.

... if you keep under 50 characters, you will be fine everywhere. (Of course it would have been better if the algorithm did not have a length limitation in the first place.) ...

[Reactie gewijzigd door wica op 3 november 2024 15:14]

[kuurtjes]

Het gaat hier over de gebruikersnaam en niet het wachtwoord zelf.

[Argantonis]

Als je het gelinkte bericht (https://trust.okta.com/se...-authentication-username/) bekijkt dan zie je dat Okta met Bcrypt een cache key maakte van een combinatie van de username en password.

[kodak]

Als je als bedrijf weet dat je grove fouten maakt (wat al jaren duidelijk voor ze is door grote beveiligingsproblemen in de afgelopen jaren) dan hoort er ook een duidelijk reactie te zijn om tegen dit soort problemen zelf controle te doen en het te willen voorkomen. Dat lijkt op meerdere manieren nagelaten. Hun reactietijd is als gevolg dus niet slechts een paar uur maar maanden en langer. Ze lijken de vrijheid te nemen om keer op keer enorme risico's voor hun klanten te laten ontstaan, en laten bestaan, tot een ander ze op hun onverantwoordelijkheid wijst waardoor ze het niet meer kunnen negeren. Bedenk daarbij dat dit risico's zijn in de diensten waarom ze bestaan en ingehuurd worden. Ze krijgen betaald om veilige diensten te leveren, niet om het pas veilig te maken als anderen ze op hun verantwoordelijkheid wijst.

[wica]

Op tijd reageren en hun klanten waarschuwen. Was 1 jaar geleden ook al een probleem.
https://blog.cloudflare.c...-another-okta-compromise/

Op zijn minst, mag je gaan twijfelen over hun interne testen.

[djwice]

Laat ik het anders formuleren. Een security issues op hun default inlog pagina maakte een aantal jaar terug dat we met een groot internationaal bedrijf er voor kozen niet over gingen naar OKTA ondanks dat contracten getekend waren.
Die issues zijn nog niet gefixt.

[Azara]

In het nieuwsitem wordt aangegeven dat het lek op 30 oktober verholpen is, dus toch echt drie maanden lang een opening in de beveiliging.

De kwetsbaarheid was sinds 23 juli aanwezig in de authenticatiesystemen van het bedrijf en werd op 30 oktober gepatched.

[Sebazzz]

Typisch he. Allerlei mensen roepen dat je zelf niets met inlogs moet doen, dat je het beter kan uitbesteden. Maar het blijkt dat degene waaraan je het uitbesteed dan ook niet altijd de zaken op orde heeft. You had one job…

[Reactie gewijzigd door Sebazzz op 3 november 2024 11:21]

[BugBoy]

Dit was een echte edge-case. Als ik het artikel goed lees werd de cache alleen eerst bevraagd als er heel veel traffic was en/of je achterliggende AD/LDAP down was. Dan moet je daarbij ook nog eens een gebruikersnaam van meer dan 52 tekens hebben. Als je het zelf maakt, dan ga je hier nooit achterkomen.

[SPee]

Wel raar dat dit speelt bij een gebruikersnaam van 52 tekens en niet 50 tekens. Dus hebben ze ergens een controle op het aantal tekens? Dat kun je in je eigen oplossing dan voorkomen. Bv door maar max 50 tekens toe te staan.

Die 2 tekens extra zouden er niet voor moeten zorgen dat er altijd een timeout plaatsvind.

[BugBoy]

Dat is een limiet van "bcrypt", zie wica in 'Okta-gebruikers met lange gebruikersnaam konden inloggen zonder wachtwoord'.

[Sebazzz]

Exact, dat maakt het geen edge case maar iets wat in een code of security review gevonden had moeten worden.

[BugBoy]

Toch denk ik dat dit weinig schade heeft veroorzaakt. Een username van meer dan 52 tekens is niet echt gebruikelijk.

[Anoniem: 201953]

Ook niet wanneer het emailadres wordt gebruikt? Dat is niet ongebruikelijk.

[BugBoy]

Dat is den een e-mailadres als "[e-mail]". Zo lang is niet erg gangbaar...

[killercow]

Wellicht als functioneel adres niet, maar als functionele beschrijving van een of ander intern IAM account of API-user is dat helemaal niet zo gek.

[BugBoy]

Dat klopt, maar de kans dat iemand zo'n IAM account raadt is ook weer niet zo groot. Daarbij zullen applicaties vaak een andere flow gebruiken dan username/password voor OIDC authenticatie.

Ik wil het niet goedpraten, maar ik denk dat de impact minder groot is dan door sommigen hier wordt beweerd. Maar ik denk dat de meeste bedrijven hun audit-log gewoon moeten scannen. Dan weet je het of er vreemde clients hebben geautoriseerd. Geen idee of Okta audit-logs bijhoudt (verwacht het wel). Als je daar de langere e-mailadressen uithaalt, dan kan je kijken of die requests van "te verwachten" servers komt.

[Korben]

Bcrypt wordt als het goed is niet gebruikt voor gebruikersnamen, alleen voor wachtwoorden. Het lijkt er op dat de overeenkomst in de limiet toeval is.

[BugBoy]

Kijk maar in de blog. Ze gebruiken een combinatie van user-id, naam en wachtwoord en voeren die aan bcrypt om een "hash" te krijgen als key voor de cache.

[wica]

Ik denk dat het heel erg afhankelijk is van de grote van je bedrijf.
Ben je een klein MKB bedrijf, dan lijkt het mij niet, dat je de resources hebt om iets beters te maken.
Ben je een bedrijven met miljoen of zelfs miljarden omzet. Kan het wellicht verstandig zijn om het wel zelf in de hand te houden.

Is het zelfde als de Zenddesk backdoor van een paar dagen geleden.
https://gist.github.com/h...145fcee49d2f5e2b9d2cf2e52

Wanneer ben je groot genoeg, dat je het beter zelf kan doen?

[Rtificial]

Dat is een interessant punt.
Het is al sneller dan we tegenwoordig denken.
Een groot voordeel van een eigen oplossing is dat je niet kwetsbaar hoeft te zijn voor aanvallen op kwetsbaarheden van alom gebruikte oplossingen. Security-by-obscurity mij of meer. Je wordt dus met name kwetsbaar voor specifiek gerichte aanvallen. Voor veel organisaties kan dat nog wel eens meevallen.

Maar goed, nu de realiteit:
Dit soort toegangsplatforms worden ook regelmatig gebruikt voor maar een specifiek stuk van de (cloud)infrastructuur. Het is voor organisaties echt niet haalbaar om alles zelf in huis te onderhouden en ontwikkelen.
Denk aan finance en HR oplossingen, Office applicaties, etc.

[beerse]

Niet helemaal zonder wachtwoord. Het is meer zo iets als 'single sign on': De eerste keer moet je wel netjes inloggen en daarbij moet ook het netwerk meewerken. Pas als het netwerk niet mee werkt en je accountnaam is lang genoeg, dan kan je met een slechter netwerk de mogelijkheid hebben om toch soepel en zelfs zonder nog een keer je wachtwoord in te tikken in te loggen.

Okee, het is wel een handvat voor problemen maar er zijn een paar afhankelijkheden die misbruik toch lastig maakt. Voor spearfishing zal het een mogelijkheid zijn, voor drive-by misbruik zal het niet snel gebruikt worden.

Enneh, het zat er pas 3 maanden in dus daar waar het patch beleid niet goed genoeg was, is het ook geen probleem.

[Reactie gewijzigd door beerse op 4 november 2024 09:27]

[Cybje]

Dat is wat kort door de bocht. Het blog artikel meldt deze vereisten voor een succesvolle authenticatie zonder wachtwoord:

• Okta AD/LDAP delegated authentication is used
• MFA is not applied
• The username is 52 characters or longer
• The user previously authenticated creating a cache of the authentication
• The cache was used first, which can occur if the AD/LDAP agent was down or cannot be reached, for example, due to high network traffic
• The authentication occurred between July 23rd, 2024 and October 30th, 2024

Ik vind het in de huidige tijd alleen al zeer matig als er geen MFA is. Met Okta Verify is het ook weinig moeite om MFA te gebruiken.

[MachIII]

Vraagje:
Wie van degene die hier zitten gebruikt een gebruikersnaam van 52 tekens?

[wica]

52 tekens in ASCII ( 1 byte) , gebruik je UTF-8 welke wel tot 4 bytes kunnen zijn. is het slechts 13 tekens

[blahenazo]

Dat maak je er zelf van.

In de bron gaat het duidelijk over characters. Jij maakt er *poof* bytes van.

Dat gezegd zijnde, het is niet ongebruikelijk als je dan toch een SaaS als sso/idp provider gebruikt. Je een keuze maakt om ipv een interne -vrij korte- logonid, Men kiest voor het bedrijfsemailadres van de gebruiker als login.

En dan kan die 52 char grens toch wel snel in zicht komen.

[svenslootweg]

Het gaat hier om het gebruik van bcrypt, dus wica heeft wel degelijk gelijk, ondanks dat de bron het misschien anders omschrijft - het loopt tegen de input-limiet van bcrypt aan, en die is toch echt in bytes, niet in karakters. Wat overigens precies de reden is waarom ik mensen doorgaans adviseer om geen bcrypt te gebruiken maar iets als scrypt of argon2... dus tot zover het "uitbesteden aan experts", zullen we maar zeggen.

[Reactie gewijzigd door svenslootweg op 4 november 2024 12:55]

[Argantonis]

Dan gebruik je wel extreem uitzonderlijke characters.

[beeldbuijs]

Ik heb meegemaakt dat veel kortere gebruikersnamen geweigerd werden vanwege 'te lang'. Een gebruikersnaam van langer dan 52 oftewel minimaal 53 tekens is dus minstens 12345678901234567890123456789012345678901234567890123 lang.

Vraag me ook altijd af wie / hoe mensen hier überhaupt achter komen.

[angulardragon03]

Komt ook vaker voor dat je Okta gebruikersnaam daadwerkelijk je email adres is, waardoor je ook rekening mee moet houden met de lengte van je bedrijfsdomein. Mijn namen en bedrijfsnaam zijn al niet zo lang, en ik kom op een 24-karakter gebruikersnaam te zitten.

[Roel1966]

Was even zo aan het tellen maar de langste gebruikersnaam die ik gebruik is nog niet de helft, 23 tekens.

[genosis]

Nou de trust kunnen ze wel weghalen dus..

[bzzzt]

Omdat ze dit openbaar maken? Ik vertrouw bedrijven die dit soort meldingen stilletjes fixen zonder openheid van zaken te geven minder. Hier heb je tenminste nog de optie om te bepalen of de impact op jou relevant is en of er extra maatregelen nodig zijn.

[jmmk]

Probleem is, dat je niet wéét welke bedrijven dit stilletjes fixen.
Daarmee weet je ook niet welke bedrijven je minder zou moeten vertrouwen...

[bzzzt]

Ik weet wel dat deze club dus meer te vertrouwen is in plaats van minder zoals @genosis suggereert.

[kodak]

Ik lees geen openheid waarom ze de fout hebben laten ontstaan. Ik lees geen openheid waarom het 3 maanden moest duren voor ze het zelf door hadden. Ik lees geen openheid waarom ze de risico's op hun klanten afschuiven. Het bedrijf neemt daarbij op veel belangrijke punten waar hun dienstverlening om gaat en waarom ze betaald krijgen ook geen verantwoordelijkheid. En tenzij je als ondergrens stelt dat een bedrijf daar geen openheid en eigen verantwoordelijkheid in hoort te tonen voldoet dit niet snel aan noh vertrouwen kunnen hebben.

[bzzzt]

Ik lees geen openheid waarom ze de fout hebben laten ontstaan.

Kennelijk heb jij het recept voor bugvrije software gevonden. Misschien handig dat je dat dan even met Okta deelt...

Ik lees geen openheid waarom het 3 maanden moest duren voor ze het zelf door hadden.

Ik vind het knap dat ze dit redelijk weinig voorkomende scenario al binnen 3 maanden gevonden hebben. Gemiddeld doen bedrijven daar 3x zo lang over.

Ik lees geen openheid waarom ze de risico's op hun klanten afschuiven. Het bedrijf neemt daarbij op veel belangrijke punten waar hun dienstverlening om gaat en waarom ze betaald krijgen ook geen verantwoordelijkheid.

Waarom is dit risico op klanten afschuiven? Als klant wil je geïnformeerd zijn over de status van je beveiliging en als er problemen zijn zelf kunnen beslissen. Dat kan alleen als de leverancier open kaart speelt. Dit geeft klanten juist meer opties om adequaat te reageren.

En tenzij je als ondergrens stelt dat een bedrijf daar geen openheid en eigen verantwoordelijkheid in hoort te tonen voldoet dit niet snel aan noh vertrouwen kunnen hebben.

Welke verantwoordelijkheid hadden ze volgens jou moeten nemen? En wat anders moeten doen?

[kodak]

Ik stel op geen enkele manier dat hun diensten 100% vrij van fouten moet zijn. Maar als je als bedrijf opzettelijk kiest om te willen verdienen aan het beveiligen (en dus weg nemen van risico's) dan is deze grove fout laten ontstaan en maanden lang je klanten in gevaar brengen niet snel redelijk.

Als het nu kleine bugs waren dan had je een punt, maar dit is een grove fout in hun belangrijkste bestaansreden. En niet de eerste of de tweede in de afgelopen 3 jaar.

Als we jou redenatie volgen dan kan het bedrijf tal van dit soort grove fouten blijven maken omdat er altijd wel iemand grotere fouten maakt of er nog slechter mee om gaat.

[bzzzt]

Ik stel op geen enkele manier dat hun diensten 100% vrij van fouten moet zijn. Maar als je als bedrijf opzettelijk kiest om te willen verdienen aan het beveiligen (en dus weg nemen van risico's) dan is deze grove fout laten ontstaan en maanden lang je klanten in gevaar brengen niet snel redelijk.

Jij vindt een corner case die alleen voorkomt bij bijzonder lange usernames een 'grove fout'? En kan je aantoonbaar motiveren hoeveel gevaar klanten gelopen hebben?

Als het nu kleine bugs waren dan had je een punt, maar dit is een grove fout in hun belangrijkste bestaansreden. En niet de eerste of de tweede in de afgelopen 3 jaar.

Je bent je er van bewust dat sommige leveranciers gewoon een vaste dag in de maand hebben om security fixes uit te rollen? Ik moet de eerste software leverancier nog zien die geen fixes hoeft te doen en het lijstje van Okta is, gezien de hoeveelheid tools die ze beheren, eigenlijk nog best bescheiden qua hoeveelheid en impact.

Als we jou redenatie volgen dan kan het bedrijf tal van dit soort grove fouten blijven maken omdat er altijd wel iemand grotere fouten maakt of er nog slechter mee om gaat.

Waar heb ik gezegd dat ik niet beter verwacht of dat ik het goed vond? Enige stelling van mij was dat een bedrijf wat open kaart speelt in mijn ogen betrouwbaarder is...
Als ze hetzelfde probleem meerdere keren laten voorkomen is dat natuurlijk een stuk lastiger uit te leggen.

[BugBoy]

Ik ben heel benieuwd welke fout aan de oorsprong ligt dat dit enkel optreed bij een naam van meer dan 52 tekens. Het lijkt er op dat slechts de eerste 64 bytes gebruikt werden om de hash te bepalen. Volgens de blog wordt "userid:username:password" gebruikt als input voor de hash. Zal dan waarschijnlijk 10 bytes user ID zijn (wel een vreemd aantal) en twee separators.

[Reactie gewijzigd door BugBoy op 3 november 2024 11:27]

[Jerie]

Bcrypt limitatie: wica in 'Okta-gebruikers met lange gebruikersnaam konden inloggen zonder wachtwoord'

Hier legt @wica het uit.

[wica]

De onderliggende fout, noemen we bcrypt

[kamerplant]

Stel dat dit als consequentie zou hebben dat je serieuze financiële schade hebt, bijvoorbeeld omdat je aandelen portfolio of crypto hiermee wordt verkocht / verplaatst. Wie is dan verantwoordelijk? En hoe bewijs je dit vervolgens? Welke wetgeving geldt dan überhaupt? Hoe bewijs je dit überhaupt? Dit kan wel heel nasty uitpakken hoor.

[Frame164]

Ik vermoed dat hier geen wetgeving voor is, maar dat dit een civiele zaak wordt als er schade is geleden. Als je dit zakelijk gebruikt heb je een contract met SLA's en KPI's en bijbehorende penalties afgesproken.

[SPee]

Ik denk dat door

Het systeem viel bij gebruikers met een gebruikersnaam van meer dan 52 tekens dan terug op een oude opgeslagen inlogsleutel van een eerdere succesvolle inlogpoging.

ze argumenteren dat het veilig is, omdat die dan met een valide wachtwoord eerder is ingelogd.

Mij blijft dan alleen niet duidelijk of dat clientside is of serverside van de applicatie.
Want bij clientside het een klein probleem (want ooit daadwerkelijk succesvol ingelogd, dus grote kans dit keer ook). Bij die serverside is dat wel een probleem, want de hele authorisatie is daar niet gecontroleerd.
Dat zal dan een moeilijk procex worden. Want eerst zal de client dat met de aanbieder van de app moeten afhandelen, daarna zal die aanbieder dat met okta moeten regelen. Met allerlei eisen en voorwaarden zal dat niet makkelijk gaan.

[_Erikje_]

Okta is schreeuwend duur als oauth-provider. Dus het zal niet heel veel sites treffen.

[Left]

Langer dan 52 tekens? Waarom staan ze uberhaupt zulke lange gebruikersnamen toe? Het lijkt me dat een maximum van, zeg, 32 tekens wel genoeg is.

[Mijzelf]

Waarom zou je een arbitraire limiet op gebruikersnaam lengte willen? Zolang er geen technische redenen voor zijn lijkt me dat ongewenst en nodeloos limiterend. In jouw voorstel mag Jan Peter zijn e-mail adres [e-mail] niet als gebruikersnaam gebruiken.

[Left]

Waarom zou je een arbitraire limiet op gebruikersnaam lengte willen? Zolang er geen technische redenen voor zijn lijkt me dat ongewenst en nodeloos limiterend

Je geeft het antwoord op je vraag zelf al Je moet sowieso een limiet hebben op gebruikersnaam lengte, anders zouden gebruikers gebruikersnamen van een miljard tekens in kunnen voeren en het complete systeem lam leggen. Maar ook bij kortere lengtes kun je al technische problemen hebben, zoals het artikel aantoont.

[Martijn.C.V]

Ja, er is en theorieeen maximum. Maar in praktijk zijn die paar bytes (1byte ≈ 1 char) bijna verwaarloosbaar in usernames. Bij ons staat t op 64 tekens. En als je 255 wilt ofzo: leef je uit. Dat kleine beetje ruimte wat t in theorie extra inneemt kost niets, waar 1 klant die afhaakt door zoiets onbenulligs je al veel meer kost.

Voor usernames maakt de lengte erg weinig uit, maar voor wachtwoorden dan weer wel. Stel je haalt wachtwoorden netjes door een hasher zoals Bcrypt, dan kost dat compute. Door extreem lange teksten daar toe te staan, sta je open voor een DOS omdat je CPU bezig is met dat te Bcrypten. Dus daar is een grens van 100 (of 255) niet gek.

De sites die je vertellen dat je max 15chars mag doen dat om bovenstaande reden, maar zijn vergeten dat we in een andere tijd leven. Vroegah kostte het misschien wat meer aan compute, nu is het verwaarloosbaar. Niemand heeft een 100char wachtwoord, dus niemand gaat tegen de grens aan lopen, terwijl je wel jezelf hebt bescherm tegen die aanval.

[Reactie gewijzigd door Martijn.C.V op 4 november 2024 14:15]

[Die_ene_gast]

Mooi, net als die sites die geestig zeggen dat een wachtwoord langer dan 15 tekens te lang is.

[Unknown Alien]

Security en een email adres gebruiken als username :facepalm: nou voor hackers een eitje om alvast de helft van de inloggegevens te achterhalen. Bedrijfsnaam is vaak ook het domein. Linkedin en je bent er al.
Ok nu nog het wachtwoord...ohh jahh er zijn voor mij nog ontelbaar aantal websites\shops die geen passphrase accepteren en zien dat als onveilig

De kwetsbaarheid was sinds 23 juli aanwezig in de authenticatiesystemen van het bedrijf en werd op 30 oktober gepatcht.

Waren ze er al zolang van op de hoogte, voordat ze dit "lek" hebben gepatched?