image

Inlogdienst Okta accepteerde elk wachtwoord bij zeer lange gebruikersnamen

zondag 3 november 2024, 08:54 door Redactie, 14 reacties

Een kwetsbaarheid bij inlogdienst Okta zorgde ervoor dat bij lange gebruikersnamen van 52 karakters of meer elk wachtwoord werd geaccepteerd. Dat heeft de dienst zelf bekendgemaakt. Het probleem is inmiddels verholpen. Okta biedt een platform waar wereldwijd duizenden bedrijven gebruik van maken om werknemers toegang tot systemen en applicaties te geven.

In de berichtgeving aan klanten laat Okta weten dat de kwetsbaarheid zich bevond in 'AD/LDAP DelAuth'. Delegated authentication (DelAuth) laat gebruikers inloggen bij Okta door de inloggegevens in te voeren van de Lightweight Directory Access Protocol (LDAP) user store van hun organisatie. Het laat gebruikers ook inloggen door de inloggegevens te gebruiken van de Active Directory (AD) of Windows networked single sign-on (SSO) van hun organisatie.

"Voor Okta orgs zonder MFA sign-on policies, gebruikmakend van gebruikersnamen van 52 karakters of meer, konden gebruikers inloggen door alleen de gebruiksnaam op te geven, ongeacht het ingevoerde wachtwoord", aldus het bericht aan klanten. Het beveiligingslek was sinds 23 juli in de betreffende inlogdienst aanwezig en klanten worden opgeroepen om te controleren of hier de afgelopen maanden geen misbruik van is gemaakt.

In een beveiligingsbulletin laat Okta weten dat het probleem ontstond bij het genereren van de cache key voor AD/LDAP DelAuth. "Het Bcrypt-algoritme werd gebruikt voor het genereren van de cache key, waarbij we een gecombineerde string van userid + gebruikersnaam + wachtwoord hashen. In bepaalde gevallen zorgde dit ervoor dat gebruikers konden inloggen door alleen de gebruikersnaam met de opgeslagen cache key van een vorige succesvolle authenticatie aan te bieden." Als oplossing voor het probleem is Okta overgestapt van het Bcrypt-algoritme naar PBKDF2.

Image

Reacties (14)
Gisteren, 09:11 door Anoniem
Je vraagt je echt af welke aap zoiets schrijft...
Gisteren, 11:00 door Anoniem
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt?
Mooi dat Okta achter deze fout is gekomen.

Inlognaam: Debestestuurluizittenaanwalendatisnooitandersgeweest
Gisteren, 15:44 door Tintin and Milou - Bijgewerkt: Gisteren, 15:44
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
welke aap begrijpt niet hoe uitzonderlijk de situatie is?

Is trouwens een bcrypt limitatie, wat de oorzaak is geweest.
Gisteren, 15:53 door Anoniem
Door Anoniem:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt?
Mooi dat Okta achter deze fout is gekomen.

Inlognaam: Debestestuurluizittenaanwalendatisnooitandersgeweest

Yep.
maar toch...

https://www.lysator.liu.se/c/ten-commandments.html

#5

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.

Niet helemaal hetzelfde (geen bufferoverflow), maar het fenomeen dat developers testen met 'foo' en 'bar' en niet langer is zo oud als de wereld.

Ik _zou_ me kunnen voorstellen dat iemand ergens een voor automation een gestructureerde "inlognaam" account maakt die lang uitpakt.
Gisteren, 16:04 door Anoniem
in 2017 had ik daarvoor al gewaarschuwd dat bcrypt 50-72 bytes user/pwd lengte had. niet erg nieuws dus
Gisteren, 21:59 door Anoniem
Door Anoniem:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt
Niet relevant of je het gebruikt. Het kan (blijkbaar) ingevoerd worden, DUS moet de meuk er tegen kunnen. DAT is relevant. Inderdaad... welke app maakt zoiets op die manier?
Is trouwens een bcrypt limitatie, wat de oorzaak is geweest.
En blijkbaar niet opgevallen bij de gebruikers van bcrypt. Dat maakt het niet minder triest...
Vandaag, 01:04 door Anoniem
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...

Er werken heel veel apen in software development. Dat zeg ik als zzper die bij een hoop bedrijven heeft mogen proeven. Voor een hoop mensen is het maar een baan en goed personeel is lastig te vinden.

Ook al zou dit automatisch getest moeten worden, is het wel vreemd dat dit niet eerder is opgemerkt. Ik zou verwachten dat bcrypt bij invoer die langer is dan mogelijk een foutmelding zou geven. Het is namelijk een foutieve invoer.
Vandaag, 11:35 door Anoniem
Door Anoniem:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt?
Mooi dat Okta achter deze fout is gekomen.

Inlognaam: Debestestuurluizittenaanwalendatisnooitandersgeweest
Door Tintin and Milou:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
welke aap begrijpt niet hoe uitzonderlijk de situatie is?

Is trouwens een bcrypt limitatie, wat de oorzaak is geweest.
Nou, nee, hier is geblunderd bij het toepassen ervan, en aangezien Okta zich nou juist specialiseert in inloggen is dit geen kleinigheid maar raakt het aan de kern van wat ze doen.

Het eerste dat me opviel is dat ze userid+gebruikersnaam+wachtwoord plaatsen in de 72 bytes die in bcrypt voor alleen een wachtwoord zijn bedoeld. Waarom gebruiken ze dan niet alleen het wachtwoord? Omdat het resultaat dient als key voor een cache die in een systeem voor gedelegeerde authenticatie wordt gebruikt. Oké, ik snap dat dan ook de userid in de cache-key verwerkt moet worden, en ik kan niet uitsluiten dat er redenen zijn om dat ook met de gebruikersnaam te doen.

Maar dan de implementatie ervan. Om in te zien dat in de gekozen opzet minder bytes voor het wachtwoord overblijven naarmate de gebruikersnaam langer wordt hoeft de ontwikkelaar echt niet briljant te zijn, alleen maar zorgvuldig: lees de documentatie van wat je gebruikt en sta stil bij wat voor consequenties dat heeft voor wat je bouwt. Dat geldt voor ontwikkelaars en voor degenen die hun werk controleren, en leidinggevenden die dat aansturen moeten bewaken dat dat niet afgeraffeld wordt maar serieus wordt gedaan.

Als die zorgvuldigheid was toegepast dan had men ofwel kunnen besluiten dat bcrypt niet geschikt is voor wat men ermee wilde doen en iets anders kunnen kiezen, ofwel had men kunnen bedenken hoe die beperking van 72 bytes onschadelijk kan worden gemaakt. Dat is niet eens moeilijk. Als wat in die 72 bytes wordt geplaatst niet rechtstreeks userid+gebruikersnaam+wachtwoord is maar bijvoorbeeld base64(sha256(userid+gebruikersnaam+wachtwoord)) kan het bcrypt-algoritme altijd gevoed worden met iets dat past én afhankelijk is van de volledige invoer.

Reacties als "mooi dat ze achter deze fout zijn gekomen" en "begrijp hoe uitzonderlijk dit is" slaan over dat dit opmerkelijk incompetent overkomt voor iets dat direct aan de kern raakt van wat Okta doet.
Vandaag, 11:47 door Erikje
Door Anoniem:
Door Anoniem:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt
Niet relevant of je het gebruikt. Het kan (blijkbaar) ingevoerd worden, DUS moet de meuk er tegen kunnen. DAT is relevant. Inderdaad... welke app maakt zoiets op die manier?
Is trouwens een bcrypt limitatie, wat de oorzaak is geweest.
En blijkbaar niet opgevallen bij de gebruikers van bcrypt. Dat maakt het niet minder triest...

Dit is een bekende beperking van Bcrypt. Maar dat was Okta blijkbaar ontgaan. Die hebben dus wat werk voor de boeg.
Vandaag, 12:12 door Anoniem
Door Anoniem: Er werken heel veel apen in software development. Dat zeg ik als zzper die bij een hoop bedrijven heeft mogen proeven. Voor een hoop mensen is het maar een baan en goed personeel is lastig te vinden.
De benodigde zorgvuldigheid hangt niet alleen van de kwaliteit van de mensen af, maar ook van de kwaliteit van de organisatie. In een cultuur van "niet nadenken maar meters maken" zitten je systemen ongetwijfeld barstens vol met dit soort fouten. Je gaat als een razende tot je in toenemende mate het lopende werk blijkt te moeten onderbreken om oude fouten te repareren. Als zorgvuldigheid en met elkaar meedenken in de cultuur zitten krijg je direct al veel betere resultaten met dezelfde mensen, en worden heel veel fouten opgelost op het moment dat mensen toch al met hun aandacht diep in het onderwerp zitten, nog voordat de software operationeel is. Bedenk dat voortdurend om moeten schakelen tussen onderwerpen die diepgang vergen uitputtend is, je verspilt er ladingen aan menselijke energie en dus capaciteit mee. Als dezelfde mensen dat minder hoeven te doen omdat ze de ruimte krijgen om hun werk meteen goed te doen dan lijken ze oppervlakkig gezien trager maar zijn ze uiteindelijk productiever en zitten er minder fouten in de operationele systemen.

Dat beeld van "apen" zou wel eens voor een belangrijk deel weer kunnen geven hoe werk wordt georganiseerd en aangestuurd, het hoeft niet zoveel te zeggen over de mensen die dat label opgeplakt krijgen.
Vandaag, 13:45 door Tintin and Milou - Bijgewerkt: Vandaag, 13:48
Door Anoniem:
Door Anoniem:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt?
Mooi dat Okta achter deze fout is gekomen.

Inlognaam: Debestestuurluizittenaanwalendatisnooitandersgeweest
Door Tintin and Milou:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
welke aap begrijpt niet hoe uitzonderlijk de situatie is?

Is trouwens een bcrypt limitatie, wat de oorzaak is geweest.
Nou, nee, hier is geblunderd bij het toepassen ervan, en aangezien Okta zich nou juist specialiseert in inloggen is dit geen kleinigheid maar raakt het aan de kern van wat ze doen.

Het eerste dat me opviel is dat ze userid+gebruikersnaam+wachtwoord plaatsen in de 72 bytes die in bcrypt voor alleen een wachtwoord zijn bedoeld. Waarom gebruiken ze dan niet alleen het wachtwoord? Omdat het resultaat dient als key voor een cache die in een systeem voor gedelegeerde authenticatie wordt gebruikt. Oké, ik snap dat dan ook de userid in de cache-key verwerkt moet worden, en ik kan niet uitsluiten dat er redenen zijn om dat ook met de gebruikersnaam te doen.

Maar dan de implementatie ervan. Om in te zien dat in de gekozen opzet minder bytes voor het wachtwoord overblijven naarmate de gebruikersnaam langer wordt hoeft de ontwikkelaar echt niet briljant te zijn, alleen maar zorgvuldig: lees de documentatie van wat je gebruikt en sta stil bij wat voor consequenties dat heeft voor wat je bouwt. Dat geldt voor ontwikkelaars en voor degenen die hun werk controleren, en leidinggevenden die dat aansturen moeten bewaken dat dat niet afgeraffeld wordt maar serieus wordt gedaan.

Als die zorgvuldigheid was toegepast dan had men ofwel kunnen besluiten dat bcrypt niet geschikt is voor wat men ermee wilde doen en iets anders kunnen kiezen, ofwel had men kunnen bedenken hoe die beperking van 72 bytes onschadelijk kan worden gemaakt. Dat is niet eens moeilijk. Als wat in die 72 bytes wordt geplaatst niet rechtstreeks userid+gebruikersnaam+wachtwoord is maar bijvoorbeeld base64(sha256(userid+gebruikersnaam+wachtwoord)) kan het bcrypt-algoritme altijd gevoed worden met iets dat past én afhankelijk is van de volledige invoer.

Reacties als "mooi dat ze achter deze fout zijn gekomen" en "begrijp hoe uitzonderlijk dit is" slaan over dat dit opmerkelijk incompetent overkomt voor iets dat direct aan de kern raakt van wat Okta doet.
Als ik dit goed begrijp, is dit ook niet echt een hele goede oplossing, maar dit is echter ver buiten mijn kennis gebied over dit onderwerp.

Als ik het goed begrijpt, zou het beter zijn om het wachtwoord met een salt te versleutelen.
hash = bcrypt(hmac_sha256(salt, password))

Ik zou dan de code kunnen bedenken:
hash = bcrypt(userid+gebruikersnaam+(hmac_sha256(userid, password)))
Maar dit is met mijn kennis hierover.

Hierbij is het wachtwoord altijd uniek, de salt zou natuurlijk ook het userid kunnen zijn, wat het helemaal uniek zal maken. Maar dit is met mijn kennis, wat ik vandaag hierop over opdoe.

https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length/184090#184090

Ik kan wel bedenken (vanuit mijn kennis) dat men de gebruikersnaam er in mee neemt. Deze kan namelijk ook veranderen, waarna je eigenlijk een re-authenticatie zou willen laten plaatst vinden en deze dus mee genomen zal moeten worden in de cache.
Vandaag, 13:56 door Anoniem
Door Anoniem:
Door Anoniem: Er werken heel veel apen in software development. Dat zeg ik als zzper die bij een hoop bedrijven heeft mogen proeven. Voor een hoop mensen is het maar een baan en goed personeel is lastig te vinden.
De benodigde zorgvuldigheid hangt niet alleen van de kwaliteit van de mensen af, maar ook van de kwaliteit van de organisatie. In een cultuur van "niet nadenken maar meters maken" zitten je systemen ongetwijfeld barstens vol met dit soort fouten. Je gaat als een razende tot je in toenemende mate het lopende werk blijkt te moeten onderbreken om oude fouten te repareren. Als zorgvuldigheid en met elkaar meedenken in de cultuur zitten krijg je direct al veel betere resultaten met dezelfde mensen, en worden heel veel fouten opgelost op het moment dat mensen toch al met hun aandacht diep in het onderwerp zitten, nog voordat de software operationeel is. Bedenk dat voortdurend om moeten schakelen tussen onderwerpen die diepgang vergen uitputtend is, je verspilt er ladingen aan menselijke energie en dus capaciteit mee. Als dezelfde mensen dat minder hoeven te doen omdat ze de ruimte krijgen om hun werk meteen goed te doen dan lijken ze oppervlakkig gezien trager maar zijn ze uiteindelijk productiever en zitten er minder fouten in de operationele systemen.

Dat beeld van "apen" zou wel eens voor een belangrijk deel weer kunnen geven hoe werk wordt georganiseerd en aangestuurd, het hoeft niet zoveel te zeggen over de mensen die dat label opgeplakt krijgen.

Wat je zegt telt zeker allemaal mee.
Je moet als ontwikkelaar wel in staat zijn om te zeggen 'nee, dit doe ik niet' of 'nee, dit heeft echt meer tijd nodig' in gevallen dat dat echt belangrijk is (zoals security zaken). Als er dan alsnog geen gehoor aan gegeven wordt dan kan dat ook verkeerd aflopen.
Laatst nog meegemaakt dat iemand op een stuk authenticatie/authorisatie aan het werk was gezet die de programmeertaal niet beheerste en niet wist hoe bcrypt gebruikt moest worden, en hier niemand vragen over had gesteld. Dan zie je er al snel uit als een "aap". Maar dan kijk ik toch wel eerder naar diegene de opdracht hebben gegeven.
Vandaag, 14:40 door Briolet - Bijgewerkt: Vandaag, 14:41
Door Anoniem:
Door Anoniem: Je vraagt je echt af welke aap zoiets schrijft...
Heb je wel eens een inlog naam van minimaal 52 karakters gebruikt?
Mooi dat Okta achter deze fout is gekomen.

Inlognaam: Debestestuurluizittenaanwalendatisnooitandersgeweest

Ik lees dat dit ook voor LDAP gebruikt wordt. Daar is het domein ook onderdeel van de gebruikersnaam. En bij een lange domeinnaam met ook nog een subdomein, komen die 52 karacters snel in zicht

Jan_met_de_korte_achternaam @ infobalie.beveiligingsbedrijf.nl

Dit zijn 26 + 1 + 31 = 58 karakters en is geen onrealistische lange gebruikersnaam.
Vandaag, 16:35 door Anoniem
Door Tintin and Milou: Als ik dit goed begrijp, is dit ook niet echt een hele goede oplossing, maar dit is echter ver buiten mijn kennis gebied over dit onderwerp.

Als ik het goed begrijpt, zou het beter zijn om het wachtwoord met een salt te versleutelen.
Bcrypt zelf gebruikt al een salt, het geheel wordt dus hoe dan ook al met een salt gehasht. Ik zie geen reden om een deel ervan ook weer van een salt te voorzien.

de salt zou natuurlijk ook het userid kunnen zijn
Nee, dat is geen goed idee, de salt moet een random waarde zijn, niet iets dat bekend of voorspelbaar is. De salt helpt een type aanval voorkomen dat met een zogenaamde "rainbow table" werkt.

Stel dat er geen salts worden gebruikt en je over een gigantische verzameling mogelijke wachtwoorden beschikt, misschien gestolen, misschien gegenereerd uit een woordenboek of zo. Je zou dan voorafgaand aan een nieuwe aanval van al die wachtwoorden een hash kunnen berekenen, en als je dan vervolgens een bestand met wachtwoord-hashes weet te bemachtigen kan je simpelweg door naar overeenkomende hashes te zoeken wachtwoorden vinden.

Een salt is simpelweg een random getal, dat voor elk opgeslagen wachtwoord opnieuw wordt bepaald. Het wachtwoord wordt samen met de salt gehasht, zodat hetzelfde wachtwoord met elke salt-waarde een andere hash krijgt. De hash wordt opgeslagen samen met de salt, en die gegevens moeten dus beslist niet algemeen toegankelijk zijn. Maar als iemand dan het bestand met wachtwoord-hashes toch weet te bemachtigen dan kan die geen bruikbare rainbow table klaar hebben staan omdat die de salts pas kent als de hashes zijn gestolen. Die kan dus pas aan het zware rekenwerk voor het kraken beginnen nadat de wachtwoord-database is gestolen. Dat geeft beheerders, die daar hopelijk sporen van aantreffen, kans om nog op tijd maatregelen te treffen.

Als de user-id gebruikt wordt als salt dan kan voor een of meer bekende of voorspelbare user-id's alsnog een werkende rainbow table gemaakt worden, en dan heeft de aanvaller toch weer een voorsprong. Dat is dus geen goed idee.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.