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
PassTransfer versleutelt wachtwoorden op de server met Laravel's Crypt facade en slaat de versleutelde waarde op in de database. Na het ophalen door de ontvanger wordt de waarde direct uit de database verwijderd. Dit is een server-side model met een sterke verwijderingsgarantie: de data blijft niet rondslingeren.
Voor de meeste zakelijke use cases — interne credential-overdracht, klantcommunicatie, projectdeling — biedt dit niveau van beveiliging een solide basis. Combineer het met one-time retrieval, een korte vervaltijd en kanaalscheiding voor maximale bescherming.
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 als gebruiker. Welk model het beste past, hangt af van je dreigingsmodel. Voor de meeste organisaties is een betrouwbare server-side implementatie met strikte dataretentie een pragmatische en afdoende keuze. Meer context vind je in de complete gids over veilig wachtwoorden delen.
