Google logde deel van wachtwoorden van G Suite-gebruikers in plain text

Google meldt dat de wachtwoorden van een deel van zijn G Suite-gebruikers in zijn interne systemen zijn opgeslagen in platte tekst. Volgens het bedrijf gaat het om een fout die terug te voeren is tot 2005. Er zou geen bewijs zijn dat er misbruik is gemaakt van de situatie.

Google zegt dat het gaat om een fout uit 2005, toen de admin console een kopie van het onbeveiligde wachtwoord opsloeg. 'Deze praktijk voldoet niet aan onze standaarden', zegt het bedrijf. De wachtwoorden zouden wel in een beveiligde infrastructuur met encryptie zijn gebleven, maar dus zonder toepassing van hashing. 'Dit probleem is opgelost en we zien geen bewijs van ongewone toegang tot of misbruik van de getroffen wachtwoorden', zegt Google. Het gaat om een klein deel van G Suite-accounts; consumenten zijn niet getroffen. Google meldt dat het met beheerders samenwerkt om er zorg voor te dragen dat hun gebruikers hun wachtwoorden resetten.

Het bedrijf zegt dat het er ook achter kwam dat in januari 2019 per ongeluk een deel van de onbeveiligde wachtwoorden in een beveiligde omgeving zijn opgeslagen, waar ze maximaal veertien dagen zouden zijn opgeslagen. Ook dit probleem is volgens Google verholpen en ook in dit geval zou er geen bewijs zijn van misbruik. De internetgigant zegt dit te beschouwen als een geïsoleerd incident.

Dit voorval hangt samen met het feit dat domeinbeheerders voorheen tools kregen om wachtwoorden in te stellen en terug te halen. Google voerde dit in, omdat het naar eigen zeggen een veelgevraagde functie was. De tool, die zich bevond in de admin console, gaf beheerders de mogelijkheid om wachtwoorden te uploaden of handmatig in te stellen voor de gebruikers van hun bedrijf. Het doel was om hen te helpen om nieuwe gebruikers meteen op de eerste dagen hun accountinformatie te geven. Deze functionaliteit voor het herstellen van wachtwoorden bestaat niet meer in deze vorm.

Reacties (45)

[biglia]

Blijkbaar ben ik getroffen:

----

Google Customer Alert

Dear G Suite Administrator,

We are writing to inform you that between January 13, 2019 and May 9, 2019, an internal system that logged account signup information for diagnostic purposes, inadvertently stored one of your user account passwords in our encrypted systems in an unhashed format. This impacted the user account password provided during the initial account signup process. The log information was retained for 14 days following the signup process, and then was deleted according to our normal retention policies.

We have reviewed the login information for the account and have found no evidence that the unhashed password was misused.

The following is the user account impacted in your domain(s):

xxxxxx

Google Planned Action: for your security, starting tomorrow Wednesday, May 22, 2019 PT we will force a password change unless it has already been changed prior to that time.

Our password update methodology is as follows:

We will terminate the impacted user’s session and prompt the user to change their password at their next login.
In addition, starting Wednesday, May 29, 2019 PT we will reset the password for the user if they have not yet selected a new password or have not had a password reset. This user will need to follow your organization’s password recovery process. However, Super Admins will not be impacted. For information on password recovery options please refer to the following Help Center Article.

For further questions please contact Google Support and reference issue number xxxxxxx.

Sincerely,

The G Suite Team


--
Edit: Het betreft een account aangemaakt op 14 Januari 2019. Waarschijnlijk zullen alle accounts aangemaakt tussen de vermelde periode van 13/01 en 09/05 hier last van hebben. Vandaar ook dat mijn e-mail verschil met die van Remaged.

[Reactie gewijzigd door biglia op 23 juli 2024 07:06]

[Pep7777]

" stored one of your user account passwords in our encrypted systems in an unhashed format"

Als dat klopt dan is het wachtwoord dus NIET in plaintext opgeslagen.
Het is dan alleen niet als hash opgeslagen maar met dezelfde encryptie als de rest van de logs.
Dat betekend dat het voor google intern wel te lezen viel (unencrypted) maar niet zomaar voor iedereen.
Nog steeds niet ideaal maar ook niet zo dat iedereen het zo van het net had kunnen plukken.

En ja hackers die binnen zouden zitten bij google zouden dit ook kunnen zien etc.
Maar de kop van het artikel vind ik weer wat te kort door de bocht

[lepel]

Ja en nee. Het is wel in plaintext opgeslagen, alleen versleuteld. Dat is heel wat anders dan het wachtwoord hashen en salten.

Normaal gezien zou nooit iemand jouw wachtwoord moeten kunnen achterhalen aan de hand van de database. Encrypten betekent dat je het ook weer kunt decrypten, een wachtwoord dat je hasht en salt zou je nooit meer moeten kunnen decrypten.

Het gevaar zit hem dan ook juist in de google medewerkers. Laatst bleek toch ook dat Facebook wachtwoorden in plain text had opgeslagen. Die waren dan niet encypted maar er was evengoed ophef. Want niemand zou ooit ergens jouw wachtwoord moeten kunnen achterhalen, encrypted of niet.

[Pep7777]

Dat is wat ik bedoelde met 'zwak' en het zou ook zeker niet moeten gebeuren. En het is goed als alle ontwikkelaars onder ons hier ook van bewust worden

[Christoxz]

In de logs hoeven ze alsnog geen plaintext wachtwoorden te loggen.

Dat is fout en hebben ze dus wel gedaan.

[Pep7777]

Dat ben ik ook helemaal met je eens! En dat geven ze zelf ook toe.
Ik heb zelf ook wel logjes moeten maken voor een systeem, en passwords van test account meeloggen deed ik wel (om te kijken of het goed door het systeem heen ging) maar van andere accounts (en in release build) absoluut niet.

[pe0mot]

maar van andere accounts (en in release build) absoluut niet.

Hier zie ik het vaak misgaan. Bij jou vast niet, maar wel iets wat mis kan gaan.
In de test versies doen we het wel, in de alfa versies intern (of zitten daar al externen in?) ook, in de beta versie extern niet en in de final release ook niet.
Dit verwijderen van een functie plus het grondig verwijderen van alle logs wordt wel eens vergeten in alle haast door druk vanuit de commercie.

[Clemens123]

Wat je nog zou kunnen doen om jezelf tegen fouten te beschermen bij het maken van een website is twee keer hashen, op client en server side. Als je dan toch eens per ongeluk een wachtwoord in plain text logt, is er tenminste een hash overheen en zijn andere accounts die hetzelfde wachtwoord gebruiken tenminste veilig...(ok akkoord nu we allemaal ons fb of google account gebruiken om ergens in te loggen helpt dit ook niet geweldig)

[pe0mot]

Dank voor de reminder.
Ik heb inderdaad alle accounts via de 2FA authenticator app, behalve Google
Snel aangepast

[Verwijderd]

Als dat klopt dan is het wachtwoord dus NIET in plaintext opgeslagen.

Vergelijk dit met het opslaan van (een lijst met) wachtwoorden in een tekstbestand (of bijvoorbeeld een .xlsx) op een schijf die versleuteld is.
Op zich veilig voor eigen gebruik, als jij weet dat jij de enige bent die bij je wachtwoorden kan. Verlies je de disk/stick, of de laptop waar deze in zit is er als het goed is niets aan de hand.
Kan iemand echter bij de data op het volume dan kan deze persoon dus ook bij al je wachtwoorden. Niet erg als je dat zelf bent en het dus je eigen wachtwoorden zijn, wel erg als het de wachtwoorden zijn van iemand anders die jij helemaal niet hoort te weten.

(En daar zat dus de fout: het was zo ontworpen dat het (lang geleden) de bedoeling was dat de wachtwoorden wél gelezen konden worden, voor ondersteuningsdoeleinden.)

[begintmeta]

Letterlijk in plain text worden zaken natuurlijk nooit opgeslagen in computers, het wordt vrijwel altijd in bits opgeslagen met een bepaalde encoding naar de textwaarde. Maar zo moet plain text denk ik niet worden opgevat, plain text kan ook prima binnen encrypted omgeving bestaan (van buiten die omgeving gezien wordt dienolain text dan echter niet als zodanig herkend)

Dat het opgeslagen was in de versleutelde systemen, zal de hoeveelheid mensen die de wachtwoorden daadwerkelijk kunnen lezen vermoedelijk wel hebben beperkt, maar daarover laat men zich eigenlijk niet uit (hebben enkele, tientallen of honderden personen de sleutel tot die versleutelde systemen?).

[Stoelpoot]

Ik moet wel zeggen dat het een hele nette mail is en goede acties worden gedaan om je veiligheid weer op orde te stellen. Wachtwoorden in logfiles zijn altijd een ongelukkige fout

[boswandeling]

Idd deze mail kreeg ik gisteren ook.

[Remaged]

Ter info; wij kregen gisteravond de volgende email binnen van Google G Suite:

---
Google Customer Alert

Dear G Suite Administrator,

We are writing to inform you that due to legacy functionality that enabled customer Domain Admins to view passwords, some of your users’ passwords were stored in our encrypted systems in an unhashed format. This primarily impacted system generated or admin generated passwords intended for one-time use.

We have reviewed the login information for the user account(s) and have found no evidence that the unhashed passwords were misused.

The following is the list of users impacted in your domain(s): [e-mail]

Google Planned Action: for your security, starting tomorrow Wednesday May 22, 2019 PT we will force a password change unless it has already been changed prior to that time.

Our password update methodology is as follows:

Users With Single Sign On: We will reset their password by changing it to a randomly generated secure value. Please note that this will have no effect on their ability to log in using their Single Sign On credentials.
Other Users and Super Admins: We will terminate their sessions and prompt users to change their password at their next login.

In addition, starting Wednesday, May 29, 2019 PT we will reset the password for users that have not yet selected a new password or have not had a password reset. These users will need to follow your organization’s password recovery process. Super Admins will not be impacted. For information on password recovery options please refer to the following Help Center Article.
For further questions please contact Google Support and reference issue number xxxxxxxx.

Sincerely,

The G Suite Team
---

[Reactie gewijzigd door Remaged op 23 juli 2024 07:06]

[Vliegenier04]

Lijkt erop dat er steeds vaker dit soort "foutjes" worden ontdekt. Facebook ook al. Vraag me serieus af waarom dat 1) nu pas ontdekt is & 2) waarom het zo moeilijk is om hasing toe te voegen.
Privacy lijkt niet zo belangrijk te zijn helaas...

[phYzar]

2) waarom het zo moeilijk is om hasing toe te voegen.

Er zijn meerdere situaties waarin hashing kan ontbreken:
1. De daadwerkelijke opslagplek van je wachtwoord, de waarde waartegen wordt gecontroleerd of je wachtwoord klopt wanneer je inlogt. Dit zou altijd gehashed moeten zijn en standaardkennis van elke developer moeten zijn.
2. De logs: een server of applicatie kan alle berichten die heen en weer worden gecommuniceerd richting gebruikers,API's, etc opslaan voor foutoplossing en audits. Dit logging-systeem heeft niet zomaar weet van de inhoudelijke betekenis van de berichten en dus of willekeurige karakters in dat bericht toevallig een wachtwoord of creditcard-nummer zijn. Natuurlijk zou dit ook gehashed of gewist moeten worden, maar dat is niet triviaal. "Hee, de server is traag. Wat wordt er allemaal op ons afgevuurd? Laten we ff een log maken om te kijken wat er mis gaat..." Hoppa, ongefilterde gevoelige data.

[kaas-schaaf]

Het was zo moeilijk om het toe te voegen omdat ze aan password recovery wilde doen. Daarom sloegen ze de wachtwoorden versleuteld op zodat ze konden worden ontsleutelen en naar de gebruiker konden worden gestuurd indien die daar om vroeg. Hoewel dit een slechte praktijk is gebeurde (en gebeurt) dit toen heel vaak. Als ze de wachtwoorden net zoals de consumenten wachtwoorden hadden gehashed was recovery op die manier niet mogelijk.

[Reactie gewijzigd door kaas-schaaf op 23 juli 2024 07:06]

[beerse]

Misschien is het wel dat dit soort zaken eerder en eerlijker worden verkondigd.

Waarom het nu pas wordt ontdekt? Dat weet ik niet, maar het is wel rap doorgegeven aan hen die het betreft (en de rest van de wereld). Je kan je ook afvragen waarom het ontdekt is.

Waarom het moeilijk is om hashing toe te voegen? Om te beginnen zou ik zeggen dat het wachtwoord ontwerp zo slecht is dat het niet-gehasht van het intikken naar het testen gaat. In een grijs verleden heb ik mij verwonderd dat wachtwoorden op veel te veel systemen in open tekst worden gecommuniceerd. Het lijkt mij beter dat de wachtwoorden bij het intikken al worden ge-hasht en dat de hash wordt gecommuniceerd en gebruikt bij het testen.

Enne, wachtwoorden hebben niets met privacy te maken. Het is meer beveiliging (security) dat hier speelt.

[dez11de]

Volgens mij ben jij de allerbeste stuurman die nog nooit ene mijl gevaren heeft.

[Vexxon]

Er dan wordt er dus altijd maar gerept over dat Google zijn security veel beter op orde heeft dan een Facebook, maar dit vind ik toch vrij amateuristisch voor een dergelijk bedrijf. Zeker omdatbdit bedrijf zo gigantisch veel data heeft van alles en iedereen.
Maar goed het zal wel weer goed gepraat worden, want Google is in eenmaal heilig in de ogen van velen

[Stoelpoot]

Toen Facebook dit specifieke probleem vond, werd het ook door enkele mensen (waaronder mijzelf) "goedgepraat". Wachtwoorden is logfiles is een stomme fout, maar alsnog een simpele menselijke fout. Niemand doet dat expres. Jammer dat het gebeurd, maar de afhandeling ziet er tot nu toe netjes uit.

[Cergorach]

Er dan wordt er dus altijd maar gerept over dat Google zijn security veel beter op orde heeft dan een Facebook

Ik durf helemaal niets te zeggen over een Facebook, maar meestal wordt er gesproken over bedrijven als MS die als hun core business bepaalde diensten heeft die beter secure zijn dan dat 99% van de bedrijven zelf kunnen regelen die hun diensten afnemen. De vraag zal nu gesteld moeten worden of G-Suite wel de core business is van Google...

Je wil niet weten wat bedrijven in de afgelopen 15 jaar hebben uitgehaald in Nederland qua hun eigen IT, meestal gaat dat de doofpot in omdat er of nog geen meld plicht was of dat ze zich voorhouden dat het niet hoeft...

[Verwijderd]

De vraag zal nu gesteld moeten worden of G-Suite wel de core business is van Google...

Die vraag kan ik je wel beantwoord: Ja. 5 miljoen organisaties (niet gebruikers) maken er al gebruik van met 1 miljoen nieuwe organisation in 2018.

Dus het is zeker een core business.

Meestal wordt er gesproken over bedrijven als MS die als hun core business bepaalde diensten heeft die beter secure zijn dan dat 99% van de bedrijven zelf kunnen regelen die hun diensten afnemen.
Dat is helemaal waar, ik ben alleen vandaag al meerdere accounts en wachtwoorden tegengekomen. Geen lekken of zo maar verdwaalde scripts, logs en taken.

[watercoolertje]

Maar goed het zal wel weer goed gepraat worden, want Google is in eenmaal heilig in de ogen van velen

Het omgekeerde is anders voor jou van toepassing, elke mogelijkheid om te zeiken hoe slecht Google wel niet is grijp je aan. Prima dat dat je mening is maar doe niet zo hypocriet

Helaas dat je dan weer niet verder kijkt dan het probleem, daarmee doel ik op de oplossing, waar Google uit zichzelf zonder enige druk van andere dit kenbaar maakt en uitlegt wat er gebeurd(e) en hoe ze er vervolgens mee om zijn gegaan, daar kan ongeveer elke bedrijf van die grote (en groter) van leren.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 07:06]

[Vexxon]

Wellicht hypocriet, er zijn er hier echter maar weinig die zich daar niet schuldig aan maken.
Je zou bv. kunnen stellen dat wanneer je grote problemen die zich voordoen bij een specifiek toestel van je favoriete fabrikant gaat goed praten ook enigszins hypocriet is.

Zeker dat Google het beter op orde lijkt te hebben dan Facebook en voor wat dit incident betreft beter lijkt af te handelen, maar het punt is dat Google blijkbaar niet gevrijwaard is van het maken van amateuristische fouten, dus in die zin niet heilig. Het gaat over data van vrijwel iedereen, ook die mensen die niets met Google te maken willen hebben (zoals ik) zijn onderdeel van hun dataset. Dus ja, ik vind dat ik daar best kritisch op mag zijn. Maar blijkbaar heb je daar een andere mening over.

[Reactie gewijzigd door Vexxon op 23 juli 2024 07:06]

[Verwijderd]

Bij security gaat het erom hoe je ermee omgaat en daar horen incidenten ook bij (anders hadden we geen beveiliging nodig). Het beveiligen is 50% van het werk, 25% is monitoren en 25% is incident beheer.

Die laatste twee vallen bij de meeste bedrijven in het water (als ze al aan het beveiligen beginnen), Google doet het hier zo te zien dus prima en daarbij zijn ze ook nog eens transparant.

Trek je niet aan van zijn reactie, het is overduidelijk enkel gemaakt om te provoceren zonder enige vorm van onderbouwing. Simpelweg een internet trol dus.

[Anonymoussaurus]

Het gaat hier om 2005... En ja, dat heeft het.

[t link]

Vaak zijn het simpele menselijke fouten. in princiepe is het standaard systeem goed, maar soms willen mensen dingen loggen en dan gaat het fout omdat ze perongeluk ook wachtwoorden loggen. ooit zul je nou eenmaal een wachtwoord in plaintext moeten behandelen anders kan je nooit inloggegevens verifieren, als iemand dan onbewust een deel van dat process logt of een memdump daarvan maakt heeft die wachtwoorden in plaintext. het is ook vrij moeilijk tegen zo iets een systeem te maken denk ik.

[Skywalker27]

Nou toch nog wat voor ISec om wat aan Security Awarness te gaan doen die security culture waar ze het altijd over hebben lijkt me toch geen sprake van.

[DigitalExorcist]

Nou.... das wellicht wat overdreven, niet?

[Skywalker27]

Nou nee dit is niet het eerste voorval, het feit alleen al dat er in de beheerders groep vraag is naar bepaalde tools. En het is geen schande hoor Awarness is 1 van de lastigste dingen binnen een bedrijf om iedereen met de neus in dezelfde richting te krijgen.

[Reactie gewijzigd door Skywalker27 op 23 juli 2024 07:06]

[4tro]

Ik verwacht dat het ging om beheerders van hun klanten, dus een vraag vanuit de klant.

Active Directory had ook altijd een optie om wachtwoorden met een reversable hash op te slaan zodat mensen hun wachtwoord weer vertelt kon worden.

Met de kennis van nu is dat natuurlijk niet meer voor te stellen, maar daarom bestaat die functie ook niet meer in die vorm, dit zal een stuk legacy zijn geweest.

[Verwijderd]

Met de kennis van nu is dat natuurlijk niet meer voor te stellen.

TL;;DR: Gebeurt nog steeds.

Ik doe Active Directory migraties. Voorafgaand aan zo'n migratie onderzoek ik natuurlijk de huidige situatie.
Minder dan 2 jaar geleden was ik bij een klant waar ik een combinatie van policies en userrights simpelweg niet begreep; zoals dat stond leek het er samengevat op dat gebruikers hun wachtwoord niet mochten en konden wijzigen. Toen ik dit voorlegde aan de verantwoordelijk IT manager zei hij zonder erbij met zijn ogen te knipperen:
"Dat klopt, want anders kunnen wij gebruikers hun wachtwoord niet vertellen."
Trots gevolgd door: "Die hebben we in een Access database; daardoor kunnen helpdeskmedewerkers als ze een profiel weg hebben gegooid alvast inloggen als die gebruiker, zodat alles alvast klaar staat als de gebruiker zelf inlogt."
O ja, voor het gemak bestonden alle wachtwoorden uit een 4-cijferige pincode.
Voor de goede orde: dit was (naar Nederlandse maatstaven) niet bepaald een klein bedrijfje.
M.a.w: Dit gebeurt nog steeds, en niet alleen eens via reversable hashes.

[DigitalExorcist]

Mja "niet op orde" is een groot woord. Tuurlijk gaat er wel eens wat mis maar als ik het artikel zo lees is er geen direct risico voor de community geweest, zijn ze niet gehacked en stonden de wachtwoorden nog steeds in een encrypted, aparte omgeving. Weliswaar niet netjes dat het plain text is maar het is niet vergelijkbaar met recente grote lekken á la The Fappening, LinkedIn, MySpace of Collection #1 ...

[gold_dust]

Weet ik niet, ik heb er ooit als software ontwikkelaar een sollicitatie ronde gehad. Opvallend hoe laag het niveau bij Google is, ook een aantal andere van de grote IT bedrijven in Sillicon Valley vielen tegen maar Google spant echt de kroon. Daarna heb ik het er maar bij gelaten, ik reageer niet meer op LinkedIn berichten van Amerikaanse bedrijven. Recent Amazon en Facebook nog.

Verbaast me niks dat ze de beveiliging ook niet op orde hebben.

[DigitalExorcist]

Ik krijg wekelijks uitnodigingen om voor "onze klant" in "een groot datacenter in Eemshaven" te komen werken. Het beestje wordt nooit bij naam genoemd natuurlijk, maareh.. standaard ignore dat soort ellende.

[Scriptkid]

Zo zie je maar weer security is zo sterk als je zwakste schakel.

Een iemand hoeft maar even niet verder na te denken en dan ga je al.

Zie het helaas nogsteedts te vaak gebeuren

[Cergorach]

Ik zie veel te vaak dat ITers oogkleppen op hebben, zolang hun issue of systeem maar weer draait kijken ze niet verder dan dat hun neus lang is. En oh-wee als iemand anders in hun systeem gaat spitten of het wel op order is of werkt zoals het hoort... Daarnaast is goed documenteren en troep opruimen vaak ook een enorm hekel issue, waardoor je jaren later naar dingen zit te staren, op je hoofd zit te krabben met een wtf! expressie op je gezicht...

[HeerKaas]

Mail is Al geplaatst dus verwijderd!

[Reactie gewijzigd door HeerKaas op 23 juli 2024 07:06]

[neboekadnezar]

Ach, het stond waarschijnlijk op een goed beveiligde PC, waarvan de AV up-to-date was.

[kodak]

Dat het in plain text opslaan van wachtwoorden niet aan hun standaarden voldoet is geen onbelangrijk detail. Google geeft aan dat ze audits doen. Als die er op gericht zijn om te controleren of hun code wel aan de standaarden voldoet blijven er een paar vragen onbeantwoord:
Hoe kan het dat functionaliteit die over belangrijke gegevens gaat 14 jaar later nog niet was opgemerkt, of nog niet verholpen?

Hoe kan het dat functionaliteit uit 2005 die niet aan de standaard voldoet in 2019 nog gebruikt kon worden?

Sinds wanneer is de standaard bij Google eigenlijk dat je wachtwoorden zo niet mag opslaan?

Gaan ze hun audits en manier waarop ze functionaliteiten toepassen ook aanpassen? Dit hadden de ontwikkelaars en testers ook kunnen herkennen voor het in productie kwam?

[TheDeeGee]

"per ongeluk"

Per ongeluk bewust iets zo laten opslaan?

[Lizard]

consumenten zijn niet getroffen

Dat lijkt me sterk, in 2005 was G-Suite nog apps for domains. Die kon je toen als consument ook (gratis) aanvragen.