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

Ah.nl gaf per ongeluk inlog en wachtwoord van tienduizend accounts vrij - update

De site van Albert Heijn gaf onbedoeld de inlognamen en het wachtwoord van zo'n tienduizend gebruikers vrij aan serviceproviders, in een url. AH lichtte getroffen gebruikers per e-mail in. Zij moeten een nieuw wachtwoord instellen.

De inlognamen en wachtwoorden waren volgens Albert Heijn 'kort' zichtbaar in url's. Dit kwam door een programmeerfout in de software die inloggen op de site mogelijk maakt. De gegevens zijn volgens de woordvoerster van AH alleen inzichtelijk geweest door serviceproviders. AH heeft die providers verzocht de data te verwijderen.

"Er is geen ongebruikelijke activiteit waargenomen met betrekking tot de inloggegevens of gebruikersaccounts", stelt Albert Heijn. Uit voorzorg heeft de supermarktketen de wachtwoorden van de desbetreffende accounts geblokkeerd, zodat de getroffen gebruikers een nieuw wachtwoord moeten instellen. Hiervoor moeten zij via 'Wachtwoord vergeten' een link opvragen.

Sinds kort kunnen gebruikers met hun Bol.com-adres inloggen bij ah.nl. De woordvoering van Albert Heijn benadrukt dat die gegevens niet zijn vrijgegeven door de programmeerfout.

Albert Heijn heeft het datalek gemeld bij de Autoriteit Persoonsgegevens.

Update, 12.17: De woordvoering van AH meldt dat data van Bol.com-accounts geen onderdeel waren van het datalek. Ook meldt het bedrijf dat alleen bepaalde serviceproviders de inlognamen en wachtwoorden via de url in konden zien en dat de gegevens over https verzonden werden en dus versleuteld waren. Dit stond aanvankelijk anders in dit artikel. Via publieke wifinetwerken zijn de gegevens dus niet in de logs onversleuteld terug te vinden.

Door Olaf van Miltenburg

Nieuwscordinator

09-11-2018 • 11:33

147 Linkedin Google+

Submitter: gwie

Reacties (147)

Wijzig sortering
Mijn account was een van de accounts die het trof. AH heeft vanmorgen nog een mail uitgestuurd aan klanten die het raakte met wat meer informatie:
Ons is duidelijk geworden dat via een programmeerfout de inloggegevens van uw AH.nl account onbedoeld gedeeld zijn met enkele online service providers van Albert Heijn. Het is natuurlijk niet de bedoeling dat dit gebeurt en wij bieden dan ook onze verontschuldigingen bij u aan vanwege dit voorval en voor het ongemak dat deze situatie voor u veroorzaakt. Hieronder geven wij u meer informatie over het voorval.

Waar gaat het om?
Het gaat hierbij om een programmeerfout in de software die wij gebruiken om het inloggen op AH.nl mogelijk te maken. Door deze programmeerfout werden mogelijk uw inlognaam en het wachtwoord dat u gebruikt om op AH.nl in te loggen kort zichtbaar in de URL, dit is de adresbalk bovenaan uw computerscherm. Wij delen deze URL met enkele van onze online service providers, bijvoorbeeld voor het continu verbeteren van onze websites. Het delen van URLs voldoet uiteraard aan alle wettelijke verplichtingen. Wat echter niet de bedoeling is, is dat in deze URLs ook uw inloggegevens zichtbaar zijn.

Wij hebben het probleem direct verholpen. De URLs die worden gedeeld bevatten geen inloggegevens. Wij hebben onze online service providers ingelicht, en opdracht gegeven de informatie te verwijderen. Ook hebben wij de Autoriteit Persoonsgegevens ingelicht.
Het is dan weer jammer dat ze niet melden dat je browser geschiedenis moet legen. Daar staat het nu ook in.
Daar staat dan een wachtwoord in dat niet meer werkt. Niet heel spannend lijkt me...
Niet volledig juist, ik ken heel veel mensen die voor alle sites hetzelfde wachtwoord gebruiken.
Bestaan die mensen anno 2018 nog? :X
Moet je eens kijken hoeveel mensen op een drukke plek omkijken als je roept "Ik weet uw wachtwoord! het is Welkom01"
Welkom01!

Natuurlijk is dat veel veiliger.

Ik heb denk ik, incl werk, iets van 50 passwords... echt vrolijk word ik daar niet van (password manager kan op werk bij ons niet)...
Welkom op een techsite, een van mijn password managers telt al 230 wachtwoorden. :?

allemaal zelf aangemaakt. dat is dus buiten de wachtwoorden die in andere vaults staan.
Elke website krijgt een unieke code, zo complex als dat de website accepteert. (na 30 random cijfers, hoofd en kleine letters, leestekens, speciale characters ga ik dan weer niet verder zoeken hoeveel de website accepteert)

[Reactie gewijzigd door Amasik op 9 november 2018 16:39]

Ik zeg ook niet dat ik er meer dan gemiddeld heb op Tweakers. Zelf word ik er niet vrolijk van met al die verschillende wachtwoorden die op verschillende intervallen aangepast moeten worden (de een na 1 jaar, de ander 3 of 6 maanden...)

Verder dan "vervelend" komt het bij mij niet echter snap ik dat de gemiddelde 55+er dit niet gaat kunnen onthouden/begrijpen. Gevolg: Overal hetzelfde wachtwoord of men plakt post-it's op de monitor.

Dan lijkt het mij veiliger om b.v. 3 zr sterke wachtwoorden te gebruiken en deze eens in de zoveel tijd aan te passen. (DigID = 1 / Mail = 2 (i.v.m. "wachtwoord vergeten" shit op overige plekken die hier je mail voor gebruiken) / Overigen = 3).

Maar liever nog zou ik overal de optie tot 2 staps verificatie zien. Ik zou je bij wijze van mijn wachtwoord voor mijn Apple ID/iCloud kunnen sturen. Succes daarmee zonder dat je fysiek toegang hebt tot mijn telefoon (SMS code benodigd)
Beter nog: tweetrapsverificatie bij je e-mailprovider met een afgedwongen sterk wachtwoord en een code op je mobiel (liever niet via SMS), en gewoon elke site die bij een inlogpoging een mail stuurt (klik hier om in te loggen).

Ik vind het heerlijk dat ik bij Slack gewoon kan inloggen door mijn e-mailadres op te geven en in mijn mailbox op een linkje te klikken. En in mijn mailbox komen ze cht niet in.
Welkom02
your turn, hackers! :+
De Sleutelhanger (macOS / iOS) is ook flink gevuld hier. Random extreem lange passwords. Niet altijd even handig maar wel secure.. en voor de rest, Keepass.
Ik ken dan ook niet veel mensen die niet omkijken als je op een drukke plek roept ik weet uw wachtwoord het is.... XD
Tijd dat men eens begint met 4, 6 of 8 cijferige PIN codes. Makkelijker te onthouden en moeilijker te ontfutselen.
natuurlijk.. ook genoeg mensen die 'password' als wachtwoord hebben..
Onder andere de campagne leider van Hillary Clinton voor z'n windows log in.
Ownee sorry dat was p@ssword.
Natuurlijk, voor iets irrelevants als een supermarkt. Ik denk dat de groep mensen die voor dat soort zaken hetzelfde wachtwoord gebruikt groter is dan de mensen die dat allemaal apart houden.

Ik begin daar ook echt niet aan.
Ja en nee, maar ik heb de afgelopen weken tig keer slecht in het engels geschreven e-mails gehad waarin men claimde dat ze mijn wachtwoord hadden van een of andere p0rn sites. Of ik even tig bitcoins kon storten.

Het password in die mail leek wel op een van mijn vele passwords uit het verleden. Vermoed dat het nog steeds met die Adobe lek te maken heeft.

Beste is idd een random password uit een password manager of iCloud chain te pakken en daar ook op te slaan. Er is eigenlijk geen reden meer om password als "mijngeheimepwd" te gebruiken voor websites.
was ook blij dat ik die mail eindelijk kreeg van de week.. was al bijna bang dat ik overgeslagen was..
Ik heb toevallig deze week ook zo'n email gehad. Het interessante was dat het mijn email adres vermelde maar een paswoord die we gebruikten voor een groepsproject. Voor dat groepsproject gebruikte ik een ander email adres dan het gene waar ik de email op heb gekregen. Breek er nog altijd mijn hoofd over hoe uiteraard ten eerste ze aan he paswoord gekomen zijn maar ook hoe het gelinkt werd met een andere email.
Waarom zouden die niet meer bestaan? Er worden dagelijks 350,000 kinderen geboren, en die maken allemaal dezelfde fouten die hun voorgangers ook gemaakt hebben.

Er zijn maar weinig mensen die privacy en digitale beveiliging met de paplepel krijgen ingegoten, en hier dan ook nog eens het belang van consequent zijn inzien. De meeste mensen hebben zoiets van 'ik gebruik het maar een keer / het is X maar / whatever, wat maakt het uit', en dan heb je weer een nieuwe account met het wachtwoord hunter2.
Ja ;( Die bestaan nog.
Je zou verwachten dat mensen toch beter moeten weten, na duizenden nieuwsberichten als deze...
Helaas ;(.
En als ik mag vragen, hoe ga jij al die verschillende wachtwoorden/token codes dan onthouden?

3x E-mail (1x prive, en 2 werk)
2 Werk accounts (wachtwoord + eigen code & authenticator)
Launchers (Steam, Origin, B.net, Uplay, Unreal, etc etc etc)
PC, tablets, telefoons (werk en priv)
Website accounts (reddit, tweakers, mmo-champ maar ook dingen zoals digid)

Je kunt mij niet vertellen dat je allemaal verschillende wachtwoorden hebt voor elk platform.
Opschrijven en die "password tools" zijn ook niet altijd even veilig.

En oudere mensen dan die niet vaak met computers enzo werken? Verwacht je ook dat zij hun inlog data onthouden? Helemaal als je ook nog geforceerd wordt om het om de zoveel tijd aan te passen?

Ik onthou dat persoonlijk namelijk niet allemaal uit mijn hoofd.

Zelfs al zijn je wachtwoorden lang en veilig, grote kans dat het alsnog op een andere manier zoals deze gelekt wordt en dan heb je er alsnog niets aan.

[Reactie gewijzigd door MiraculoX op 9 november 2018 14:15]

De oplossing is: verzin een systeempje, een formule waarmee je al wachtwoorden altijd kunt herleiden. Zo hoef je alleen nog je formule te onthouden.

Maar, voor veel mensen is dat ook al erg ingewikkeld.
Dat werkt heel even, totdat siteA elk jaar een nieuw wachtwoord wil wat niet mag lijken op het oude wachtwoord, dan begint dienstB elke drie maanden dat te eisen en het wachtwoord mag niet lijken op de vorige 6 wachtwoorden en vervolgens wilt siteC alleen kleine letters, siteD minimaal 6 kleine letters, 1 hoofdletter, 2 cijfers en 1 speciaal karakter en opnieuw mag het niet lijken op vorige wachtwoorden en ook niet op een bestaand woord en vervolgens heb je 1 formule voor je wachtwoord + x uitzonderingen en y aanpassingen op die uitzonderingen :+
Toch is het wel mogelijk iets te bedenken, ik gebruik zelf ook op veel plekken een vergelijkbaar wachtwoord, met tekens en cijfers, waarin ik slechts een paar symbolen per account aanpas. Als symbool dat je steeds aanpast zou je iets logisch kunnen kiezen, zoals M voor mail, of T voor tweakers, of een bepaald cijfer, er is echt wel iets te bedenken.
Dat gaat dus niet ;)
Stel je doet Wachtwoord001WT ('Wachtwoord' maak je wat minder obvious uiteraard, 001 voor eerste wachtwoord, 'W' voor website en 'T' voor Tweakers...
Dan wil je jezelf registreren voor Twitch... Je Tele2 of T-Mobile account gaat dan ook moeilijk...
Dus je bedenkt Wachtwoord001WTW (TW voor Tweakers, TW voor Twitch.......) Oke Wachtwoord001WTWE voor Tweakers en ...TWI voor Twitch...
Vervolgens wil een dienst dat je regelmatig (maandelijks....) je wachtwoord veranderd, Wachtwoord002WTW en de maand erop Wachtwoord003WTW maar beide mogen niet want ze lijken op het eerste wachtwoord... Dus je draait het om: WTW001Wachtwoord en vervolgens krijg je vrolijk de melding dat ook dat op je vorige wachtwoord lijkt (zelfde tekenreeks zit erin.
Vervolgens komt siteX eraan met een max wachtwoordlengte van 8 karakters (ja echt ze bestaan helaas nog...) en siteY met een minimale lengte-eis van 24 karakters... SiteZ maakt het dan af door alleen bepaalde tekens toe te staan (again, true story...)

Heb zat diensten en netwerken gezien waar je maandelijks je wachtwoord moe(s)t veranderen en het nieuwe wachtwoord niet dezelfde tekenreeks mocht bevatten, dan gaat een formule sowieso niet werken.
Dan heb je leuk een formule, maar met dusdanig veel uitzonderingen of gewoon complete afwijkingen dat je net zo goed minder moeite had kunnen stoppen in een password manager die daadwerkelijk sterke wachtwoorden bedenkt op basis van hoe moeilijk ze te kraken zijn door computers, niet door mensen...

Dan nog niet eens begonnen over hoe veilig een dergelijke formule is, meeste password tooltjes proberen dergelijke patronen standaard al...
Haha ja ik begrijp wat je bedoelt, ben daar zelf ook vaker tegen aangelopen :+

Deels opgelost door ervoor te zorgen dat mijn formule wachtwoorden genereert die ingewikkeld genoeg zijn om hoe dan ook alle websitebouwers tevreden te stellen.
Dan heb je altijd nog de wachtwoord vergeten optie als je formule niet werkt.
Simpel.

Kies 1 (n) wachtwoord dat voldoende complex is en onthoud dit. Vervolgens voeg je voor iedere toepassing/website een random nummer (4 cijfers ofzo) toe. Die nummers en hun toepassing kun je desnoods in een boekje schrijven en naast de computer bewaren. Zonder het eerste deel kun je er niks mee. Methode is relatief veilig en in ieder geval al veel beter dan overal hetzelfde wachtwoord of alles in een boekje schrijven.
gewoon met keepass. Super veilig en handig.
Heb voor alles een password wat uniek is en heel lang en random. Zou ze nooit kunnen onthouden.

-keepass datebase staat online
-zit een password op (die alleen ik weet)
-zit een keyfile op (die alleen ik heb)

[Reactie gewijzigd door bilbob op 9 november 2018 17:04]

En dat is nog niets, ik werk in de IT. Elke website, (S)FTP wachtwoord, database wachtwoord, CMS wachtwoord, hosting wachtwoord. Dat zijn er minimaal 4 per website die ik onderhoud.

Voor projecten nog allerlei andere wachtwoorden, jenkins, jira en confluence bijvoorbeeld allemaal anders. Dan nog het wachtwoord voor je OS, bank, router en ga maar door.

Je moet dan zoveel wachtwoorden hebben dat het ondoenlijk wordt, een passwordmanager of papier en een wachtwoord generator is dan toch de beste oplossing lijkt mij, want hetzelfde wachtwoord voor alles is vragen om problemen en een heleboel werk als die wordt gekraakt.
Precies dit, ben eens even gaan kijken, heb toch zeker zo'n 150 inlogs die ik zou moeten onthouden.
Gaat em toch niet worden.
In mac OS zit dat bij uw Icloud, ik vul geen logins wachtwoorden meer in, het gaat vanzelf, ook op men Iphone synct dat automatisch. Ik vermoed dat Windows ook zoiets gelijkaardigs heeft op w10? (Al synct dat wss niet naar uw mobiel?)

Password tools zijn wel erg veilig, ze checken de website op zijn echtheid en alles wordt veiliger opgeslagen dat je het zelf ooit kan organiseren, cross platform. Op het werk gebruiken we 1password, werkt heel goed.
Ik heb wel degelijk voor elke site en elk programma en elke inlog een uniek wachtwoord van 16 tekens. Daar gebruik ik een wachtwoordmanager voor. En dat zou de norm moeten zijn, het is namelijk de enige manier om nog enigszins veilig te zijn tegen hacks en datalekken.
Ja, dat zou je denken. Maar veel mensen zijn niet zo handig met het concept wachtwoord.

Het schijnt nogal lastig te zijn om wachtwoorden te onthouden, verzinnen van een nieuw wachtwoord kost ook moeite, en mensen die ik ken die wel verschillende wachtwoorden gebruiken, zitten een half uur in een boekje te graven voor ze een wachtwoord hebben gevonden.

Wachtwoordkluizen zijn ook nog lastig te bevatten voor deze groep.

De mensen waarom dit gaat zijn ook vooral mensen die niets met computers hebben, maar toch worden gedwongen om ermee aan de haal te gaan.
Multi-factor zou gewoon goed moeten worden. Desnoods via de telefoon.
Kijk om je heen en je ziet genoeg objecten om als wachtwoord te gebruiken
Je zou verwachten dat mensen toch beter moeten weten, na duizenden nieuwsberichten als deze...
Helaas ;(.
lekker makkelijk gezegd overigens, ik weet alle manieren om dit niet te laten gebeuren, password managers, en de hele rompslomp op verschillende apparaten, alleen veel van deze managers werken gewoon heel rot met mobiele apparaten, denk aan gewoon ruk integratie, maar ook al kopieer je het wachtwoord naar je klembord, dat de app copy paste niet accepteerd of de app elke keer refreshed als je dit sowiesow opent.

dan wordt het ineens heel rot om voor elk iets een apart wachtwoord te hebben.
Heb je de Android implementatie van Keepass al gebruikt? Want ik heb tot nu toe nog niet meegemaakt dat ik mijn user/wachtwoord onmogelijk was om in te voeren.
gaat idd altijd goed via het keepass keyboard.
Daar heb je wel een punt hoor. Ik moet soms zo'n onhandig lang wachtwoord overtypen. Maar ja, kleine prijs voor een stukje veiligheid denk ik. De implementatie mag echter wel beter. Ik moet zeggen dat Lastpass op mijn Samsung S9+ wel behoorlijk goed werkt. Als ik daar een invulveld selecteer, krijg ik een popup, moet ik even mijn vinger op de scanner leggen, en dan wordt het gelijk goed ingevuld.
"Een oor in, andere oor weer uit".

Dat fenomeen beschrijft mensen al veel langer dan computers bestaan.
"In Nederland hebben 2,5 miljoen mensen van 16 jaar en ouder moeite met lezen, schrijven en/of rekenen. Vaak hebben zij ook moeite met digitale vaardigheden. Dat staat gelijk aan 18%, dus ongeveer 1 op de 6 mensen in Nederland." (bron)

Beleidsbepalers en ontwerpers/programmeurs hebben nogal eens scheef beeld van de maatschappij. Het stikt van de mensen die moeite hebben met computers en er toch vanalles mee moeten doen. En wachtwoorden zijn ook voor mensen die wl handig met computers zijn een bron van ergernis.
Hoezo zou ik mijzelf verplichten tot een wachtwoordmanager als simpel vaststellen van veiligheidsniveau al helpt?

Zelf gebruik ik n specifiek wachtwoord voor meerdere sites; maar dan hebben we het wel over sites waar het mij niet heel veel zou interesseren als het account gekraakt raakt (geen betaalgegevens gelinkt, bijv.) zoals onder andere mijn bol.com en ah.nl accounts; wachtwoorden van diensten die wat belangrijker zijn (waar bijv mee geauthenticeerd kan worden bij de mail als voorbeeld) zijn veel gecompliceerder en allen uniek; zo hoef ik niet voor elke onbenullige site wr een extra wachtwoord aan te maken en kan ik prima veilig wachtwoorden beheren znder extra wachtwoordmanager.
Ik ben helaas niet gezegend met zo'n goed geheugen dat ik een stuk of 15 a 20 random wachtwoorden van 16 tekens (hoofdletters, kleine letters, cijfers, vreemde tekens) uit mijn hoofd kan onthouden... Dus ik heb daar een wachtwoordmanager voor nodig. En als ik die toch gebruik, dan is het een kleine moeite om dan gelijk voor alle websites een uniek complex wachtwoord te hanteren.
Ze weten ook beter. MFA en diensten zoals SAML voor SSO werken veel beter overal maar random passwords gebruiken. Het wachtwoord "Tweakers1" in combinatie met deze diensten is veiliger dan slechts een wachtwoord zoals "vc,~ܹ¨ذRV¸¾."
Ja en hoe erg is dat voor een hoop websites? Maakt mij voor heel veel sites namelijk niet uit dat ze er achter komen. Ik gebruik meestal toch fictieve persoonsgegevens :Y). En ik heb natuurlijk wel een ander ww voor mijn mail en voor mij belangrijke of persoonlijke websites.

Nou staat op ah.nl waarschijnlijk wel wat persoonlijke gegevens als ook je boodschappen thuis bezorgen. Dus dat zou dat in mijn geval een ander ww zijn geweest O-)
Niet bij AH, maar de vraag is bij hoeveel andere website waar het zelfde wachtwoord gebruikt is wel...
Je hoeft gelukkig niet je hele geschiedenis te legen. Je kan ook de AH specifieke URL's er uit halen. Op dit soort momenten ben ik blij met een zoekfunctie in je browsergeschiedenis.
Een beetje man schoont regelmatig zijn browse history.... ;-)
Hoe kan een password zichtbaar worden ?
Dat sla je toch ALTIJD op als hash !
(php voorbeeldje : http://php.net/manual/en/function.password-verify.php)

edit: snap dat het waarschijnlijk ging om een login form die als GET naar de server werd gestuurd, met dus als gevolg dat dat in iedere log etc. komt ...

[Reactie gewijzigd door xats6nl op 10 november 2018 08:05]

Maak ik hieruit op dat AH zijn wachtwoorden in plain tekst of encrypted maar niet hashed opslaat? Dat is natuurlijk ook al ronduit schandalig...

Of is dit een gevalletje GET i.p.v. POST request? Dan vind ik het wel een beetje raar verwoord in het artikel dat er 10000 gegevens in de adres balk zouden staan...

[Reactie gewijzigd door waxdt1 op 9 november 2018 11:38]

Zoals ik het lees gaat het eerder om een foutje bij het versturen van het loginformulier. Normaal wordt zo'n formulier als POST verstuurd naar de server, zodat de server je gebruikersnaam en wachtwoord kan controleren. Met een POST zitten deze gegevens in de body van de request.

De standaard methode van een HTML-formulier is echter een GET. Hierbij worden de gegevens als onderdeel van het adres naar de server verstuurd (bijvorbeeld ah.nl/login?username=X&password=Y).

Hoewel de data op beide manieren encrypted is (als er gebruik gemaakt wordt van HTTPS) worden GET URL's op allerlei plekken gelogged: op de server van AH, op proxies tussen de client en AH, en zelfs in de browsergeschiedenis van de gebruiker. Deze logs en browsergeschiedenis zijn niet encrypted, en dat is niet heel handig natuurlijk.
Waarom worden wachtwoorden eigenlijk niet gehashed voordat ze naar de server toe gaan? Je krijgt altijd dezelfde hash bij dezelfde input en zo kan niemand ooit achter het originele wachtwoord komen.
Omdat je dan net zo goed niet de hash kunt doen. Op dat moment heb je het hele gebeuren gereduceerd tot het opslaan van plain text wachtwoorden. Want hoe gaat de server controleren dat je aan die string gekomen bent door iets te hashen en niet door (bijv.) het uit een gestolen database te vissen?
Voor proxies via HTTPS wordt het lastig, of de proxy moet werken met automatisch genererende certificaten waarvoor de gebruiker door middel van het inladen van een root certificate toestemming heeft gegeven. Anders kan ook een proxy enkel de hostname zien

Sommige malware scanners op je PC doen hetzelfde, waardoor de controle van de geldigheid van het certificaat bij die applicatie komt te liggen en niet meer bij de browser.
Ik doelde eigenlijk op reverse proxies of load balancers, bijvoorbeeld als AH.nl gebruikt maakt van Cloudflare of zelf load balancers heeft. Er kunnen meerdere reverse proxies tussen de client en de daadwerkelijke website zitten, waarbij elke proxy natuurlijk weer een extra risico is.

Daarnaast zijn er vast genoeg proxies die alles loggen bij bijvoorbeeld scholen, internetcaf's of werk.

Maar het klopt inderdaad dat dit niet zomaar kan als je met je eigen PC zou verbinden.
Dat is precies het eerste wat ik ook dacht. Een GET waar een POST zou moeten worden gebruikt verklaart dit hele geval. Ze zeiden dan ook dat het een programmeerfout is. Dat zal het dus ook inderdaad zijn.
Wat je vergeet is dat veel pagina's tegenwoordig afgehangen zijn met tools als Google Analytics, Visual Website Optimizer, Criteo tracking en dat soort zooi. Behalve in de webserver logs gaan dan je gebruikersnaam en wachtwoord dus ook vrolijk naar de advertentie en analysepartijen.
Ik vermoed dat de 'referrer' url de grootste boosdoener is als je bijvoorbeeld CDN's gebruikt... zulke third party partijen kunnen zo uw wachtwoord inlezen. https of niet...
Nee, lees de tekst nogmaals, de gegevens werden via een GET request ipv een POST request verstuurd. Dus wanneer jij het wachtwoord als gebruiker invoerd om te valideren dat je in mag loggen. Dat zegt niks over hoe het opgeslagen is in de DB.
Deze volg ik even niet helemaal?
Wat heeft GET vs POST te maken met hoe alles is opgeslagen in de database?
Alle wachtwoorden stonden nu waarschijnlijk in een log van de AH webserver/reverseproxy.
Dus inderdaad niet in de database opgeslagen.
Ik vind dit een wat raar verhaal, ik zie dat de site HTTPS gebruikt, daarmee is de URL niet zichtbaar voor tussenpartijen, ook niet voor GET requests.
Wel als al je URLs worden gelogd door bijv. Google Analytics, ik neem aan dat dat in dit geval is gebeurd. Als je daar vervolgens al je SEO en marketing partijen toegang aan geeft dan hebben stiekem toch al veel partijen toegang tot die data. Dat zullen ze dan ook bedoelen met "inzichtelijk geweest door serviceproviders".
Maar de tekst komt dan dus wel plaintekst in je browse history enzo te staan, ik denk dat daar het probleem zit. Dus als je ooit een publieke of gedeelde computer gebruikt ...
En niet te vergeten in de access logs van de server. Dan heeft die encryptie / hashing in de database niet zo veel zin meer.
Buiten dat die server eigenlijk ook dichtgetimmerd moet zijn :)
never mind

[Reactie gewijzigd door KDG37 op 9 november 2018 14:10]

nee de wachtwoorden werden plain text verstuurd via de browser. Opslag zal prima encrypted zijn, maar dat gebeurt blijkbaar pas op de webserver.
Dat is trouwens normaal. als je inlogt wordt het wachtwoord wat je invult inderdaad niet encrypted verstuurd (behalve als je HTTPS gebruikt, maar dat is een ander geval). Dan op de server wordt het encrypted en vergeleken met de waarde in de database. Als de encrypted waarde overeenkomt met de encrypted waarde in de database, heb je het juiste wachtwoord ingevuld.
Wat je beschrijft (en op zich ook klopt) is een hash, geen encryptie. Encryptie is omkeerbaar als je de sleutel hebt, hash heeft geen sleutel en is niet omkeerbaar.
Beetje mierenneukerij. Ik leg het zo uit om het niet onnodig ingewikkelder te maken.
Klinkt eerder alsof de inloggegevens via GET verstuurd werden ipv POST
Dan is het waarschijnlijk niet af te luisteren zelfs via een openbaar wifi. Als de verbinding via HTTPS tot stand is gebracht, wat bij AH.nl het geval is, is de query string niet af te luisteren. Alleen via SNI kan je hostname te weten komen maar de rest is versleuteld.
Ze hebben ook een wachtwoord lengte limiet (15 characters). Gewoon een slechte implementatie, het is zo makkelijk een bcrypt implementatie te bouwen. Waarom zou jij het niet doen?
Daar kwam ik ook net achter. Wil ik een 100 karakter wachtwoord erin plempen, geeft dat ding weer een foutmelding dat 't te lang is.... beetje jammer.
Uit het artikel haal ik dat dit gebeurde tijdens het inlog proces. Wanneer de waarde die jij als wachtwoord opgeeft naar de server verstuurd om vergeleken te worden met een opgeslagen hash. Dat het clientside niet gehashed wordt voordat het naar de server gaat is niet heel vreemd. Dat dit gebeurd over een onbeveiligde verbinding is echter wel vreemd, en dat lijkt hier het probleem te zijn. Of zoals andere noemen, een verkeerde REST method gebruikt. Al hoewel de query params in een GET niet plain tekst zouden moeten zijn in combinatie met https.

[Reactie gewijzigd door Caayn op 9 november 2018 11:43]

Kan ook gewoon dat in plaatsnvan een POST request er nu een GET request gedaan werd. Dit zorgt er namelijk voor dat alle data in de URL zit.

Hieruit kan je niet zeggen hoe wachtwoorden opgeslagen worden. Ook kan de backend prima detecteren of een wachtwoord al gehashed is op de frontend, zo niet hashed de backend hem alsnog

[Reactie gewijzigd door hellfighter87 op 9 november 2018 11:41]

Mogelijk was het enkel zichtbaar tijdens inloggen en/of registratie, waarbij het wachtwoord naar de server wordt gestuurd ter verificatie.
Vervolgens kan op de server de controle nog steeds plaatsvinden met een hash in de database.

Zolang er https gebruikt werd is het deel in de adresbalk overigens niet te onderscheppen, dus enkel iemand die meekijkt in de adresbalk zou het wachtwoord dan kunnen bekijken.
Ja en ik verwacht de service providers het advertentie netwerk, counters en andere netwerk/website analyse/trackers zijn etc zijn
Iemand die perongeluk een form als een GET request verstuurd in plaats van een POST? Dat zou nooit door de code review en testen moeten kunnen komen.
Reviewers zijn ook maar mensen, ik heb soms veel te grote PR's voor m'n gezicht, dan ontglipt wel eens iets
Natuurlijk maar zowel een code review en tests? En ik verwacht dat er voor dergelijke kritieke dingen wel automatische tests zouden opgezet zijn.
En natuurlijk kun je een te grote pull request krijgen maar hier moet je ten eerste iets langer de tijd voor nemen en als je ziet dat er dingen in het account systeem worden aangepast je dubbel moet kijken.
Dit incident is dus een van de "voordelen" van devops.
De tijd voor bezinning en ingrijpen die er "vroeger" nog was is er niet meer.
Nee, uiteraard niet. Maar het zou in the first place al nooit geprogrammeerd moeten zijn.

Waar gewerkt wordt, worden fouten gemaakt. Als ik een euro zou krijgen voor elke fout die ik gemaakt heb, zou ik allang kunnen rentenieren :+
Als ik een euro zou krijgen voor elke fout die ik gemaakt heb, zou ik allang kunnen rentenieren :+
Als ik een euro zou krijgen voor iedere fout die ik maak, zou ik heel veel fouten maken ...
In het bronartikel lees je bovendien nog het volgende:
Door een programmeerfout zijn ah.nl inloggegevens van circa tienduizend klanten onbedoeld gedeeld met enkele online service providers van Albert Heijn.
en:
naast de betrokken klanten en de AP, zijn ook de online service providers ingelicht. Zij werken bijvoorbeeld samen met AH aan het verbeteren van de websites. Verder heeft Albert Heijn de betrokken service providers opdracht gegeven de informatie te verwijderen.
De gegevens zijn dus niet alleen plain-text verstuurd, maar ook gedeeld met 3e partijen. Dat is nog wel een stapje erger dan wat tweakers ervan overgenomen heeft.
Analytics en andere trackers slaan de url op, daarme in dit geval van een get request dus ook de wachtwoorden.
Dat zal waarschijnlijk de manier zijn waarop het gegaan is inderdaad. Maar je moet je natuurlijk afvragen waarom er berhaupt 3rd party scripts gebruikt zijn op een pagina waar wachtwoorden verwerkt worden. Dat is toch wel redelijk not-done.
Analytics op een login pagina..., wat zou er mis kunnen gaan op zo'n pagina en wat wil je er van meten?...
Daarnaast in de haast van de hedendaags populaire devops is blijkbaar onvoldoende getest.

Hm. umatrix kan meer leed voorkomen dan ik dacht. :+

[Reactie gewijzigd door tweaknico op 9 november 2018 12:23]

Albert Heijn heeft gewoon een beveiligde verbinding. De gegevens zijn op publieke netwerken dus niet zichtbaar. Het lek zit hem in analytics, waar de bezochte URL wel zichtbaar is.
Dus de AVG (GDPR) werkt wel. Sinds de wet effectief is geworden, al meer dan 18.000 (!!) meldingen van datalekken (https://duckduckgo.com/?q=18000+datalekken&atb=v8&ia=web).

Nu begint men (hopelijk) de omvang ervan te zien en worden (meer) mensen bewust dat hun data op internet gewoon niet veilig is.
Daar zijn we zo lang geleden al voor gewaarschuwd...film is nog steeds actueel...

[Reactie gewijzigd door FrankAlexander op 9 november 2018 12:38]

Hmm, dus login via GET parameter gedaan ipv POST?

Zeker niet netjes, maar gelukkig waren die 10000 wachtwoorden dan niet door 1 iemand centraal op te halen (zolang je niet bij een ISP werkt), maar kan je enkel aan de wachtwoorden die op jou netwerk werden ingevuld.

Edit: right, analytics pikt uiteraard die GET parameters op, wat verklaard hoe die 3th parties die wachtwoorden zien...

[Reactie gewijzigd door strykaizer op 9 november 2018 11:44]

Direct mijn wachtwoord (ook voor Bol.com) maar aangepast...

Goed dat het direct (binnen 3 dagen) wordt gemeld waardoor mensen actie kunnen ondernemen.

[Reactie gewijzigd door Blommie01 op 9 november 2018 11:52]

Bestaat deze endpoint dan wel?
Ik zou dan eigenlijk verwachten dat de gebruikers een "405 - Method not allowed" terugkrijgen.
Maar uit het verhaal lijkt het alsof de site gewoon blijft werken.

Zou het vreemd vinden als ze deze manier van inloggen ondersteunen namelijk.
Ik val ook onder deze klantgroep. Maar mag dan wel weer voor 10 euro gratis boodschappen doen. :9 Zonder enig voorbehoud. Dat vind ik dan wel weer netjes.
Netjes opgepakt vind ik. Er is een fout gemaakt, die is ontdekt, gemeld en vervolgens is de schade beperkt. Nu weet ik niet precies wat de schade zou kunnen zijn als iemand anders op je AH account in kan loggen, maar toch fijn dat ze het serieus nemen. Als ze nu nog actie ondernemen om eenzelfde fout in de toekomst te voorkomen hebben ze de hele lijst afgevinkt.
Sommige gebruiken dezelfde wachtwoord voor alles.
50 per account lijkt mij geen "relatief laag" bedrag, dan spreken we hier al over zo'n 500.000,-


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

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