Twitter og GitHub lagrede ellers hashede kodeord i klartekst. Gør du?

Mange andre organisationer gemmer også kodeord i klartekst uden at ane det, vurderer softwareudvikler Poul-Henning Kamp.

I denne uge kom det frem, at både Twitter og GitHub har gemt brugeres kodeord i klartekst.

Begge organisationer har godt nok på forsvarlig vis brugt bcrypt-algoritmen til at hashe kodeord med, så disse ikke har ligget i klar tekst.

Men både GitHub og senest Twitter har meddelt, at brugeres kodeord som følge af ikke nærmere definerede bugs alligevel er blevet opbevaret i klartekst i logfiler.

I en mail sendt til brugere af GitHub, fremgår det, at buggen skulle være relativt ny, mens CTO hos Twitter Parag Agrawai i et blog-indlæg ikke umiddelbart kommer nærmere ind på, hvor længe fejlen har eksisteret.

Meldingerne fra Twitter og GitHub kommer stort set samtidigt, og fejlen lader overordnet til at være den samme: kodeord i klartekst i logfiler

It-udvikler og Version2-blogger Poul-Henning Kamp, mener dog, der på det tekniske niveau er tale om forskellige bugs.

»Samme overordnede fejl, men utvivlsomt forskellige implementeringer i praksis,« skriver han i en mail.

GDPR

Twitter har stort set samtidig med beskeden om kodeords-bommerten udsendt en besked om opdaterede brugervilkår, der træder i kraft 25. maj. Altså samme dato som den europæiske persondataforordning GDPR træder i kraft.

En stribe virksomheder har i den senere tid haft travlt med informere brugere om opdaterede vilkår i lyset af GDPR.

På sub-redit’en /r/programming/ mener en bruger, at Twitter har opdaget problemet med kodeord i klartekst i forbindelse med en system revision i anledning af netop den europæiske persondatafordrning.

Poul-Henning Kamp kalder det »en nærliggende teori« at opdagelsen af kodeordene i klartekst hænger sammen med GDPR.

Mange har nok samme problem

Han er derudover helt sikker på, at der er masser af andre organisationer, der har kodeord i klartekst liggende uden at ane det.

»Der er i praksis ingen store organisationer, der har styr på, hvad der faktisk foregår på de nederste tekniske/systemadministrationslag af systemerne,« skriver han og tilføjer:

»I moradset af storage, routere, servere, VM, outsourcing og cloud er der aldrig nogen der har et klart overblik over hvem der i praksis kan gøre XYZ.«

Der kan være mange årsager til, at ellers forsvarligt hashede kodeord ender op i klartekst i en log, påpeger Poul-Henning Kamp. Blandt mulighederne nævner han:

  • Folk der kalder subrutiner, som skriver logfiler, de ikke har hørt om

  • Folk der kalder kode, som efter en opdatering, giver sig til at skrive logfiler, der ikke tidligere eksisterede

  • Folk der glemmer at slette debug-kode inden produktion

  • Folk der regner med at logfilerne er 'sikre'

  • Folk med hemmelige bijob, der går ud på at lave den slags fejl, startende med ‘selvstændige iværksættere’ som Se&Hør kilden hos IBM og sluttende med professionelle ‘plants’ fra FE, PET, CIA, NSA, Mossad etc.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
David Konrad

Derudover tror jeg som visse andre der ligger lidt "politik" bag Twitter og GitHub's udmeldinger. Det er jo tilsyneladende interne brølere vi blot informeres overfladisk om, alternativt ligger der mere alvorligt bag der ikke kommunikeres ud. Med mindre man hedder Trump o.lign må bekymringsgraden være ret lille. Chancen for at blive kompromitteret mindre end sandsynligheden for at blive ramt af lynet.

Magnus Jørgensen
4:

Hele formålet med at hashe og salte er jo netop at undgå at gemme passwordet på serveren. En programmør der udvikler en authentifikations mekanisme, må jo være specielt opmærksom på det faktum. Hvordan skal det så være en forklaring at vedkommende pludselig synes at en log fil er sikker? Udviklere med mangel på logisk rationalisering er lidt ligesom håndværker uden arme. De får ikke programmeret ret meget og slet ikke authentifikations mekanismer på store tjenester i skyen.

3

På de autentifikations mekanismer som jeg har udviklet har det aldrig slået mig at logge et kodeord. Ved test af koden har jeg altid blot logget det interessante, som er de tilstande min kode gennemgår. Det kunne feks. være digest ved oprettelse af brugeren og digest ved authentisering. Det kunne være om authentiseringen slår den rigtige bruger op i database og om sammenligning af digest er korrekt. Jeg vil selvfølgelig ikke udelukke at en udvikler kunne være så skødesløs at logge et kodeord. Men vedkommende må da være specielt opmærksom i sådan en sag.

Så jeg synes egentlig at #3 og #4 er mindst oplagt.

Anders Poulsen

Det er jo nok ikke sket ved at nogen med vilje har skrevet: log.writeLine(request.password)

En sansynlig forklaring kunne være nogen har hævet log-niveauet i whatever logging framework de nu end bruger for at debugge et problem uden at tænke over at frameworket så logger hele http-requestet INKLUSIVE indholdet af (authentication)cookies og alle form-felter. Det er i hvert fald en ret let fejl at begå.

Chresten Christensen

Det mest oplagte er for mig at se #5; da det vil være en lækkerbisken for en efterretningsvæsen, når man tage i betragtning den mænge oplysninger der er hos twitter GitHub og lignende. Husk på at efterretningsvæsen er at indsamle oplysninger i bredt forstand, samt spiongase og kontra spiongase.
Det falder også fint i hak, med det meme, politiker kør med Rusland, som den store skruk, og at der er et behov for større kontrol og undersøgelser af personer. Mens den virkelige grund er sandsynligvis nok mere kynisk og mørk; det handler om kontrol og styring af folket… :)

meme = https://en.wikipedia.org/wiki/Meme

Finn Aarup Nielsen

Findes der systemer der også hasher på klientsiden før den sendes til serveren? Det kunne give en smule ekstra beskyttelse: Kodeordet vil så ikke ligge i klartekst i en fejlagtig konfigureret serverlog og en person med adgang til kodeordsdatabase ville skulle baglæns igennem to hasher.

Problemet er vel at det kræver at Javascript kører på klienten.

Bjarne Nielsen

Findes der systemer der også hasher på klientsiden før den sendes til serveren?

En alternativ tilgang kunne f.eks. være SRP: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol.

In layman's terms, during SRP (or any other PAKE protocol) authentication, one party (the "client" or "user") demonstrates to another party (the "server") that they know the password, without sending the password itself, nor any other information from which the password can be broken. The password never leaves the client and is unknown to the server.

Sune Marcher

En sansynlig forklaring kunne være nogen har hævet log-niveauet i whatever logging framework de nu end bruger for at debugge et problem uden at tænke over at frameworket så logger hele http-requestet INKLUSIVE indholdet af (authentication)cookies og alle form-felter. Det er i hvert fald en ret let fejl at begå.


Det ville også være mit første bud, før konspirationsteorier.

Eller en søvnig udvikler der er kommet til at have password-feltet med i User-klassens toString metode, der så har været med i noget logning i stil med "User $user (breached in $leak) finally performed password-reset".

Kristian Thy

Det mest oplagte er for mig at se #5; da det vil være en lækkerbisken for en efterretningsvæsen, når man tage i betragtning den mænge oplysninger der er hos twitter GitHub og lignende.

Langt de fleste informationer på Twitter og Github er offentligt tilgængelige.

samt spiongase og kontra spiongase.

Jeg vidste ikke man var begyndt at rekruttere handyr af slægten Anser til efterretningsvirksomhed.

Kjeld Flarup Christensen

Det må være nogle stabile og fejlfri systemer, hvor systemadministratorene aldrig har behov for at kikke i loggen. Havde man gjort det, så havde man sikkert også opdaget kodeordene noget før.

Det kan selvfølgelig også være at logs er så fyldte med spam, at man aldrig opdager fejlen.

En løsning kunne være at sætte en scanner til at sammenholde logs med en liste af almindeligt anvendte kodeord.
Ligesom scanneren burde kunne genkende CPR numre.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder