Een Login die Niemand Hoefde te Raden
Dropbox maakte op 2 september 2026 bekend dat ongeveer 5.000 accounts waren gecompromitteerd door een fout in Lenovo's identiteitssysteem, niet in Dropbox's eigen wachtwoordcontrole. Het toegangsvenster liep van 4 tot 21 augustus 2026, voordat Dropbox het opmerkte. Een getroffen gebruiker beschreef het eerste teken dat er iets mis was: de Dropbox-inlogpagina begon voor haar e-mailadres de optie Doorgaan met SSO aan te bieden, terwijl ze nooit een Lenovo-ID had aangemaakt.
Het mechanisme was eenvoudig zodra het eenmaal ontdekt was. Een aanvaller kon een Lenovo-ID registreren met het e-mailadres van een slachtoffer, en Lenovo's verificatieproces vereiste niet dat die persoon eerst bewees dat hij die inbox beheerde. Dropbox's eigen systemen, die jaren eerder Lenovo's Identity Provider Services hadden geïntegreerd voor single sign-on, behandelden die vers aangemaakte en ongeverifieerde Lenovo-ID vervolgens als voldoende bewijs om het bijbehorende Dropbox-account te ontgrendelen. Lenovo verklaarde dat het, zodra het probleem was vastgesteld, samen met Dropbox snel aan het beperken van het risico heeft gewerkt.
De Fout Zat Nooit in Dropbox's Eigen Wachtwoord
Dit is het detail waar het de moeite waard is bij stil te staan: niemands Dropbox-wachtwoord werd geraden, gelekt of hergebruikt. De 5.000 getroffen accounts werden niet gehackt omdat hun eigenaren zwakke inloggegevens kozen. Ze werden gehackt omdat Dropbox op enig moment had besloten een tweede bedrijf te laten instaan voor wie een e-mailadres bezit, en nooit opnieuw heeft gecontroleerd of dat proces daadwerkelijk betrouwbaar was.
Tweestapsverificatie zou elk van deze overnames hebben tegengehouden, want geen van de 5.000 accounts had het ingeschakeld. Maar de precieze les is niet simpelweg schakel tweestapsverificatie in. Het is dat een gefedereerde login geen gemaksfunctie is naast de echte beveiliging; zodra je er een inschakelt, wordt de verificatiekwaliteit van de partner de verificatiekwaliteit van je eigen product, of je die nu hebt gecontroleerd of niet.
Elk Bedrijf dat Inloggen met X Accepteert Heeft Deze Vraag
Dropbox is geen ongewoon onzorgvuldig bedrijf, en dit is geen verhaal over de fout van een enkele leverancier. Het is een verhaal over een categorie defect die bestaat in elk product dat ooit voor het gemak een Inloggen met Google-, Inloggen met Microsoft-, of Inloggen met de ID van een hardwarefabrikant-knop heeft toegevoegd. Elke van die knoppen breidt stilletjes de beveiligingsperimeter van je eigen product uit met een systeem dat je niet beheert en dat je na de integratie zelden opnieuw onderzoekt.
De praktische test voor elke ondernemer is specifiek: kun je voor elke externe login die je product accepteert precies benoemen hoe die aanbieder bevestigt dat iemand een e-mailadres bezit voordat hij je product een geverifieerde sessie overhandigt? Als het eerlijke antwoord is we namen aan dat ze dat goed controleerden, dan is die aanname het hele aanvalsoppervlak, en dit incident laat zien hoe het eruitziet wanneer die aanname onjuist blijkt.
Wat Dropbox Heeft Veranderd
Dropbox's oplossing was structureel, niet cosmetisch. Het liet alle bestaande Lenovo-ID-sessies verlopen, verwijderde de koppeling tussen Lenovo-ID's en Dropbox-accounts volledig, en vereist nu het echte Dropbox-wachtwoord voordat een aan Lenovo gekoppelde aanmelding kan doorgaan, waarmee precies het gat werd gedicht dat een vers aangemaakte, ongeverifieerde identiteit liet doorgaan voor een reeds bestaand account.
Dat is de juiste oplossing, en het is ook degene die vanaf het begin de standaard had moeten zijn: de identiteitsbevestiging van een partner zou een reeds bestaande, geauthenticeerde sessie moeten verlengen, nooit op zichzelf een nieuwe geauthenticeerde sessie moeten aanmaken.
Lees hierna: McKesson viel door een telefoontje, niet door een wachtwoordkraak | 8,7 miljoen records, één sleutel voor iedereen zichtbaar
