Wachtwoorden per e-mail versturen – maar dan veilig

#Het alledaagse probleem achter een schijnbaar triviale taak

Een collega heeft toegang nodig tot het rapportagesysteem, een cliënt wil het wachtwoord voor een versleuteld document, een externe dienstverlener heeft de inloggegevens voor een staging-omgeving nodig. De reflexmatige reactie is bijna altijd dezelfde: het wachtwoord in een e-mail typen en op verzenden klikken. Die reflex is begrijpelijk, maar hij is de oorzaak van een verrassend groot deel van de vermijdbare beveiligingsincidenten.

Het probleem is niet de e-mail als zodanig. Het probleem is dat een wachtwoord in platte tekst, zodra het verzonden is, aan uw controle ontsnapt. Het bevindt zich daarna op meerdere plaatsen tegelijk, blijvend en doorzoekbaar. Wie inloggegevens veilig wil delen, hoeft de e-mail dus niet af te schaffen, maar moet begrijpen wat er bij het verzenden werkelijk beschermd is – en wat niet. Daarover gaat dit artikel.

• Het alledaagse probleem achter een schijnbaar triviale taak
• Waarom een wachtwoord in platte tekst in de mailbox een risico is
  • Wat TLS beschermt – en wat niet
  • Chattools zijn geen veilig alternatief
• Het grondprincipe van veilige wachtwoordoverdracht
• De methoden vergeleken
  • Het tweekanaalsprincipe
  • Wachtwoordmanagers met deelfunctie
  • Eenmalige links
  • Eind-tot-eindversleuteling en zero-knowledge
• Het verzenden helemaal vermijden waar het kan
• Wachtwoorden AVG-conform versturen
• Checklist: inloggegevens veilig overdragen
• Veelgemaakte fouten
• Veelgestelde vragen
• Conclusie

#Waarom een wachtwoord in platte tekst in de mailbox een risico is

Een verzonden e-mail is geen punt-tot-puntoverdracht. Hij passeert mailservers, wordt opgeslagen in mailboxen, vastgelegd in back-ups, gesynchroniseerd over mobiele apparaten en niet zelden doorgestuurd naar derden. Elk van die stations is een eigen bewaarplaats. Een wachtwoord dat u vandaag verstuurt, kan over een jaar nog in een mailboxarchief, een back-up of de cache van een allang vergeten mailclient liggen.

Het werkelijke risico van een wachtwoord in platte tekst is dus niet het moment van verzenden, maar de blijvendheid ervan. Drie eigenschappen maken e-mail hier kwetsbaar:

• Duurzaamheid: berichten blijven standaard bewaard, vaak jarenlang, zonder dat iemand ze bewust heeft willen bewaren.
• Vermenigvuldiging: mailbox van verzender en ontvanger, servers, back-ups, doorstuuracties – hetzelfde geheim bestaat tegelijk op vele plaatsen.
• Doorzoekbaarheid: wie een mailbox compromitteert, zoekt gericht naar termen als „wachtwoord", „toegang" of „login" en vindt ze betrouwbaar.

Als een aanvaller één enkele mailbox compromitteert – via phishing of een hergebruikt wachtwoord – erft hij niet alleen de actuele correspondentie, maar elk geheim dat ooit in platte tekst is verzonden. Dat is het mechanisme waardoor één gecompromitteerd account een keten van verdere overnames wordt.

#Wat TLS beschermt – en wat niet

Op dit punt komt steevast het bezwaar: „Maar onze e-mail is toch versleuteld." Dat klopt meestal maar half. Wijdverbreid is de transportversleuteling (TLS), die de verbinding tussen mailservers beveiligt. Zij beschermt het bericht terwijl het onderweg is – dus tegen meelezen op de lijn.

TLS beschermt echter niet de rustende inhoud. Zodra de e-mail in een mailbox is aangekomen, ligt hij daar leesbaar – voor de ontvanger, voor iedereen die toegang tot die mailbox krijgt, en voor de systemen die hem opslaan en back-uppen. Transportversleuteling is noodzakelijk, maar zij is geen eind-tot-eindversleuteling en lost het blijvendheidsprobleem niet op. Een wachtwoord dat in platte tekst in de berichttekst staat, is na aflevering even blootgesteld als daarvoor.

#Chattools zijn geen veilig alternatief

Wie wachtwoorden om die reden niet per mail maar via Slack, Microsoft Teams of WhatsApp verstuurt, verplaatst het probleem alleen. Zakelijke chattools loggen berichten standaard, houden ze doorzoekbaar en zijn onderworpen aan administratieve toegang en export. Een wachtwoord in een teamkanaal is zichtbaar voor alle huidige en toekomstige leden van dat kanaal; een wachtwoord in een direct bericht blijft in de geschiedenis tot iemand het actief verwijdert – als het bewaarbeleid dat al toelaat.

Ook waar transportversleuteling bestaat, blijft de inhoud aan de serverzijde of in de gespreksgeschiedenis opgeslagen. De vuistregel is daarom kanaalonafhankelijk: een geheim dat in een doorzoekbare, blijvende geschiedenis belandt, is geen geheim meer.

#Het grondprincipe van veilige wachtwoordoverdracht

Uit deze zwaktes valt af te leiden wat een veilige wachtwoordoverdracht moet leveren. Drie principes dragen de meeste geschikte methoden:

1. Scheiding. Het geheim en de context waartoe het behoort, reizen niet samen. Wie de loginnaam en het wachtwoord over hetzelfde kanaal stuurt, geeft een aanvaller beide tegelijk.
2. Vergankelijkheid. Het geheim bestaat slechts zolang het nodig is. Na opvraging of verloop verdwijnt het, in plaats van onbeperkt te blijven liggen.
3. Zero-knowledge. De dienst waarover de overdracht loopt, kan de inhoud zelf niet lezen. Het geheim wordt versleuteld voordat het de verzender verlaat, en alleen de ontvanger bezit de sleutel.

Deze drie principes staan niet op gespannen voet met e-mail – ze vullen die aan. De e-mail blijft het comfortabele overdrachtskanaal; hij vervoert alleen niet meer het wachtwoord zelf, maar een verwijzing ernaar die op zichzelf waardeloos is zodra die eenmaal is ingewisseld of verlopen.

#De methoden vergeleken

Er is niet één juiste methode, maar geschiktheid afhankelijk van de context. Het onderstaande overzicht plaatst de gangbare opties ten opzichte van elkaar.

#Het tweekanaalsprincipe

De klassieke, arbeidsextensieve verbetering is scheiding over twee kanalen: de loginnaam gaat per e-mail, het wachtwoord via een andere weg, zoals telefonisch of per sms. Een aanvaller die alleen de mailbox beheerst, houdt dan slechts de helft in handen.

De methode is beter dan niets, maar kent grenzen. Het telefonisch doorgegeven wachtwoord kan worden genoteerd; de sms blijft op het apparaat; en de aanpak schaalt slecht als u regelmatig of aan veel ontvangers inloggegevens overdraagt. Zij verhelpt de scheiding, maar niet de blijvendheid.

#Wachtwoordmanagers met deelfunctie

Binnen een team of organisatie is een wachtwoordmanager het meest robuuste middel. Oplossingen als Bitwarden, 1Password of een gedeelde KeePass-database laten u inloggegevens vrijgeven zonder ze ooit in platte tekst te versturen. De ontvanger ziet het wachtwoord in een versleutelde kluis, niet in een mailbox.

De beperking is organisatorisch van aard: dit delen werkt alleen betrouwbaar als beide kanten dezelfde of een compatibele manager gebruiken. Voor overdracht aan externe cliënten, overheden of eenmalige contacten die geen gemeenschappelijk systeem hebben, is de wachtwoordmanager daarom vaak geen begaanbare weg.

#Eenmalige links

Hier komt de eenmalige link (Engels one-time link) in beeld. In plaats van het wachtwoord zelf te versturen, deponeert u het bij een dienst die daarvoor een eenmalig opvraagbare link genereert. Die link stuurt u per e-mail. Bij de eerste keer openen wordt het geheim getoond – en daarna verwijderd. Een tweede opvraging loopt op niets uit.

Daaruit volgt een nuttige eigenschap: bereikt de ontvanger een reeds verbruikte link, dan is dat een waarschuwingssignaal. Ofwel is het geheim al opgevraagd, ofwel is iemand anders u voor geweest. De eenmalige link maakt een compromittering dus niet alleen onwaarschijnlijker, hij maakt die zichtbaar. Hoe dit mechanisme in detail werkt, behandelt het artikel Eenmalige links: werking en toepassingen uitvoeriger.

#Eind-tot-eindversleuteling en zero-knowledge

Een eenmalige link alleen is nog geen volledig antwoord. Doorslaggevend is of de aanbieder van de dienst het gedeponeerde geheim zelf kan lezen. Bij een zero-knowledge-methode is dat uitgesloten: het wachtwoord wordt al in de browser van de verzender versleuteld voordat het wordt overgedragen. De voor ontsleuteling benodigde sleutel maakt deel uit van de link – technisch in het zogenoemde fragment achter het hekje, dat helemaal niet aan de server wordt overgedragen. De dienst slaat dus alleen een voor hem onleesbare cijfertekst op.

Het praktische gevolg is verstrekkend: zelfs als de dienstaanbieder zou worden gecompromitteerd, valt uit de opgeslagen gegevens geen wachtwoord te reconstrueren, omdat de sleutel daar nooit aanwezig was. Wat zero-knowledge concreet betekent en waar de grenzen liggen, verdiept het artikel Zero-knowledge uitgelegd.

Crymbl combineert deze bouwstenen: een in de browser versleuteld geheim, een eenmalige link voor de overdracht en een zelfvernietigende opvraging. De e-mail vervoert dan alleen nog de link – het wachtwoord zelf stond op geen enkel moment in platte tekst in de mailbox.

#Het verzenden helemaal vermijden waar het kan

De veiligste overdracht is die welke helemaal niet plaatsvindt. Voordat u nadenkt over het „hoe", loont de vraag of een wachtwoordverzending überhaupt nodig is:

• Uitnodigings- en registratiestromen: veel systemen laten u nieuwe gebruikers aanmaken via een uitnodigingslink, waarbij de ontvanger zijn eigen wachtwoord instelt. Dan verlaat er nooit een wachtwoord de verzender.
• Gefedereerde aanmelding (SSO): waar single sign-on beschikbaar is, vervalt de afzonderlijke wachtwoordoverdracht volledig.
• Verplichte wisseling bij eerste login: is een initieel wachtwoord onvermijdelijk, dan zou het slechts kort geldig moeten zijn en bij de eerste aanmelding verplicht moeten worden gewijzigd.

Deze maatregelen halen het geheim uit de overdracht. Wat nooit wordt overgedragen, kan onderweg ook niet verloren gaan.

#Wachtwoorden AVG-conform versturen

De wijze van wachtwoordoverdracht is niet alleen een technische, maar ook een privacyrechtelijke kwestie. Inloggegevens beschermen vrijwel altijd de toegang tot persoonsgegevens; soms zijn ze zelf persoonsgegevens. Daarmee valt hun bescherming rechtstreeks onder de AVG.

Bepalend is artikel 32 AVG, dat voor de verwerking van persoonsgegevens passende technische en organisatorische maatregelen verlangt, evenredig aan het betreffende risico – uitdrukkelijk met inbegrip van versleuteling waar dat passend is. Een wachtwoord in platte tekst over meerdere mailboxen en back-ups verspreiden, laat zich tegen die maatstaf moeilijk als passende maatregel rechtvaardigen. Daarbij komt de verantwoordingsplicht: verwerkingsverantwoordelijken moeten niet alleen passend handelen, maar dit ook kunnen aantonen.

De Autoriteit Persoonsgegevens verwacht in lijn hiermee passende maatregelen, afgestemd op de gevoeligheid van de gegevens. Voor de overdracht van inloggegevens valt daaruit een heldere lijn af te leiden: vertrouwelijk overdragen, geldigheidsduur beperken, overbodige kopieën vermijden, het proces aantoonbaar vastleggen. Methoden met vergankelijkheid en zero-knowledge sluiten precies op deze eisen aan. Het bredere kader behandelt het artikel AVG-conforme informatie-uitwisseling.

#Checklist: inloggegevens veilig overdragen

• Nagaan of het verzenden van een wachtwoord vermeden kan worden (uitnodigingslink, SSO, verplichte wisseling).
• Loginnaam en wachtwoord nooit over hetzelfde kanaal versturen.
• Geen wachtwoord in platte tekst in e-mail, Slack, Teams of andere doorzoekbare geschiedenissen.
• Voor de overdracht een eenmalige link met beperkte geldigheid gebruiken.
• Letten op een zero-knowledge-methode waarbij de dienst de inhoud niet kan lezen.
• Ontvangers instrueren een reeds verbruikte link als waarschuwingssignaal te behandelen.
• Initiële wachtwoorden slechts kort geldig houden en bij de eerste login tot wisseling dwingen.
• Het proces traceerbaar vastleggen om aan de verantwoordingsplicht te voldoen.

#Veelgemaakte fouten

Ook met goede gereedschappen sluipen er typische fouten in. De meest voorkomende is het vermengen van de link met verklarende context – bijvoorbeeld „Hier het wachtwoord voor het admin-account: [link]." Daarmee verraadt de e-mail waartoe het geheim behoort, zelfs als de link al verbruikt is. Houd het begeleidende bericht kort en contextarm.

Een tweede fout is een te lange geldigheidsduur. Een eenmalige link die wekenlang opvraagbaar blijft, ondermijnt het principe van vergankelijkheid. Kies het kortste venster dat de ontvanger realistisch kan halen. De derde fout is de stilzwijgende aanname dat de ontvanger even zorgvuldig te werk gaat – bijvoorbeeld dat hij de opgevraagde inhoud niet alsnog in een e-mail kopieert. Een korte instructie over de omgang hoort daarom bij de overdracht. De bescherming tegen zulke patronen is het onderwerp van Bescherming tegen onbedoelde openbaarmaking.

#Veelgestelde vragen

Is het veilig om wachtwoorden per e-mail te versturen? Een wachtwoord in platte tekst per e-mail is niet veilig, omdat het blijvend, vermenigvuldigd en doorzoekbaar over meerdere mailboxen en back-ups achterblijft. Het verzenden wordt pas veilig wanneer de e-mail in plaats van het wachtwoord alleen een eenmalige link vervoert, waarachter het geheim versleuteld en vergankelijk is gedeponeerd.

Mag ik wachtwoorden via Slack of Microsoft Teams versturen? Dat is af te raden. Deze tools slaan berichten standaard op, houden ze doorzoekbaar en zijn onderworpen aan administratieve toegang. Een wachtwoord in een kanaal of geschiedenis blijft zichtbaar tot het actief wordt verwijderd – als het bewaarbeleid dat toelaat.

Is het voldoende om login en wachtwoord over twee verschillende kanalen te sturen? Scheiding is een zinvolle verbetering, maar verhelpt slechts een deel van het probleem. Het over het tweede kanaal verstuurde wachtwoord kan nog steeds worden genoteerd of opgeslagen. In combinatie met een vergankelijke, versleutelde methode komt de scheiding pas volledig tot haar recht.

Wat is een eenmalige link? Een eenmalige link verwijst naar een geheim dat precies één keer kan worden opgevraagd. Bij de eerste toegang wordt de inhoud getoond en daarna verwijderd; elke verdere opvraging loopt op niets uit. Daardoor is een reeds verbruikte link een aanwijzing dat het geheim is opgevraagd.

Wat betekent zero-knowledge in deze context? Zero-knowledge betekent dat de bemiddelende dienst het geheim zelf niet kan lezen. De versleuteling gebeurt vóór de overdracht, en de sleutel blijft in de link zonder aan de server te worden overgedragen. Zelfs bij een compromittering van de dienst zou de inhoud niet te reconstrueren zijn.

Hoe verstuur ik inloggegevens AVG-conform? Draag ze vertrouwelijk over, beperk hun geldigheid, vermijd overbodige kopieën en leg het proces vast. Artikel 32 AVG verlangt passende technische en organisatorische maatregelen; vergankelijke, versleutelde methoden voldoen daar duidelijk beter aan dan een verzending in platte tekst.

#Conclusie

„Wachtwoorden per e-mail versturen" hoeft niet in tegenspraak te zijn met veiligheid – mits de e-mail niet meer het wachtwoord vervoert, maar alleen een verwijzing ernaar. Het werkelijke risico ligt nooit in het verzenden zelf, maar in de blijvendheid van platte tekst over vele bewaarplaatsen heen.

Wie scheiding, vergankelijkheid en zero-knowledge samenbrengt, keert dat risico om: het geheim bestaat slechts zolang het nodig is, is onleesbaar voor de bemiddelende dienst en maakt onbevoegde toegang zichtbaar. De comfortabele e-mail blijft – de kwetsbaarheid verdwijnt.