Elk bedrijf doet het: even een wachtwoord doorsturen naar een collega, een API-token naar de webbouwer, inloggegevens voor de boekhouding naar de accountant. Meestal gaat dat via mail of WhatsApp, want dat is waar het gesprek toch al plaatsvindt. Het voelt onschuldig, want het duurt maar even.
Het probleem is dat het niet even duurt. Een wachtwoord in een mailtje blijft jaren staan: in twee postvakken, in de back-ups van beide mailomgevingen, in een doorgestuurde kopie die niemand meer weet, en op elke telefoon waarop dat account is ingesteld. Datzelfde geldt voor chatberichten. Het bericht is gelezen, de inhoud blijft.
In dit artikel: waarom dit een groter risico is dan het lijkt, wat de AVG hier eigenlijk van vindt, hoe eenmalige deellinks het oplossen, en hoe wij dat met SecretsMonkey hebben ingericht.
Waarom een wachtwoord in de mail een probleem is
De reflex is te denken dat het risico onderweg zit: iemand die meeleest. In de praktijk is transport zelden het zwakke punt, want mailverkeer tussen serieuze providers is versleuteld. Het risico zit in de opslag.
Het bericht overleeft de aanleiding
Een gedeeld wachtwoord heeft een gebruiksduur van vijf minuten en een levensduur van vijf jaar. Zolang het bericht bestaat, bestaat het wachtwoord op een plek waar niemand meer naar kijkt. Wie later toegang krijgt tot een van die postvakken, krijgt de hele geschiedenis erbij. Precies dat maakt het aantrekkelijk voor aanvallers: een gekaapt mailaccount is niet alleen toegang tot mail, het is een archief van andermans inloggegevens.
Hoe dat in de praktijk gebeurt, beschreven we eerder in het artikel over de wachtwoordspray-campagne tegen Microsoft 365. De eerste toegang is zelden het einddoel, het is de springplank naar wat er in dat postvak ligt opgeslagen.
Je verliest de controle over kopieën
Zodra een wachtwoord in een mailthread staat, bepaal jij niet meer waar het heen gaat. Het wordt doorgestuurd naar een collega die “even meekijkt”, het belandt in een gearchiveerde thread bij de klant, het staat in de export die iemand maakte bij het wisselen van baan. Terughalen kan niet. Weten wie het heeft, kan ook niet.
Chat is niet beter, alleen informeler
WhatsApp en Teams voelen vluchtiger dan mail, maar dat is een gevoel, geen eigenschap. Chatgeschiedenis wordt bewaard, gesynchroniseerd naar meerdere apparaten en vaak automatisch geback-upt naar een cloudopslag die buiten je eigen beheer valt. Bij WhatsApp op een privételefoon staat bedrijfsdata daarmee ineens in een privéaccount, iets wat zelden ergens is vastgelegd.
Wat de AVG hier van vindt
De AVG schrijft nergens letterlijk voor dat je geen wachtwoorden mag mailen. Wat er wel staat is de plicht om passende technische en organisatorische maatregelen te nemen, en om niet meer gegevens te bewaren dan nodig voor het doel. Op beide punten valt een gemaild wachtwoord slecht uit.
Zodra achter dat wachtwoord persoonsgegevens zitten, en dat is bij een boekhoudpakket, een CRM of een personeelssysteem vrijwel altijd het geval, is de sleutel tot die gegevens zelf onderdeel van je beveiliging. Een sleutel die jarenlang onbeheerd in een postvak ligt, is moeilijk te verdedigen als passende maatregel na een datalek. De Autoriteit Persoonsgegevens kijkt bij een melding niet alleen naar wat er is gebeurd, maar ook naar wat je redelijkerwijs had kunnen voorkomen.
Voor organisaties die onder de Cyberbeveiligingswet vallen komt daar de zorgplicht rond toegangsbeheer bovenop. Ook het NCSC wijst er in zijn basismaatregelen op dat het beheer van toegangsmiddelen net zo serieus hoort te zijn als het beheer van de systemen zelf.
Hoe een eenmalige deellink het oplost
De oplossing is simpeler dan de meeste bedrijven denken. In plaats van het wachtwoord zelf te versturen, verstuur je een verwijzing die precies één keer werkt en daarna verdwijnt.
Het principe
Je plakt het wachtwoord, token of notitie in een webformulier. De inhoud gaat versleuteld naar de server, en de sleutel om het te openen zit uitsluitend in de link die je terugkrijgt. Die link stuur je naar de ontvanger. Zodra die hem opent, ziet hij de inhoud en wordt die daarna vernietigd. Kijkt er niemand, dan verdwijnt het alsnog na de vervaltijd die jij hebt ingesteld.
Het verschil met mailen is dat er na afloop niets blijft staan. Niet bij de ontvanger, niet in jouw verzonden items, en ook niet bij de aanbieder van de dienst.
Waarom dat ontwerp uitmaakt
Bij SecretsMonkey wordt de sleutel afgeleid uit het token in de deellink, en dat token slaan we nergens op. In de database staat alleen een onomkeerbare afdruk ervan: genoeg om de juiste regel terug te vinden, niet genoeg om hem te openen. Wie de database in handen krijgt, of dat nu een beheerder, een inbreker of een justitiële partij is, heeft daarmee versleutelde tekst en geen sleutel.
Dat is geen marketingzin maar een ontwerpkeuze met een consequentie die we ook uitspreken: een geheim dat bekeken of vervallen is, kunnen wij niet terughalen. Hoe dringend het verzoek ook is. Een dienst die dat wel zou kunnen, bewaart per definitie iets wat hij niet zou moeten hebben.
De praktische instellingen
Zonder account kies je een vervaltijd van vijftien minuten, een uur, vier uur of maximaal een dag. Het geheim is dan één keer te bekijken, maximaal acht kilobyte tekst, en het komt in geen enkel overzicht te staan. De link is de enige kopie.
Met een gratis account kan er meer: meerdere weergaven per geheim, een looptijd tot dertig dagen, ruimere inhoud, een melding zodra iemand kijkt, een overzicht van je eigen geheimen en een knop om er zelf een te vernietigen voordat de tijd om is. Die melding is in de praktijk waardevoller dan hij klinkt: als jij een link stuurt en er wordt binnen een minuut op geklikt terwijl je collega nog in een vergadering zit, weet je dat er iets niet klopt.
Het toegangswachtwoord als tweede slot
Wie de link heeft, kan het geheim openen. Dat is precies waarom er een optioneel toegangswachtwoord is: de ontvanger moet dat eerst invullen voordat de inhoud verschijnt. De regel daarbij is simpel: geef dat wachtwoord door via een ander kanaal dan de link. Link per mail, toegangswachtwoord per telefoon of sms. Twee kanalen die allebei gecompromitteerd zijn, is een heel ander scenario dan één postvak dat openstaat. Dat is dezelfde gedachte als achter Zero Trust: ga er niet van uit dat één kanaal veilig is.
Ook andersom: iets opvragen
Het werkt ook in de omgekeerde richting. Je kunt een aanvraag klaarzetten met een omschrijving van wat je nodig hebt, bijvoorbeeld de FTP-gegevens van een klant, en die link versturen. De ontvanger vult zijn gegevens in, versleuteld, en jij haalt het op. Dat voorkomt de klassieke situatie waarin een klant zijn wachtwoorden in een gewoon mailtje terugstuurt omdat niemand hem een alternatief heeft aangeboden.
Waar het draait, en waarom dat uitmaakt
Een dienst voor het delen van vertrouwelijke gegevens die bij een Amerikaanse hyperscaler draait, verplaatst het probleem in plaats van het op te lossen. SecretsMonkey draait daarom op eigen servers bij Hetzner in Duitsland. Database, back-ups en logbestanden blijven binnen de Europese Economische Ruimte en er is geen doorgifte daarbuiten. Geen Amerikaanse cloudopslag, geen Amerikaanse analysedienst, geen contentnetwerk dat verzoeken buiten Europa afhandelt.
Daar hoort ook bij wat er niet op de site staat: geen analysesoftware, geen advertentienetwerk, geen sociale knoppen en geen script van een andere partij. Het inhoudsbeleid van de site blokkeert dat actief, zodat het er ook niet ongemerkt in kan sluipen. IP-adressen worden ingekort tot het netwerkblok en daarna versleuteld afgedrukt, genoeg om misbruik te herkennen en te weinig om iemand te volgen. Toegangslogs blijven negentig dagen, auditlogs twaalf maanden.
Voor zakelijk gebruik is er een verwerkersovereenkomst waarin dit is vastgelegd, inclusief de volledige lijst van partijen die erbij kunnen: de serverleverancier in Duitsland en de mailverzender in Nederland. Meer zijn het er niet. Dezelfde afweging speelt breder bij de keuze voor de Europese cloud: niet uit principe, maar omdat het de vraag “waar staat onze data en wie kan erbij” beantwoordbaar maakt.
Wanneer je het juist niet moet gebruiken
Een eerlijk verhaal hoort ook de grenzen te noemen.
- Het is geen archief en geen back-up. De dienst is bedoeld voor overhandigen, niet voor bewaren. Weg is weg, ook voor ons. Voor bewaren hoort een wachtwoordkluis, en voor bedrijfsdata hoort een geregelde back-up en continuïteitsopzet.
- Het vervangt geen wachtwoordmanager. Voor vaste toegang die een team dagelijks nodig heeft, is een gedeelde kluis met rechten de juiste plek. De eenmalige link is voor het moment van overdracht.
- Het lost een fout adres niet op. Stuur je de link naar de verkeerde persoon zonder toegangswachtwoord, dan is het geheim wat het zegt te zijn: bruikbaar voor wie de link heeft. Wijzig dan het wachtwoord bij de bron.
- Het is geen vervanging voor goed toegangsbeheer. Als vijf mensen hetzelfde account delen, is veilig delen van dat wachtwoord het verkeerde probleem oplossen. Persoonlijke accounts met rechten per rol zijn de echte oplossing, precies zoals we beschrijven bij de inrichting van Microsoft 365.
Zo voer je het in zonder gedoe
- Maak het de makkelijkste route. Gedrag verandert niet door beleid maar door gemak. Zet de link naar de dienst in je intranet, je servicedesk-handtekening en je onboardingdocument.
- Spreek één regel af. Geen wachtwoorden, tokens of sleutels in mail of chat, punt. Eén regel die iedereen onthoudt werkt beter dan een pagina met uitzonderingen.
- Gebruik het richting klanten en leveranciers. Juist daar ontstaat de rommel, omdat de ander vaak geen alternatief kent. Stuur een aanvraaglink in plaats van te vragen om “de gegevens even te mailen”.
- Zet het toegangswachtwoord standaard aan bij gevoelige overdrachten. Serversleutels, betaalgegevens en beheeraccounts verdienen dat tweede slot.
- Ruim op wat er al staat. Zoek in je mailomgeving op termen als wachtwoord, password en inloggegevens, en verwijder de oude berichten. Wissel de wachtwoorden die daar in stonden.
Veelgestelde vragen
Is een wachtwoord in een e-mail echt zo’n probleem?
Ja, vooral door de houdbaarheid. Het bericht blijft staan in het postvak van de afzender en de ontvanger, in de back-up van beide mailomgevingen, vaak in een doorgestuurde kopie en op elke telefoon waarop dat account staat. Wie over een jaar toegang krijgt tot een van die postvakken, krijgt dat wachtwoord er gratis bij. Het probleem is niet dat mail onderweg onveilig is, het probleem is dat mail bewaart.
Wat is een eenmalige deellink precies?
Je plakt het wachtwoord of token in een webformulier en krijgt een link terug. De inhoud staat versleuteld op de server, de sleutel zit alleen in de link. Zodra de ontvanger de link opent, wordt de inhoud getoond en daarna vernietigd. Klikt niemand, dan verdwijnt hij alsnog na de ingestelde vervaltijd. Het wachtwoord zelf staat nergens in een chat of mailbericht.
Wat als de link bij de verkeerde persoon terechtkomt?
Wie de link heeft, kan het geheim openen. Dat is het ontwerp. Daarom is er een optioneel toegangswachtwoord dat de ontvanger eerst moet invullen, en dat je via een ander kanaal doorgeeft dan de link zelf. Verstuur de link bijvoorbeeld per mail en het toegangswachtwoord per telefoon. Verkeerd verstuurd zonder toegangswachtwoord betekent: nieuw wachtwoord instellen bij de bron.
Vervangt dit een wachtwoordmanager?
Nee, het vult hem aan. Een wachtwoordmanager is voor bewaren, een eenmalige deellink is voor overhandigen. Voor vaste toegang binnen een team blijft een gedeelde kluis de juiste plek. Voor het eenmalig overdragen van een sleutel aan een leverancier, een nieuwe medewerker of een klant is een zelfvernietigende link beter, omdat er daarna niets blijft staan.
Waar staan die gegevens dan, en is dat AVG-proof?
Alles draait op eigen servers bij Hetzner in Duitsland, met database, back-ups en logbestanden binnen de Europese Economische Ruimte en zonder doorgifte daarbuiten. Er staat geen analysesoftware of advertentiescript op de site en IP-adressen worden ingekort voordat ze worden opgeslagen. Voor zakelijk gebruik is er een verwerkersovereenkomst beschikbaar.
Klein probleem, kleine oplossing, echt verschil
Van alle beveiligingsmaatregelen die een MKB-bedrijf kan nemen, is deze een van de goedkoopste. Er is geen project voor nodig, geen migratie en geen licentietraject. Het vraagt één afspraak en één bladwijzer, en het haalt een categorie gevoelige gegevens permanent uit je mailarchief.
Dat maakt het geen wondermiddel. De grotere maatregelen, zoals persoonlijke accounts, meervoudige verificatie, voorwaardelijke toegang en tijdig patchen, doen nog steeds het meeste werk. Maar het is wel een van de weinige verbeteringen die je vanmiddag kunt doorvoeren en die morgen al effect heeft.
SecretsMonkey is gratis te gebruiken, ook zonder account, en beschikbaar in zeven talen. Probeer het op secrets.monkeysoft.nl. Wil je het binnen je organisatie invoeren, inclusief verwerkersovereenkomst en afspraken over toegangsbeheer? Neem contact op met MonkeySoft.
Bronnen: SecretsMonkey privacyverklaring | Autoriteit Persoonsgegevens | Nationaal Cyber Security Centrum