In juni 2026 hebben drie gebeurtenissen het debat over de werkelijke garanties van „zero-knowledge“-managers opnieuw aangewakkerd: een academische studie van ETH Zurich en Aalto University brengt 25 aanvallen in kaart die exploiteerbaar zijn als de server gecompromitteerd is, een datalek bij LastPass loopt via een CRM van een derde, en een onderzoeker van DEF CON 33 demonstreert de kaping van autofill via clickjacking. Hier is de concrete impact van deze drie gebeurtenissen op de ARDNTECH-architectuur, zonder marketingretoriek.
Gepubliceerd op 23 juni 2026 door ARDNTECH EI · Interne analyse op basis van de openbare onthullingen
Een diefstal van OAuth-tokens bij Klue (een sales-intelligence-tool geïntegreerd met Salesforce) gaf toegang tot de contactgegevens van LastPass-klanten. De versleutelde kluizen werden niet blootgesteld. Het werkelijke risico is gerichte phishing op basis van een contactlijst gestolen bij een perifere subverwerker, niet de compromittering van de cryptografische kern.
Les : zero-knowledge beschermt de kluizen, niet de door derden gehouden metadata.
Matteo Scarlata en zijn coauteurs (overgenomen door Ars Technica) brengen 25 aanvallen in kaart die aantonen dat de „zero-knowledge“-garanties van Bitwarden, Dashlane en LastPass verzwakken als de server gecompromitteerd is en bepaalde opt-in-functies actief zijn: accountherstel, delen via distributie van publieke sleutels, cryptografische achterwaartse compatibiliteit (KDF-downgrade).
Les : een formeel correcte ZK moet bestand zijn tegen het scenario van een gecompromitteerde server, niet alleen tegen een eerlijke beheerder.
Marek Tóth toont aan dat de autofill van 11 managers kan worden getriggerd door een onzichtbare overlay. Eén enkele klik op een nep-cookiebanner volstaat om de velden van een door de aanvaller gecontroleerde pagina in te vullen. Het getroffen oppervlak is de DOM-injectielogica van de extensie, niet de serverkluis.
Les : de browserextensie is een aanvalsoppervlak dat losstaat van de server en onafhankelijk gehard moet worden.
De studie richt zich op drie families van functies die, op een gecompromitteerde server, de ZK-garanties verzwakken. Hier is hun overeenkomst in de ARDNTECH-architectuur.
| Vector van de studie | ARDNTECH-architectuur | Oordeel |
|---|---|---|
|
Accountherstel
Kopie van de kluissleutel opgeslagen aan de serverzijde, bruikbaar als de server gecompromitteerd is |
De wrap wordt aan de clientzijde geproduceerd (Argon2id) op basis van een herstelcode die alleen de gebruiker bezit. De server slaat ondoorzichtige wraps op: hij kan de sleutel niet opnieuw afleiden. Verbruik met onmiddellijke scrub. | Gezond |
|
Cryptografische downgrade
Een client dwingen een zwakker algoritme te gebruiken tijdens de herstel-wrap |
Geblokkeerd aan de serverzijde: een inspectiecomponent parseert de werkelijke armor (SKESK v6, S2K Argon2id, AEAD aanwezig, minimumkosten). Een gemanipuleerde client die downgradet wordt geweigerd en gedwongen tot een heractivering. | Geneutraliseerd |
|
Substitutie van publieke sleutel bij het delen
De server levert zijn eigen sleutel in plaats van die van de ontvanger |
De server stelt de publieke sleutel + vingerafdruk van de ontvanger beschikbaar. Een fix van juni 2026 (extensies-repo) dekt de controle aan de clientzijde. Resterend punt: ervoor zorgen dat een sleutelwijziging van een bekend contact een expliciete waarschuwing triggert. | In verificatie |
|
Admin-herstelsleutels (type LastPass)
Een groepsbeheerder kan de kluis van een gebruiker aan de serverzijde herversleutelen |
ARDNTECH beschikt niet over een „break-glass admin“-mechanisme aan de serverzijde dat de kluissleutel van een gebruiker zou herversleutelen naar een adminsleutel. Het delen binnen een team verloopt uitsluitend via de publieke sleutel van het team en zijn vingerafdruk. | Gezond door ontwerp |
Samenvatting : een gecompromitteerde ARDNTECH-server maakt het niet mogelijk de herstel-wraps te ontsleutelen - ze zijn ondoorzichtig, aan de clientzijde afgeleid van een geheim dat de server niet bezit, en de KDF-downgrade wordt bij de registratie geweigerd. Dit zijn precies de scenarios die in andere managers worden uitgebuit door de ETH/Aalto-studie. Ze worden hier gesloten door architecturale keuzes gedocumenteerd in het dreigingsmodel.
Het onderzoek van Tóth richt zich op de DOM-injectielogica van de extensies. Autofill en autologin zijn de betrokken oppervlakken. De serverkluis is niet de oorzaak - het is de extensie die de velden invult die misleid kan worden. De volgende punten worden momenteel geaudit in de ARDNTECH-extensie.
visibility:hidden, vrijwel nulgrootte of bedekt element (hit-testing van het klikpunt).window.top === window.self of dezelfde origin.z-index, hercontrole van zichtbaarheid op het moment van de klik.Een gezonde cryptografische kern kan worden omzeild door de perifere SaaS-stack. De LastPass-kluizen zijn niet bewogen, maar een contactlijst werd gestolen bij een CRM-integrator van een derde.
De huidige subverwerkers van ARDNTECH (Scaleway, Brevo, Stancer, HIBP, Bugsink) zijn afgebakend in het register dat is gepubliceerd op de pagina Vertrouwen. Zero-knowledge beschermt de kluizen, niet een contactlijst in een niet-geregistreerd CRM van een derde.
Rotatie van de tokens van integraties van derden, minimale scopes, onmiddellijke intrekking bij een incident. Toegang tot perifere systemen mag het niet mogelijk maken een kaart van de klanten te reconstrueren.
Elke nieuwe subverwerker is onderwerp van een bijwerking van het DPA vóór integratie. Het register is openbaar toegankelijk op de pagina Vertrouwen.
Verifieerbare zero-knowledge, gehost in Frankrijk, broncode onder AGPLv3. De private bèta is toegankelijk na inschrijving.