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

welke aap begrijpt niet hoe uitzonderlijk de situatie is?

Is trouwens een bcrypt limitatie, wat de oorzaak is geweest.

Yep.
maar toch...

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

#5


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.

in 2017 had ik daarvoor al gewaarschuwd dat bcrypt 50-72 bytes user/pwd lengte had. niet erg nieuws dus

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?En blijkbaar niet opgevallen bij de gebruikers van bcrypt. Dat maakt het niet minder triest...

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.

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.

Dit is een bekende beperking van Bcrypt. Maar dat was Okta blijkbaar ontgaan. Die hebben dus wat werk voor de boeg.

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.

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.

Ik zou dan de code kunnen bedenken:
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.

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.

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.

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.

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.

M.i. zijn rainbow tables niet meer van deze tijd.

Het hele rendement van een rainbow table is - opzoeken in een (groot) bestand is sneller dan nieuw berekenen.
Met de enorm toegenomen rekenkracht van GPUs (en het vrij traag gebleven zijn van opslag en ram geheugen) is die rendementsverhouding behoorlijk verschoven naar 'live hashen is sneller dan zoeken in disk+ram' .

Dat geldt voor meer 'pre-compute table' dingen - er was ooit een tijd dat even flink stampen om een tabel met sinus waarden te berekenen efficient was bij het tekenen van cirkels . Dat is heel lang geleden.

Waar salts _wel_ nog steeds nut hebben : ook bij het live hashen moet elke user individueel getest worden.

Zonder salting kun je elke gegenereerde hash meteen testen tegen het hele bestand aan password-hashes.
En alle gebruikers met een identiek password vallen er meteen uit - Alle Welkom01's hebben dezelfde hash.

Met een salt hebben alle Welkom01's NIET dezelfde hash , en moet de hash-tester Welkom01 proberen met ieder salt dat in de user-lijst voorkomt.

Wanneer het doel is "zoveel mogelijk passwords uit het bestand vinden" is dat erg veel meer werk.
(wanneer het doel is om dat ene magische account - root/administrator - te kraken , voegt een salt eigenlijk niks toe , want alle testen van woord en lettercombinaties worden alleen gebruikt bij de hash van dat ene account).


onvoorspelbaar is wat beter, maar m.i. is pre-computed tables gewoon geen ding meer.