Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Wachtwoorden sommige GitHub-gebruikers werden door bug in plaintext opgeslagen

GitHub heeft het wachtwoord van sommige gebruikers gereset, omdat wachtwoorden door een bug via het interne logsysteem in plaintext werden opgeslagen. De wachtwoorden zijn niet in handen van derden gekomen.

GitHub meldt in een e-mail aan getroffen gebruikers dat de fout is ontdekt tijdens een reguliere audit. De website spreekt van 'een klein aantal' gebruikers waarvan het wachtwoord als platte tekst is opgeslagen door het logsysteem, maar noemt geen aantallen. De fout trad op bij het aanvragen van een wachtwoordreset.

Gebruikers waarvan het wachtwoord door de bug als plaintext in het logsysteem is terechtgekomen, moeten een nieuw wachtwoord instellen om weer in te loggen op de website. GitHub heeft de wachtwoorden zelf een reset gegeven.

Verdere technische details over de bug geeft GitHub niet. De website zegt dat de logs waarin de plaintextwachtwoorden stonden, op geen moment inzichtelijk zijn geweest voor derden. Ook binnen GitHub zelf zouden er weinig mensen zijn geweest met toegang tot de logs.

Door Julian Huijbregts

Nieuwsredacteur

02-05-2018 • 10:39

79 Linkedin Google+

Submitter: VanWilder

Reacties (79)

Wijzig sortering
Ik was een van de ongelukkigen, maar netjes opgelost door GitHub. De email van GitHub:

Hi there,

During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you'll need to reset your password to regain access to your account.

GitHub stores user passwords with secure cryptographic hashes (bcrypt). However, this recently introduced bug resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset. Rest assured, these passwords were not accessible to the public or other GitHub users at any time. Additionally, they were not accessible to the majority of GitHub staff and we have determined that it is very unlikely that any GitHub staff accessed these logs. GitHub does not intentionally store passwords in plaintext format. Instead, we use modern cryptographic methods to ensure passwords are stored securely in production. To note, GitHub has not been hacked or compromised in any way.

You can regain access to your account by resetting your password using the link below::
Haha ja, is ook een mooie dat je hem krijgt wanneer je zelf uit veiligheidsoverweging je wachtwoord elke X tijd veranderd (zelf een van deze mensen). Maar erg netjes verwoord in de mail en goed opgepakt door ze alvast maar onbruikbaar te maken.
Leuke achtergrond over bcrypt, welke toch al weer een flink aantal jaren meegaat, eerste release alweer in 1999!

https://security.stackexc...rypt-for-password-storage
Ik ben ook wel benieuwd wat verstaan wordt onder plain text in het geval van bcrypt hashed passwords;
Echt als plain text opslaan in logs kan dan alleen wanneer iemand zich registreert of inlogt. Heb je die acties dus niet gedaan, dan kan alleen het encrypted password zijn gelekt. Anders heeft het encrypten van de passwords sowieso geen zin, immers.

Dat maakt het niet minder erg wat er gebeurd is, maar het risico dat wachtwoorden op straat liggen is dan wel kleiner, omdat bcrypt encrypted passwords naar mijn weten voor het moment irreversible zijn.

Alleen wel spijtig dat door deze nalatigheid de gebruikers de dupe zijn.
Ik ben heel tevreden over het bestaan en de doorgrondigheid van deze audits. Ik kan me goed voor stellen waar de bug door veroorzaakt werd en hoe simpel het te overzien is. Ook goed hoe er op gereageerd is.
Toch was ik sceptisch op een mail met een link (die verhaspeld wordt door MSFT op een Outlook account, waardoor je niet direct de oorspronkelijke URL kan zien). Het had meer vertrouwen gewekt als ze hadden aangegeven dat je via de site een wachtwoord reset moet aanvragen.

Anyway, dat was mijn persoonlijke ervaring. Na wachtwoord gereset te hebben werkt het weer. Goed gehandeld inderdaad en dit soort fouten zijn inderdaad snel gemaakt!
De mail is als plain text verstuurd. Er staat dus ook alleen https://github.com/password_reset in de mail, zonder <a href="https://github.com/password_reset"> bijvoorbeeld.

Dat jouw e-mailclient er a) een link van maakt en b) die link ook nog eens verhaspeld, kun je moeilijk GitHub aanrekenen.

[Reactie gewijzigd door StephanVierkant op 2 mei 2018 11:24]

Er zijn zelfs regels voor Content-Disposition (minder relevant) en voor hoe de multipart/alternative en/of multipart/mixed (meer relevant) moet gepresenteerd worden (en indien er in dit geval enkel een text/plain (nieuwere versie) was, en dus geen text/html, dan moet de text/plain getoond worden). Links maken van URLs in text/plain is een feature/gimmick die afaik niet gespecifieerd is. Het verhaspelen is m.a.w. volledig de fout van de MUA (mail user agent).

De MUA's van Microsoft zitten hier echter op bijzonder veel vlakken fout. Hierdoor gaan andere MUA's zich helaas aanpassen aan die van Microsoft, waardoor Microsoft de fouten propagandeert en de fouten van Microsoft de de facto standaard gaan worden. Dat is spijtig want ze zitten vaak zo mottig slecht in elkaar dat het lachwekkend wordt. Natuurlijk wanneer je dan Microsoft's eigen standaarden gebruikt, of in dit geval van een Microsoft MUA naar een Microsoft MUA stuurt, ziet het er wel plots altijd goed uit.

Disclaimer: ik heb voor Nokia aan de E-mail clients voor de 770, N800, 810, N900 en N9 gewerkt.

[Reactie gewijzigd door freaxje op 2 mei 2018 12:11]

Je bedoelt dat dit misschien een phishing aanval mogelijk maakt? Je stuurt willekeurige GH gebruikers een mail die hier op lijkt maar dan met een link naar een nepsite waar je de gebruiker hun oude ww en een nieuw ww laat invullen. Zoiets?
Dat is het gevaarlijke scenario ja.

Waar @Djerro123 denk ik op doelt is dat je deze mail dismissed als phishing.
Het kan allebei en is een reëel probleem.

Dit is ook een van de redenen dat ik URLs wél belangrijk vind. Ze horen kort en leesbaar te zijn en duidelijk te wijzen naar de bron. Hierom gebruik ik ook liever geen url shorteners. En uiteraard altijd HTTPS. En hopelijk gewoon duidelijk zichtbaar (en dus niet verhaspeld!) in de statusbalk of een hint als je er overheen hovered.

In dit soort specifieke gevallen is het wellicht zelfs beter geen link te geven, maar instructies om zelf naar de website te gaan; dat is namelijk een heel effectief wapen tegen fishing. Krijg je een mail en twijfel je er aan of hij echt komt van de partij waarvan hij claimt te zijn? Negeer dan de link in de mail en ga zélf naar de website. Dit is het advies dat ik mijn moeder geef. Even 'rabobank' in je adresbalk typen en je komt vanzelf op de échte site van de Rabobank (browser toont onmiddelijk de juiste URL). Geen twijfel mogelijk.
Dan nog opletten dat de link die je in de text ziet staan wel overeenkomt met waar je naar wordt doorverwezen, dat je niet het volgende krijgt:

https://rabobank.nI

[Reactie gewijzigd door svenk91 op 2 mei 2018 12:02]

Daarom:
Even 'rabobank' in je adresbalk typen en je komt vanzelf op de échte site van de Rabobank (browser toont onmiddelijk de juiste URL)
Als je zélf de juiste term intyped in de adresbalk van je browser dan krijg je altijd de echte site (want die bezoek je regelmatig en staat dus in de history e.d.) en niet de fake site want jij typed dan geen '.ni' i,p,v, .nl.

Sowieso als de mail in plain tekst meldt:
Ga naar rabobank.nI en klik op wachtwoord resetten...
(ook al staat hier in mijn voorbeeld dus eigenlijk .ni (met hoofdletter i) en niet .nl, dan nog maakt dat niet uit want jij ziet dat niet eens en typed gewoon zélf .nl.

Type de naam van het bedrijf zélf in in je browser. Kan niet mis gaan. Simpelste advies tegen phishing dat er is wat mij betreft.
Yep, maar als men braaf de instructies uit de mail volgt, zal men hier ook in kunnen trappen:

Wegens veiligheidsoverwegingen maken we geen gebruik van links. Typ daarom de volgende link in uw internetbrowser om uw wachtwoord te veranderen: rabobank-wachtwoord.nl

Jouw tip om gewoon Rabobank in te typen omdat de browser history dit herkent, is op zich wel een aardige. Werkt natuurlijk alleen voor websites waar men al eerder is geweest.
Maar als je geen klant bent bij zeg Rabobank kun je al sowieso niet in zo'n phishing mail trappen natuurlijk.
Toch was ik sceptisch op een mail met een link (die verhaspeld wordt door MSFT op een Outlook account, waardoor je niet direct de oorspronkelijke URL kan zien). Het had meer vertrouwen gewekt als ze hadden aangegeven dat je via de site een wachtwoord reset moet aanvragen.
Dat is ook het eerste waar ik naar keek, zoals altijd. Bij veel mailprogramma's kun je dit on hover gewoon lezen dus vind ik het het probleem meer bij MS Outlook liggen.

Sowieso ben ik niet zo happig op het aanklikken van links in mailtjes vanwege al die tracking.
>> Het had meer vertrouwen gewekt als ze hadden aangegeven dat je via de site een wachtwoord reset moet aanvragen.

grappig ik zit hier net totaal anders in.
bv mijnoverheid.nl stuurt ook altijd van die emails waar geen directe link instaat, dus ik moet naar de browser, tab openen, mijn overheid in tikken of bookmark..
Allemaal zeer gebruikers onvriendelijk...

Terwijl het niks maar dan ook niks fixed. Want stell je voor dat er wel een email komt met kwade bedoelingen die zetten net wel een link er in.... En denk je nu echt dat de meeste mensen echt weten dat mijnoverheid dat niet doet? Het zou kunnen dat in de email net staat "voor gebruiksvriendelijkheid zetten we er vanaf nu wel een directe link er bij in"

Dus geen directe links er in fixed niks en is alleen maar zwaar irritant.
Dus geen directe links er in fixed niks en is alleen maar zwaar irritant.
Ik snap dat het voor jou irritant is (sterker nog, ik geef dit advies en ik vind het zelf zelfs irritant!). Maar toch ben ik het niet met deze stelling eens.

Mijn overheid is natuurlijk maar één site. Snap ik. Maar als bedrijven en overheden dit als policy zouden aannemen zou er een effect ontstaan waarbij gebruikers op een gegeven moment wel degelijk weten dat een link naar een pagina om je wachtwoord te herstellen niet 'normaal' is.

Bijvoorbeeld in the early days van het internet waren en veel kleine sites die je wachtwoord in plaintekst naar je mailden. Of dat men er aan de telefoon om vroeg. Dit waren ook van die 'gevaarlijke' gewoonten. Als normale bedrijven aan de telefoon naar je wachtwoord vragen, waarom zou je het dan verdacht vinden als dat gebeurt? Inmiddels doet vrijwel geen enkel bedrijf dit nog zo. En de meeste gebruikers zullen het nu dus ook gewoon verdacht vinden als naar hun wachtwoord gevraagd wordt.

Dus nee als Mijn overheid dit alleen doet dan gaat dit niet helpen, maar als dit policy wordt dan helpt het wel degelijk denk ik.
het gaat me niet eens om password reset

Het gaat gewoon "er staat een nieuw bericht in je inbox op mijn overheid"

Maar geen link niks.. Vind je het gek dat mensen die dingen totaal niet lezen

Hoe wet het ook proberen, phishing emails zullen altijd een link hebben en hoe we het ook zullen proberen er zullen altijd grote groepen mensen zijn die als ze denken dat dat een juiste email is dat ze op die link gaan klikken

Je moet mensen gewoon goed aanleren wat ze moeten doen nadat ze op link klikken (waar ze ook vandaan komen) niet proberen om het maar moeilijker en irritanter te maken
Hoe wet het ook proberen, phishing emails zullen altijd een link hebben en hoe we het ook zullen proberen er zullen altijd grote groepen mensen zijn die als ze denken dat dat een juiste email is dat ze op die link gaan klikken
En als alleen phishing mails deze praktijk gebruiken, dan kan elke mail met een link erin direct in je spam folder. Dus ik ben het met OddesE eens; als iedereen zich gewoon aan de best practices houdt, dan is dit probleem wel degelijk oplosbaar (en zonder elke gebruiker één voor één les te moeten geven over security, want dat is vechten tegen de bierkaai).
gaat echt niet werken...

Hoe werken nu vaak de reset password emails??

Precies je reset op de site, dan krijg je een email MET een link waar je op moet klikken om je nieuwe wachtwoord aan te kunnen maken..
Dat moet wel een link zijn in een email, want die is nog al speciaal...

Dus links in emails krijg je echt er niet uit en is gewoon ook zeerk ongebruiksvriendelijk dus ik hoop echt echt niet dat we daar naar toe gaan.
Maar password reset mails initieer je zelf. Jij gaat naar de site, geeft aan: wachtwoord vergeten en krijgt die mail.

Maar hier in het geval van Github initieert Github het proces door jou een mail te sturen. En dat is wat mij betreft een heel ander verhaal. Als je zelf op wachtwoord vergeten drukt weet je waar je mee bezig bent (dat wordt meestal ook uitgelegd; de mail wordt aangekondigd) en je verwacht die mail; daardor kun je die mail impliciet vertrouwen. Het moest wel heel stug zijn wil er net een phishing mail op precies dat moment van precies dat bedrijf binnenkomen.

Dus dat is waar het mij in deze om gaat. Sowieso, je wachtwoord beheer je zelf. Je kiest het zelf. Je verandert het zelf. Je kiest zelf wanneer je het verandert en hoe vaak. Etc. Dat zijn wat mij betreft sterke guiding principles (en ja ik weet dat die ingaan tegen sommige bestaande guidelines, maar die zijn ook niet altijd goed, zie xkcd).

Dit hier is een uitzonderlijke situatie. Github bepaalt voor jou dat je wachtwoord gereset moet worden. En dat doen ze door je een mail te sturen. Dit is op zich verdachte shit en dus moet Github er alles aan doen om te zorgen dat je als gebruiker instinctief begrijpt dat je niet genept wordt.

Net zoals banken zeggen 'wij vragen nooit om uw pincode', wat feitelijk onzin is want de Rabobank vraagt bij elke transactie om mijn pincode... Maar het verschil is het initiatief. Ik initieer die transacties. Dus ik vraag de Rabobank om mijn pincode te verifiëren. Als er iemand aanbelt die zegt dat hij van de rabobank is en dan om mijn pincode vraagt dan gaan wel alle alarmbellen rinkelen.

Er moet een common sense rond wachtwoord processen zijn die phishing moeilijker maken. Dus wat mij betreft als de site het initieert dan geen links. Als het goed is is dat een zeer zeldzaam iets en voor die ene keer maakt het niet uit dat er geen link in de mail staat.
Onzin. Je kunt prima een alfanumerieke code in plaintext ontvangen die je invult (of copy/paste) op de wachtwoord reset pagina. Sommige bedrijven doen het ook precies zo.
Zodra beveiliging comfortabel en makkelijk is, is hij niet goed.
Goede beveiliging laat je door hoepels springen voordat je bent waar je zijn moet. Als je die hoepels weghaalt omdat ze irritant zijn, verslechterd de beveiliging.

Beveiliging is inherent het tegenovergestelde van gebruiksvriendelijk.
tja en als je het niet gebruiksvriendelijk maakt wordt het niet gebruikt...

Volgens mij denken jullie nog steeds te veel in desktop mode.. Nu even waar meer en meer mensen op deze wereld alleen maar in werken: mobiel...

Stel ik krijg een email van reset password of nieuw bericht in de inbox bij mijnoverheid op mijn mobiel...
En daar zit niet direct een link in.. ik kan je nu al vertellen dat dan 99 van de 100 personen (inc ik) gewoon dan niks doe met de email of ik moet het echt echt nodig zijn??

Want op een mobiele telefoon is het nog veel irritanter dan op een desktop... Daar wil je echt niet switchen urls in tikken, navigeren, copy pasten van een code.....
Dan haakt echt 90% al af..
Toch geeft bijv. de Google Authenticator App je gewoon een alfanumerieke code. Ook veel bedrijven gebruiken SMS of andere text kanalen om je een code toe te sturen. Vaak alleen bij two-factor authenticatie, dat wel.

Ik ben het overigens niet eens dat gebruikersvriendelijker betekent minder veilig. Sleutels van 50 jaar geleden waren log en onveilig. Tegenwoordig heb je een pasje in je portemonee dat je niet eens meer uit je zak hoeft te halen, maar zonder dat pasje is dat slot vele malen moeilijker te openen dan een slot van 50 jaar geleden zonder sleutel.

Ik zou graag een stap verder gaan en stellen dat *goede* beveiliging een balans is. Alleen maar meer hoepels toevoegen helpt niet. Sterker nog het werkt averechts. Beveiliging MOET gebruiksvriendelijk zijn. Anders wordt het alleen gebruikt als het verplicht is. En de mens blijft de zwakste schakel. Die gaat een omweg zoeken zonder hoepels.

Weet je wie de beveiliging echt hebben verbeterd? Google en Facebook e.d. Al je berichtenverkeer over die diensten is sterk versleuteld. We weten al 50 jaar hoe dat moet maar pas sinds een jaar of 5 zien we serieus encryptie opkomen in de communicatie. Hell, zelfs deze post gaat versleuteld over de lijn! Daar mag je Google voor bedanken, want pas toen de search ranking in gevaar kwam ging tweakers over op https. En we mailen elkaar allemaal nog steeds in plaintext, maar je Facebook posts en WhatsApp berichten gaan wel versleuteld over de lijn. Dat is dan weer even de andere kant van de datagraaiers...
google authenticator gebruiken op de telefoon voor je telefoon zelf is niet te doen
Dat is ook weer zo'n verschrikkelijke gebruikers ervaring.. Ik gebruik google authenticator voor veel dingen (google zelf, amazon, enz) dus vat dit niet op als ik gebruik het niet, ik gebruik het best vaak.
Maar voor de telefoon zelf? dus ik zit op de telefoon en moet inloggen met google authenticator die op de telefoon zelf staat? Das echt een verschrikking en soms lukt het niet eens omdat het log scherm dat je voor je hebt weer weg is als je terug komt van de authenticator app...

Kijk een sms wordt vaak opgepakt door de app direct zelf, of die zie je in de notificaties zonder dat je er echt heen moet en dan kun je hem makkelijk even over tikken..

tuurlijk is het goed dat alles goed encrypted is, maar dat is hier niet de discussie
Ik zeg gewoon het moet ook gebruiksvriendelijk zijn, anders haken mensen echt af..
berichten op mijn overheid? het gebeurd gewoon heel vaak dat ik die heel lang niet zie
Want als ik het bericht eerst lees op mijn telefoon en ik kan er niet direct heen door op een link te klikken dan doe ik het niet, want de dan is het mij veel te veel moeite dus dan is het maar de vraag of ik die email nog weer zie of er aan denk als ik weer achter mijn laptop zit.

Maar goed bv mijnoverheid is gewoon niet handig op gezet, het was veel handiger als je gewoon kon zeggen forward alles naar mijn main email adres as is.... Mensen gaan geen berichten inbox bij houden wanneer dit niet echt hun main email is en er bijna nooit wat in komt.
ik zit op de telefoon en moet inloggen met google authenticator die op de telefoon zelf staat? Das echt een verschrikking en soms lukt het niet eens omdat het log scherm dat je voor je hebt weer weg is als je terug komt van de authenticator app...
Ja! Heb ik ook gehad ja. Dat is echt dramatisch idd.
Ik zeg gewoon het moet ook gebruiksvriendelijk zijn, anders haken mensen echt af..
Helemaal mee eens. Ik zeg dus zelfs dat die twee elkaar helemaal niet uitsluiten. Goede beveiliging is gebruikersvriendelijk. Dat is een vereiste. Want anders is het minder veilig omdat de mens nog steeds de zwakste schakel is dus als die mens het niet fijn vindt gaat die er omheen werken en ben je nog verder van huis.
berichten op mijn overheid?
Ja ik weet wat je bedoelt. Verschrikkelijk. En om even aan te geven hoe verschrikkelijk... Ik ben gewoon naar de berichtenbox gegaan en heb alle vinkjes uit gezet... Niet één dienst die zich bij die berichtenbox heeft aangesloten heeft van mij nog toestemming om hem te gebruiken. Ze sturen nu alles gewoon weer per papieren post. Hoezo mislukte feature?? Maar helaas is dit echt beter voor mij want ik ben dus ook te lui om erheen te gaan als er geen link staat, maar post van de overheid allemaal missen dat gaat vast niet goed aflopen dus dan maar weer gewoon ouderwets... :z
Google Prompt is wat dat betreft ook wel een fijn alternatief. :)
Als MijnOverheid nou gewoon ook een mobiele app had, dan kan je ook makkelijk de links overslaan, want dan is het weer gewoon een kwestie van de juiste app openen. :)

Dan zit je natuurlijk wel weer met het risico dat er wellicht third party apps met vergelijkbare namen verschijnen. ;)
Dit is wel een bugje die volgens mij tijdens een code review zichtbaar had moeten zijn. Dus beetje slordig is het wel.

Wel netjes opgelost en gecommuniceerd.
Je 'code review' verhaal gaat er vanuit dat ergens in de code iets staat als dit:
log.info('reset password to: ' + password);
maar dit is hoogstwaarschijnlijk niet het geval. Veel waarschijnlijker is het dat er ergens iets staat als dit:
function processRequest(request, settings) {
if (settings.requestLogger.enabled) {
settings.requestLogger.log(request);
}
// ....
}
Oftewel, code die er heel onschuldig uitziet.... Maar wel het wachtwoord naar de log file schrijft als dat toevallig in de request zat.

Hoe vaak heb je niet info ingelezen en ergens gelogged zonder precies te weten wat er in zat? Bijvoorbeeld de inhoud van een file, de parameters van een functie etc? Dit is hier hoogstwaarschijnlijk ook gebeurd.
GitHub is gebouwd met Ruby on Rails en dat logt standaard alle inkomende parameters voor een request. Standaard wordt de value van elke parameter key "password" vervangen door "[FILTERED]". Waarschijnlijk is de input name voor het wachtwoordveld gewijzigd in de HTML templates en heeft men deze instelling niet mee veranderd.

Een integratietest voor inloggen met een assertion dat het wachtwoord niet plaintext in de logs is terechtgekomen zal nu waarschijnlijk wel zijn toegevoegd :)

[Reactie gewijzigd door Rafe op 2 mei 2018 13:54]

Dan had het ook nog tijdens een test naar voren kunnen komen (er van uitgaande dat de log files op testomgevingen ook gechecked worden). :)
De configuratie van log files is nou net een van de zaken die vaak compleet anders is op productie als op test omgevingen. Het moge duidelijk zijn waarom denk ik; op een test omgeving wil je details wat er gebeurt zodat je kunt zien of je code goed is. Op productie, met miljoenen gebruikers die bezig zijn, wil je die details niet.

Oftewel, nee. Dit was (waarschijnlijk, ik ken de details niet) niet een domme fout maar een subtiel issue dat ontstaat uit een combinatie van software die wachtwoorden niet wegfilterd, software die generiek alles wat langskomt logt en de configuratie van de het logging systeem.

Ik ben de eerste die laks gedrag omtrent security laakbaar vindt. Ik heb in het verleden hier ook aangegeven dat er wat mij betreft strenge regels met bijbehorende boetes moeten komen om veiligheid af te dwingen. Maar het maakt in mijn boekje nogal wat uit of je gewoon je passwords niet gehashed hebt, of geen salt toegevoegd (je bent hier met wachtwoorden bezig! dus opletten!!) of dit. Dit zie ik als een menselijke fout die helaas maar al te makkelijk kan optreden.
De configuratie van log files is nou net een van de zaken die vaak compleet anders is op productie als op test omgevingen.
Gelukkig zit daartussen een acceptatieomgeving. Toch? ;)
Met weer andere instellingen. Wat is je punt?

Een omgeving kan hoogstens 'production-like' zijn. Of je er nu 1, 2, of 23 omgevingen tussen zet maakt niks uit. Je productieomgeving is anders. Misschien maak je het probleem zelfs wel erger; hoe meer omgevingen, hoe meer verschillende configs, hoe makkelijker een foutje er tussendoor slipt.
Toch zeer netjes dat ze dit melden, zit zelf ook niet onder de personen. Gebruik GitHub trouwens zelden de laatste tijd.
Ik heb nergens een melding gezien of gekregen.
Alleen de mensen wiens wachtwoord in plain text in logs was opgeslagen (waar onder mijne) hebben een email gekregen.
De comment van Plainside leek anders te beweren.
In het artikel:
De fout trad op bij het aanvragen van een wachtwoordreset. Gebruikers waarvan het wachtwoord door de bug als plaintext in het logsysteem is terechtgekomen, moeten een nieuw wachtwoord instellen om weer in te loggen op de website.
Dus alleen gebruikers die recent een wachtwoordreset aangevraagd hebben.
Dat klopt, maar FitsSprits reageert op Plainside's zin "Toch zeer netjes dat ze dit melden". Dat lijkt GitHub dus niet te hebben gedaan aan de rest van de wereld, ze lijken alleen de getroffen gebruikers te hebben bericht. Zo 'netjes' is dat niet naar mijn idee.
Ik zocht net ook al naar een blogpost o.i.d. van ze, maar die is er inderdaad niet. Vreemd, want ze snappen zelf toch ook wel dat het nieuws meteen uitkomt.
Dan is jouw account niet getroffen door deze bug.
De vraag is meer waarom ze het (schijnbaar) niet publiekelijk hebben gemeld. De verscheidene nieuwsberichten lijken gebaseerd te zijn op meldingen van de getroffen users over de e-mail die ze hebben ontvangen.
Voor dergelijke platformen vind ik het toch onbegrijpelijk dat zoiets kan gebeuren.
Zoiets zou nooit ofte nooit in een log terecht mogen komen en al zeker niet in plain text.
Jawel hoor, dat moet gewoon kunnen, niet aan de lopende band natuurlijk dan is het een ander verhaal...
Verwachten dat een platform geen bugs zal hebben is zoals verwachten dat je voor altijd je auto kan blijven gebruiken zonder ooit naar de garage te moeten gaan.

Software is iets dat constant evolueert, encryptie ook, bugs zijn dan snel geïntroduceerd. Is niet meer dan normaal, wat je wel verwacht van deze platformen is een professionele aanpak, wat dit (in mijn boekje) wel was.
Onbegrijpelijk is een groot woord.
Soms is het tijdens het opsporen van een bug handig om van alles te loggen. Wachtwoorden heb ikzelf nog nooit gelogd maar het is niet ondenkbaar te doen als bijvoorbeeld het aanmeldproces of iets dergelijks fout gaat. Als dat dan per ongeluk live gaat heb je een probleem, dus dat soort dingen doe je niet zomaar. Maar een ongelukje zit soms in een klein hoekje.
Wachtwoorden heb ikzelf nog nooit gelogd
Are you sure?

Er zijn honderd en één manieren hoe je wachtwoord in een log file terecht kan komen zonder dat je dit merkt. HTTP request loggers en Debug/trace loggers (die params van functies loggen) zijn maar twee voorbeelden.

Probeer dit eens. Open een terminal en type:
mysql -u root -p secret
Als je een MySQL install op de machine hebt met een root user met password secret ben je nu ingelogd. Handig. Maarreh... druk eens op pijl omhoog... ja daar heb je dat commando weer, uit de command history. Ook handig! Maar betekent dus wel dat je wachtwoord nu in de command history staat... die wellicht gelogd wordt.

Of een andere. Vaak worden servers geconfigureerd met environment variables. Dan wordt ergens gewoon een config in de env gezet en die wordt in de code dan weer opgepakt:

HOST=127.0.0.1
PORT=80
API_KEY=bn2-3n4vn-235vj

Oeps! Er hoeft maar ergens een stukje code de inhoud van de environment af te drukken en daar ga je weer! Nu staat de API_KEY gewoon plaintext in een log file!

Dit omgaan met secrets is een veel diepgaander probleem dan het in eerste instantie lijkt.
100% zeker weet ik het niet, nee. Maar ik heb in ieder geval zelf nog nooit code geschreven die wachtwoorden in een debug log schrijft. De kans is inderdaad aanwezig dat ik wel eens een sessie op mijn lokale werkstation heb gelogd met Fiddler, JMeter, SOAPUI of een dergelijke tool. Maar goed dat zijn tools die data lokaal opslaan.

Passwords zou je trouwens ook niet als string parameter aan een functie door moeten geven omdat strings (in ieder geval in managed talen zoals java en C#/.Net) nog een tijdje in het geheugen rondzwerven. Maar goed, dat is altijd nog minder erg dan expliciet wachtwoorden in een logfile wegschrijven.
Maarreh... druk eens op pijl omhoog... ja daar heb je dat commando weer, uit de command history.
Als je bash gebruikt kun je je commando voorgaan met een spatie, dan wordt deze niet opgeslagen in de command history. Bash logt inderdaad je history in .bash_history.
PowerShell en CMD misschien ook, maar weet ik niet zeker.

[Reactie gewijzigd door jimshatt op 2 mei 2018 16:19]

Ha ha sorry ik had het commando wellicht eerst even moeten testen. Ik typte het uit mijn hoofd in :)
Gelukkig niet de mijne. :)
Ik was ook een van de ongelukkige, heb 2 traps authentication aanstaan dus dat verkleint sowieso al de kans dat er iets naars gebeurt.

Verder netjes dat ze het melden, wachtwoord aanpassen is natuurlijk ook zo gedaan.
Wat mijn vraag is hierop: hoe kon je dan inloggen? ik neem aan dat ze wel probeerde het plaintext password te decrypten.
In de database stonden de wachtwoorden netjes crypted met Bcrypt. In de logfiles (die niet gebruikt worden om in te loggen..) stonden deze in sommige gevallen plain.
Netjes dat dit gemeld wordt door GitHub. Zelf ben ik een van de getroffene, maar acties zoals deze vergroten het vertrouwen bij een organisatie zoals deze.
Ik denk dat we niet willen weten hoe vaak een bug zoals deze voorkomt zonder dat het gemeld wordt. Mede door de media aandacht begrijp ik dat een bedrijf niet graag door het stof wilt bijten. Zelfs op tweakers merk ik al dat mensen hoog van de daken schreeuwen dat dit niet kan. Mocht dit bij een website gebeuren die meer door de "normale mens (niet IT'er)" wordt gebruikt, hebben mensen helemaal geen flauw idee wat er aan de hand is ("MIJN WACHTWOORDEN LIGGEN OP STRAAT") en zal er bij nieuwsuur die avond wel weer iemand zitten die er ook geen verstand van heeft zodat er nog meer onduidelijkheid wordt gecreëerd, hetzelfde zie je gebeuren bij het hele Facebook debacle van de afgelopen maand.

Al met al, probs voor GitHub voor het melden, en gebruik een wachtwoordmanager :)
Hoe is het toch mogelijk he... Op een bepaald moment - plotseling - werden die wachtwoorden opeens niet meer encrypted opgeslagen..
We snappen er zelf helemaal niets van..

Hoezo wachtwoorden in logs!
Encrypted of plaintext maakt daarvoor niet eens uit. Ze horen gewoon no-way in logs te belanden.

[Reactie gewijzigd door twilex op 2 mei 2018 20:18]

Hoe is het toch mogelijk he... Op een bepaald moment - plotseling - werden die wachtwoorden opeens niet meer encrypted opgeslagen..
Sorry maar dit klinkt wel heel paranoia. Vermoed je een complot of zo?

Hoe is het toch mogelijk? Hoe is het eigenlijk mogelijk dat dit niet aan de lopende band fout gaat zou ik zeggen. Want je wachtwoord mag dan wel encrypted in de database staan, maar als je inlogt biedt je wel gewoon je unencrypted password aan ter verificatie. Dit wachtwoord bewandelt een hele weg, van toetsaanslagen (keyloggers!) tot karakters op een scherm (onzichtbaar gemaakt met sterretjes) tot een HTTP request naar een server ergens anders ter wereld (hopelijk onderweg versleuteld met https), waar het binnenkomt in een generiek stukje software (die wellicht die binnenkomende request logt), die het weer doorstuurt naar een specifiek stukje code die de inlog afhandelt etc etc.

De data gaat over een heel traject en op grote stukken van dat traject kan het niet versleuteld worden/zijn. Op al die stukken loopt het gevaar. En er is eigenlijk geen standaard om aan een stukje data een vlaggetje te hangen dat zegt 'secret'. Request loggers filteren vaak op veldnaam parameters genaamd 'password' er uit maar ja dat is maar een naamsconventie. Om dit echt op te lossen moet je eigenlijk een soort metadata aan de data hangen, zoals het execute bit in linux, of read-only vlaggetjes. Net zoals we 'confidential' op een envelop zetten in de gewone post.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True