Meta krijgt 91 miljoen euro boete voor opslaan van wachtwoorden in plaintext

De Ierse toezichthouder heeft Meta een boete van 91 miljoen euro opgelegd. Het socialemediabedrijf heeft tussen 2012 en 2019 de wachtwoorden van tot 600 miljoen Facebook- en Instagram-gebruikers in plaintext opgeslagen.

De Ierse toezichthouder DPC werd in 2019 op de hoogte gesteld dat de wachtwoorden van honderden miljoenen Facebook- en Instagram-gebruikers per ongeluk jarenlang onversleuteld op de interne systemen van Meta waren opgeslagen. De DPC heeft zijn onderzoek nu afgerond en concludeert dat het techbedrijf hiermee de AVG-wetgeving heeft geschonden.

De toezichthouder neemt het Meta niet alleen kwalijk dat de wachtwoorden in de eerste plaats niet goed beschermd waren, maar ook dat het bedrijf de DPC niet tijdig van het beveiligingslek op de hoogte heeft gesteld. Meta ontdekte de fout in januari 2019, maar lichtte de toezichthouder pas enkele maanden later in.

In dat jaar maakte Meta al bekend dat de wachtwoorden van 200 miljoen tot mogelijk 600 miljoen gebruikers van Facebook, Facebook Lite en Instagram vanaf 2012 per ongeluk in platte tekst op zijn interne systemen waren gelogd en opgeslagen. Daardoor konden duizenden medewerkers bij de wachtwoorden. De oorzaak lag bij fouten van applicaties voor het loggen van gegevens. Meta laat aan Reuters weten dat er geen bewijs is dat de wachtwoorden in die jaren zijn misbruikt.

Reacties (51)

[lvdgraaff]

Ik vind dit toch wel een aparte uitspraak. Waarom wordt een wachtwoord als een persoonsgegeven gezien? Persoonsgegevens moeten toch (redelijk) onlosmakelijk verbonden zijn aan je persoon? Een wachtwoord kan je ieder moment veranderen.

Los daarvan: dat wachtwoord zou natuurlijk niet hergebruikt moeten zijn bij andere diensten…

[Patrick_Wolf]

Maar het is wel jouw wachtwoord die toegang geeft tot al je persoonsgegevens. Een ieder kan zich hierdoor digitaal voordoen als jou.

[DataGhost]

Ja maar ook niet echt. Het is het wachtwoord wat enkel toegang geeft tot de persoonsgegevens die je bij Meta hebt gestald. Ik vermoed dat alle medewerkers die toegang gehad zouden hebben tot deze wachtwoorden sowieso de rest van de gegevens ook al in konden zien, mochten ze dat willen. Als jij je wachtwoord op een dusdanige manier hergebruikt dat deze in combinatie met je FB-account toegang geeft tot andere services en eventueel meer persoonsgegevens is dat eigenlijk een beetje je eigen schuld vind ik. Je wachtwoord is namelijk niet echt een persoonsgegeven (mijns inziens) maar een afspraak tussen jou en Meta dat degene die zich voor wilt doen als jou dat wachtwoord moet kunnen presenteren. Wachtwoorden hergebruiken is ook al sinds ruim voor 2019 not done meer.

[B64]

Een wachtwoord alleen is inderdaad niet direct herleidbaar naar een individu. Maar wachtwoorden zijn natuurlijk wel enorm waardevol om toegang te krijgen tot een account, waarmee vervolgens heel makkelijk identiteitsfraude gepleegd kan worden.

En vergis je niet, het gaat niet alleen om data die bij Meta gestald wordt. Er zijn talloze apps, websites en diensten waar je bij accounts kunt inloggen middels je Facebook account. Persoonlijk moet ik daar nooit wat van hebben, maar er zijn hele volksstammen die dat gebruiken.

Maar goed. eigenlijk is deze hele discussie niet erg zinvol: volgens de GDPR en AVG is een wachtwoord een persoonsgegeven.

[david-v]

Ik vermoed dat alle medewerkers die toegang gehad zouden hebben tot deze wachtwoorden sowieso de rest van de gegevens ook al in konden zien, mochten ze dat willen.

Nou dat mag ik hopen van niet. Ik heb toegang tot enorm veel metrieken en logging, maar ik kan niet bij de gegevens van gebruikers. Daar heb je weer andere mensen voor die gemachtigd zijn om dat te doen. Om een probleem op te lossen heb je soms ook deze mensen nodig die de gebruikers gegevens kunnen nakijken. Vier ogen principe zeg maar.

[Magere Hein]

Exactly! En daarom kunnen ze nu ook domweg claimen dat er 'geen bewijs is dat passwords zijn misbruikt'. De vraag is niet of er een bewijs is, maar of er een aanwijzing is, en eigenlijk gewoon dat er massaal de mogelijkheid aanwezig was.

[R4gnax]

Ik vind dit toch wel een aparte uitspraak. Waarom wordt een wachtwoord als een persoonsgegeven gezien? Persoonsgegevens moeten toch (redelijk) onlosmakelijk verbonden zijn aan je persoon? Een wachtwoord kan je ieder moment veranderen.

Los daarvan: dat wachtwoord zou natuurlijk niet hergebruikt moeten zijn bij andere diensten…

Het gaat er om dat de AVG/GDPR vereist dat persoonsgegevens adequaat beveiligd worden. Wachtwoorden in plain text opslaan valt niet onder de noemer 'adequaat,' evenals wachtwoorden in plain text naar buiten laten lekken via logging.

[david-v]

Heel goed verwoord, en daarom krijgen ze ook een boete.

[tvdijen]

Het is de combinatie van username + wachtwoord waarmee je je uniek identificeert bij een dienst. De twee zijn onlosmakelijk met elkaar verbonden en daarom is een unhashed wachtwoord ook een persoonsgegeven.

[Godlikev]

In zo’n gevallen zouden de medewerkers die hier medeplichtig aan zijn, ook aangepakt moeten worden, dit gaat gewoon vele grenzen over.

[david-v]

Bedoel je medeplichtig omdat ze een fout hebben gemaakt (bug) of omdat je verdenkt dat ze het express hebben gedaan?

Als software ontwikkelaar vind ik dit soort ongenuanceerde uitspraken best gevaarlijk. Bij opzet in het spel, ja, ben ik met je eens, maar ik vermoed dat hier geen opzet was.

Ik maak het ook wel eens mee dat er data in logs terechtkomt die eigenlijk niet nodig is voor monitoring of problem solving en die privacy gevoelig zou kunnen zijn. Dat is een fout in de manier waarop je de logs wegschrijft, een bug. Ontwikkelaars justitieel aanpakken bij bugs vind ik nogal ver gaan. Intern bij meta kan je wel aangepakt worden, maar dat is een ander verhaal.

[kuurtjes]

Daardoor konden duizenden medewerkers bij de wachtwoorden.

Hoe bezie je dit dan?

[wooha]

Blijkbaar hadden duizenden medewerkers toegang tot alle of een deel van de logbestanden. Dat betekent niet dat al die medewerkers daar misbruik van hebben gemaakt.

Medewerkers die er misbruik van hebben gemaakt moeten aangepakt worden.

Medewerkers die de passwords (per ongeluk) in de log terecht hebben laten komen hoeven er zelf uiteraard geen misbruik van gemaakt te hebben. Dat is van een heel andere orde.

Meta kan er op aangesproken worden dat ze dit als organisatie niet eerder hebben ontdekt.

Ook kan je je afvragen of zoveel medewerkers toegang tot de betreffende logbestanden nodig hebben.

[kuurtjes]

In 7 jaar tijd zou dat toch eens opgevallen moeten zijn?

Ik verdachtte Facebook toen ook al van plaintext wachtwoorden op slaan. Ergens in het login- of wachtwoord veranderen process merkte ik op dat het waarschijnlijk niet gehasht was.

[david-v]

Log regels bevatten enorm veel informatie, worden maar een beperkte periode bewaard en je hebt het vaak over miljoenen zoniet miljarden logregels per dag. Als dit in een deel van de logs staat waar je niet vaak naar kijkt (maar wel moet hebben voor het geval dat) dan kan dat best lang door blijven gaan zonder dat het je opvalt.

Ik denk niet dat meta met opzet dat gedaan heeft. Dat het zo lang heeft geduurd voordat het ontdekt werd is wel een ding, maar in die jaren was meta ook enorm aan het groeien. Ik praat het niet goed, naar ik kan me goed voorstellen dat het even duurde voordat ze alles onder controle hadden, waaronder dit.

[kuurtjes]

Als er duizenden mensen aan logs van mensen kunnen, en ook gewoon soms daar naar moeten kijken, denk je dan dat er in 7 jaar niet eens iemand is geweest die zich afvroeg waarom daar een wachtwoord staat? Een wachtwoord loggen is trouwens zeer opmerkelijk. Dat gebeurd via POST en wordt dus niet standaard gelogd.

Misschien zijn het inderdaad duizenden mensen die aan de server logs komen, maar dan nog is de kans dat dat in 7 jaar niet gezien is, zo klein, dat het niet echt een punt is dat je zou moeten verdedigen.

Er zijn maar 2 mogelijkheden. 1, het is gewoon 1 grote zooi van chaos. 2, het was al lang opgemerkt maar Meta zei mooi tegen de medewerkers dat het geen probleem was. Dat het voor een tijd onopgemerkt zou geweest zijn zou ik geloven als het niet ZEVEN JAAR lang zo was.

[We Are Borg]

Een wachtwoord loggen is trouwens zeer opmerkelijk. Dat gebeurd via POST en wordt dus niet standaard gelogd.

Ik vind dat niet zo opmerkelijk. Een serieuze applicatie zoals Facebook zal veel loggen. POST output is nuttig om te loggen. Ik vermoed (geen inzicht in) dat Tweakers bij bepaalde input ook de POST waardes zal loggen

[wooha]

Jij denkt blijkbaar dat er sprake was van kwade opzet en dat:

• medewerkers van Meta het in opdracht hebben geïmplementeerd
• andere medewerkers van Meta het opgevallen is
• die medewerkers het belangrijk genoeg vonden om te melden
• hen werd verteld dat het niet belangrijk was, of geheim moesten houden
• ze het niet belangrijk vonden om het verder bekend te maken, of dat niet durfden

Ik denk dat:

• het per ongeluk is ontstaan (generieke logging) of na een test in de code is blijven staan
• de mensen die het gezien hebben het belang er niet van in zagen

Ook denk ik dat Meta hier geen (groot) belang bij had, dat Meta een groot risico zou lopen dat het ooit uit zou komen en blijkbaar was het beperkt tot relatief weinig accounts.

Wat was hun doel hierbij? Gingen ze de wachtwoorden gebruiken om op andere systemen in te loggen? Gaven ze de wachtwoorden door aan derden (overheidsdiensten)?

Dan denk ik nog eerder dat er een werknemer was die hier iets mee wilde.

The DPC will publish the full Decision and further related information in due course.

Ik ben benieuwd naar dat volledige rapport. In wat er nu gepubliceerd is staat weinig inhoudelijks behalve dat het 'inadvertently' was. Blijkbaar is DPC niet overtuigd van een kwade opzet.

Wordt DPC misleid of doen ze mee?

[Luchtbakker]

Nog buiten dat; kan best zo zijn dat het opslaan in PT een bewuste keuze geweest kan zijn. Als dev heb je vaak hier alleen maar naar te luisteren.

[Jenk-Han]

Een kleine verzachtende omstandigheid voor degenen die de laatste alinea niet gelezen hebben: het gaat hier om applicaties voor het loggen van gegevens.
Het was dus niet bewust de password kolom in de users tabel. Desalniettemin...

[Mortis__Rigor]

Dat lijkt me net nog een verzwarende omstandigheden. Waarom zouden wachtwoorden gelogd moeten worden? Een wachtwoord zou ten eerste al niet in plain text mogen aankomen in de backend.

[edwinjm]

Ik heb het sterke vermoeden dat van elk gepost formulier alle gegevens van dat formulier gelogd worden, ongeacht de inhoud van het formulier. Dat er ook inlogformulieren zijn met gevoelige gegevens, daar is niet over nagedacht.

[R4gnax]

Ach ik heb ooit nog eens in de geminificeerde broncode van de Facebook Like widgets van weleer rondgeneusd om een compatibility probleem te proberen te debuggen. En daarbij kwam ik lappen code tegen die er verdacht veel op leken dat elke toetsaanslag in elk input veld dat er op de webpagina stond waarop Facebook's SDK ingeladen werd, afgevangen werd en naar hun servers doorgestuurd werd. Keylogger dus.

Jaren later nog eens een artikel tegengekomen waar een andere software ontwikkelaar er achter was gekomen dat soortgelijke code in elke webpagina geinjecteerd werd die via de embedded browser in de Android of iOS Facebook app zit, geopend werd.

Zij hebben daar destijds verhaal over gehaald en kregen als antwoord terug dat het een debug feature betrof en dat je er vanuit moest gaan dat die gegevens niet gebruikt werden.

[Reactie gewijzigd door R4gnax op 27 september 2024 20:26]

[Patrick_Wolf]

Maar ik kan mij wel voorstellen dat dit het meest gebruikte formulier op de website van de Meta websites is. Dan zou je toch wel eerder verwachten dat zoiets naar boven komt.

[Anoniem: 718943]

Wij loggen ook in fout situaties de body van een request, maar dat wordt toch echt wel automatisch ge-redacted. Die logging frameworks hebben daar gewoon kant-en-klare features voor.

7 jaar ongemerkt gevoelige data loggen kan echt niet, hoor. Dat betekent ook dat die logs nergens voor gebruikt zijn, anders had er wel iemand aan de bel getrokken.

[m_snel]

Dat ligt er maar aan, zo werd ik jaren nadat ik weg was bij een klant gebeld door collega’s. Hoe het zat met een oplossing waarbij ik gebruik maakte van een beveiligingsrisico omdat het anders onmogelijk was om een oplossing te implementeren.
Natuurlijk had ik deze oplossing doorgesproken met een de hoogste technische medewerker. Zijn antwoord was oh is dat nog niet opgelost.
En mijn antwoord was aan die collega’s, die persoon was eindverantwoordelijk en haalde zijn schouders op.
Dat is dan de praktijk.

[Jenk-Han]

Ik noem het verzachtend, omdat het hoogstwaarschijnlijk per ongeluk is gebeurd.
Ik zeg niet dat het gelogd "zou moeten worden".

[mbo]

Waarom niet, wil je de salt genereren en hashen langs de client side misschien?

[deadinspace]

Een wachtwoord zou ten eerste al niet in plain text mogen aankomen in de backend.

Zo werkt inloggen met een wachtwoord op basically elke website. Zoals deze waarop je je comment hebt gepost bijvoorbeeld.

[Mortis__Rigor]

Ik zie 2 opties waarbij het wachtwoord gelogd wordt:
- Ofwel wordt het bewust ergens in het process in de backend gelogd, en dan wisten ze bewust dat het gelogd werd en zijn ze daarmee zwaar in de fout gegaan.
- Ofwel komt dit voort omdat ze heel hun http request inclusief de formdata loggen, in dat laatste geval had het wachtwoord op zijn minst gehashed doorgestuurd moeten worden (en niet alleen uitgaan van de ssl versleuteling).

Zelfs al doet de frontend een simpele one-way hashing vooraleer het wachtwoord wordt doorgestuurd, ben je al een pak veiliger. Het interesseert de backend immers helemaal niet wat het wachtwoord net is. Het enige wat zij willen weten is: komt de gecompute waarde in onze database overeen met de nieuwe gecompute waarde. In dit geval is het al moeilijker voor de aanvaller om aan de hand van de doorgestuurde hash het echte wachtwoord terug te vinden en dit te gaan uitproberen op andere sites.

[deadinspace]

Ik snap wat je bedoelt hoor, maar de realiteit is dat zo'n beetje elke website het wachtwoord niet client-side hasht, en dat hij dus as-is gepost wordt via https.

Dat is simpelweg hoe inloggen op websites werkt. Doen alsof dat niet zo is helpt deze discussie niet verder.

[david-v]

ik probeer ook tussen de lijnen te lezen wat er nou staat aan het einde, vooral deze zin:

De oorzaak lag bij fouten van applicaties voor het loggen van gegevens

Bedoelen ze dat applicaties die gegevens loggen de wachtwoorden plaintext in de log databases/services wegschreven? Want dat is precies wat jij zegt. En dan ga ik me afvragen, ging het alleen om de wachtwoorden of ook om veel meer privacy gevoelige data?

Want toegang tot databases met gebruikers gegevens worden vaak wel beperkt en daar zit veel auditing op. Maar log databases....daar zit veel minder toezicht op omdat je normaal gesproken dit soort data daar niet moet/mag wegschrijven. Bij elke log regel in onze code krijg je van SonarCloud/SonarQube namelijk wel de vraag of je daar geen gevoelige data wegschrijft. Terecht ook want soms wordt lukraak zeer gevoelige data opgeslagen in de logs en dat wil je echt absoluut voorkomen.

[ISaFeeliN]

Wow. Ik sta hier van te kijken. Dit is wel zo'n beetje het ergste wat je kunt doen. Over zo'n lange periode ook. Ongelofelijk.

[wooha]

Je gaat uit van opzet van Meta. DPC spreekt over inadvertently, dus onbedoeld.

[downtime]

Het is zo'n bedrijf wat zo groot is geworden dat het ze ook geen fuck meer interesseert wat iemand ervan vindt. Het geld stroomt toch wel binnen.

[kodak]

Een miljoenenboete voor enkele maanden te laat melden, terwijl dat niet duidelijk uit maakt voor het kunnen afronden van het nodige onderzoek. 5 jaar heeft het afronden gekost, zonder duidelijke verantwoording hoe dat wel redelijk is. Want meestal is dat een reden om de boete te verlagen of sterk te betwijfelen wat het nut van melden dan nog is.

[Marcel Br]

Nee, de boete is voor de overtreding; het te laat melden is een verzwarende omstandigheid die eenvan de punten is. ZIe de link in het artikel

[kodak]

Het op tijd moeten informeren is een verplichting via artikel 33 van de GDPR. Dat het extra mee telt is omdat het een extra overtreding is. Of het bedrijf is op tijd en voldoet aan de wet, of het is te laat en het is een reden om het aan te rekenen.

[jinvanthee]

Hoe kan een megacorporatie als Meta zo'n amateuristische fout maken? Ongelofelijk dit...

[david-v]

Mijn ervaring is hoe groter het bedrijf hoe meer je van dit soort zaken tegenkomt. De genie van 100 mensen (de goeie techneuten) kan niet op tegen de domheid van 1000 zogenoemde ontwikkelaars (de minder goeie techneuten )

[phYzar]

Hoewel ze het al vanaf 2012 deden, was de AVG op basis waarvan ze zijn beboet pas van kracht vanaf 2018. Dat maakt het geen haar beter, maar suggereert in ieder geval niet zo'n langdurige overtreding.

https://www.autoriteitper...gemeen/de-avg-in-het-kort

De AVG is sinds 25 mei 2018 van toepassing in de hele Europese Unie (EU). De AVG geldt voor iedereen die persoonsgegevens verwerkt.

[zenlord]

Je hebt gelijk, maar ieder Europees land had voor de inwerkingtreding van de AVG al bepaalde gelijklopende wetgeving. Ik ken de Ierse voorloper niet van de AVG, maar misschien was deze fout van Meta ook onder de oude wet strafbaar.
(en zelfs als dat niet het geval is, hoeft de duurtijd van de overtreding niet meegenomen te worden in de overwegingen om de hoegrootheid van de boete vast te stellen - 600 miljoen data subjects + gevoelige informatie + 6 maanden na ontdekken pas rapporteren = voldoende voor een zware boete)

[bursche]

Ik zou voor zulke vergrijpen pleiten voor een boete van 50% van de jaaromzet. Wedden dat ze dan zorgen dat de boel op orde is?

[wooha]

En als het opzettelijk was geweest? Liquidatie?

[bursche]

Ik begrijp je reactie niet.

[wooha]

Ik was wat kortaf inderdaad.

De DPC schrijft dat de overtreding 'inadvertently' plaatsvond, wat inhoudt dat ze ervan uit gaat dat het niet opzettelijk gebeurde.

Een boete van 50% van de jaaromzet lijkt me erg hoog als er geen (bewezen) opzet in het spel is. Omzet is bijvoorbeeld veel hoger dan de winst die gemaakt wordt. Daarom vond ik dat voorstel nogal extreem.

Ik vraag me af hoe hoog je de boete of straf dan zou willen laten zijn als er wel opzet wordt aangetoond. Naar mijn idee moet die fors hoger zijn en dat trok ik extreem door naar liquidatie.

[Adriel]

En maar 100 miljoen euro boete. Blijkbaar niet genoeg.

[Raymond Deen]

Oei, hadden ze toch niet die ene eerste-jaars-stagiair op het implementeren van login moeten zetten....

[m_snel]

Er staat log gegevens, dat lijkt me iets anders dan inloggen. Maar je zou natuurlijk bij het inloggen de wachtwoorden niet in plain tekst moeten opslaan.
Dat iemand daar gebruik van kon maken was natuurlijk gewoon een design fout.