Client-side versus server-side encryptie bij secure links
Waarom dit onderscheid ertoe doet
Als je een wachtwoord of geheim deelt via een secure link, wordt dat geheim ergens opgeslagen, al is het maar tijdelijk. De vraag is: wie heeft er toegang tot die opgeslagen data? Het antwoord hangt volledig af van waar de encryptie plaatsvindt: op de server van de aanbieder, of al op jouw apparaat voordat de data de server bereikt.
Veel aanbieders communiceren over "end-to-end encryptie" of "zero-knowledge" zonder precies uit te leggen wat dat in de praktijk betekent. Dit artikel geeft je de tools om dat zelf te beoordelen.
Server-side encryptie: hoe het werkt
Bij server-side encryptie stuur je de plaintext (het onversleutelde wachtwoord) naar de server. De server versleutelt die data vervolgens met een sleutel die hij zelf beheert en slaat het versleuteld op.
Voordelen:
- Eenvoudig te implementeren
- Werkt in elke browser zonder speciale code
- Versleuteld opgeslagen op schijf (beschermt tegen databreach op opslaglaag)
Nadelen:
- De aanbieder heeft (technisch gezien) toegang tot je data. De server ontvangt immers de plaintext voordat hij versleutelt.
- Als de server gecompromitteerd is tijdens de overdracht, is je geheim blootgesteld.
- Je vertrouwt volledig op de integriteit en het beveiligingsbeleid van de aanbieder.
Dit model is niet per se onveilig, maar het vereist vertrouwen in de aanbieder als derde partij.
Client-side encryptie: hoe het werkt
Bij client-side encryptie versleutelt je browser de data al voordat die de server bereikt. De server ontvangt uitsluitend versleutelde data en heeft nooit toegang tot de sleutel of de plaintext.
De sleutel wordt vaak verwerkt in het URL-fragment (het gedeelte na de #). URL-fragmenten worden standaard niet naar de server gestuurd door browsers, wat betekent dat de server de sleutel nooit ziet: zelfs niet in de serverlog.
Voordelen:
- Zelfs de aanbieder kan de data niet lezen
- Beschermt tegen aanvallen op de server zelf
- Sterkere privacygarantie
Nadelen:
- Complexer om correct te implementeren
- Sleutelbeheer ligt bij de gebruiker: als het URL-fragment verloren gaat, is de data onherstelbaar
- Vereist JavaScript in de browser
Wat betekent "zero-knowledge" echt?
Zero-knowledge verwijst naar het principe dat de aanbieder geen kennis heeft van de inhoud van wat je deelt. Echte zero-knowledge vereist client-side encryptie: de server mag de sleutel nooit zien of ontvangen.
Wees kritisch als een dienst "zero-knowledge" claimt maar de encryptie server-side uitvoert. Dat is een contradictie. Vraag altijd: wordt de data versleuteld voor of na verzending naar de server?
PassTransfer en encryptie
Correctie, september 2026: dit artikel beschreef PassTransfer eerder als een server-side model. Dat klopte tot juli 2026. Sindsdien versleutelt PassTransfer client-side, en de tekst hieronder beschrijft hoe het nu werkt.
PassTransfer versleutelt in je browser, voordat er iets naar ons verstuurd wordt. Je browser maakt een willekeurige sleutel aan, versleutelt daarmee je wachtwoord en de afzendernaam met AES-GCM, en zet die sleutel achter het # in de link. Browsers sturen het deel van een URL achter het hekje nooit mee naar de server. Wij krijgen hem dus niet, ook niet in onze logs.
Wat wij bewaren is de versleutelde waarde en het moment waarop de link verloopt. Meer niet. Bij het ophalen geven wij die waarde terug en wordt hij in dezelfde bewerking uit de database verwijderd; de browser van de ontvanger ontsleutelt lokaal. Wij kunnen de inhoud op geen enkel moment lezen.
Die encryptie staat niet op zichzelf. Je combineert hem met one-time retrieval, een korte vervaltijd en kanaalscheiding: stuur de link via een ander kanaal dan waarover je het wachtwoord aankondigde. Dat sluit ook aan bij wat de AVG vraagt van het delen van wachtwoorden.
Twee gevolgen maken het eerlijke verhaal compleet.
Kwijt is kwijt. Omdat wij de sleutel niet hebben, kunnen wij een geheim niet terughalen. Verlies je de link, dan is de inhoud onherstelbaar. Dat is geen tekortkoming maar de prijs van het model.
Geen HTTPS, geen versleuteling. Kan je browser niet veilig versleutelen, dan weigert het formulier te versturen. Er is geen stille terugval naar een server-side pad: dat zou precies de garantie ondermijnen die je hier komt halen.
De kanttekening die bij elke browser-E2EE hoort
Client-side encryptie in een browser betekent dat de aanbieder de code levert die de versleuteling uitvoert. Dat geldt voor ons net zo goed als voor elke andere webgebaseerde tool. Wil je die aanname niet doen, dan is een lokaal geïnstalleerde tool met een geauditeerde client het juiste antwoord, en geen website. Dat is een legitieme keuze en wij zullen niet doen alsof dat niet zo is. Heb je vragen over ons beveiligingsmodel, mail ons gerust op hello@passtransfer.com.
Conclusie
Server-side encryptie beschermt je data op de opslaglaag en vereist vertrouwen in de aanbieder. Client-side encryptie verwijdert dat vertrouwen als vereiste, maar verschuift de verantwoordelijkheid naar jou: de sleutel zit in de link, en wie de link kwijtraakt, raakt de inhoud kwijt.
Voor het delen van een enkel geheim met een enkele ontvanger is die ruil gunstig. De link leeft toch maar kort, en je hoeft ons niet op ons woord te geloven over wie er in onze database kan kijken: wij kunnen de inhoud niet lezen omdat wij de sleutel niet hebben. Daarom versleutelt PassTransfer client-side. Meer context vind je in de complete gids over veilig wachtwoorden delen.
