Dreigingsmodellen
Waarom Collogue-links geen eenmalige links zijn
Waarom een versleutelde link met wachtwoord verschilt van een eenmalig of vervallend geheim.
Gepubliceerd: 5 mei 2026
Grenzen van de huidige implementatie
De huidige client versleutelt tekst in de browser en draagt de versleutelde inhoud in de URL. Het apart gedeelde wachtwoord staat niet in de link. Er is geen applicatieserver die berichten opslaat, ophaalt, verwijdert of als eenmalig bericht verwerkt.
Verdere context
Een link die maar één keer werkt kan blootstelling verminderen, maar de persoon die hem als eerste opent wint nog steeds.
Die zin vat zowel het voordeel als de beperking samen.
Stel u voor dat u een tijdelijk wachtwoord per e-mail verstuurt.
De meeste van die kopieën veroorzaken nooit een incident. Het probleem is dat ze nog lang bestaan nadat hun doel is verdwenen.
Dat is een echte vermindering van blijvende blootstelling.
- hoe waarschijnlijk toegang is;
- hoelang toegang mogelijk blijft.
Een geheim dat tien minuten beschikbaar is, is niet automatisch veilig. Het is meestal korter blootgesteld dan hetzelfde geheim dat drie jaar in een inbox blijft staan.
Dit is risicobeperking, geen onkwetsbaarheid.
Toch is de fout nuttig. Bob en Alice weten nu dat ze de toegangsgegevens niet blind moeten vertrouwen.
Bij een toegangstoken of wachtwoord is de veilige reactie meestal om het in te trekken of te roteren en een nieuw token of wachtwoord te maken.
Gewone e-mail met platte tekst geeft deze waarschuwing zelden. Die blijft het geheim tonen, ongeacht hoeveel mensen het hebben gelezen.
Als de link als bearer-machtiging werkt, weet Collogue mogelijk dat de juiste URL is aangeboden. Het weet mogelijk niet dat de mens Bob is.
- controleer het bestemmingsadres;
- bevestig de ontvanger via een gevestigd kanaal;
- voeg geen onnodige context aan de link toe;
- gebruik een tijdelijke, beperkte toegangswaarde;
- eis een wachtwoordwijziging of tokenrotatie;
- schakel MFA in op het doelaccount.
Maak van de privélink zelf niet het enige identiteitsbewijs voor een actie met hoge bevoegdheden.
Mensen sturen soms de ene helft van een wachtwoord per e-mail en de andere helft per sms.
Dit kan een aanvaller dwingen twee kanalen te compromitteren, maar creëert ook complexiteit, overschrijffouten en twee blijvende fragmenten. De waarde hangt ervan af of de kanalen werkelijk onafhankelijk zijn en hoe de helften worden gemaakt.
Een andere mogelijkheid is de Collogue-link via één kanaal te versturen en de ontvanger of niet-geheime context via een ander kanaal te bevestigen.
Geen van beide methoden creëert automatisch multi-factor-authenticatie. Het zijn keuzes voor bezorging, geen universele bewijzen.
- een tijdelijk wachtwoord;
- een kortlevend API-token;
- een herstelcode;
- een wifiwachtwoord;
- een eenmalige klantlogin;
- een private configuratiewaarde;
- een korte gevoelige notitie.
- langdurig delen van teamtoegangsgegevens;
- terugkerende toegang;
- sterk gereguleerde gegevens waarvoor auditprocessen nodig zijn;
- grote bestanden;
- geheimen die niet kunnen worden geroteerd;
- situaties waarin sterke verificatie van de ontvangeridentiteit nodig is.
Een wachtwoordmanager, secretsmanager, systeem voor geprivilegieerde toegang of goedgekeurde bedrijfstool voor overdracht kan in die gevallen beter zijn.
Het kan blijvende leesbare kopieën en de actieve levensduur verminderen. De veiligheid hangt nog steeds af van linkbezorging, versleuteling, verificatie van de ontvanger, endpointbeveiliging en de eigen levenscyclus van het geheim.
Nee. Het bewijst alleen de applicatiestatus die het vastlegt. De eerste kijker kan de inhoud hebben gekopieerd en de dienst weet mogelijk niet wie die kijker was.
Geef de voorkeur aan tijdelijke, beperkte en intrekbare toegangsgegevens. Een veiliger bezorgingskanaal herstelt geen permanent geheim met te ruime rechten.
Collogue kan blijvende blootstelling in e-mail en chat verminderen, maar kan een gecompromitteerd apparaat niet beveiligen en niet controleren wat een ontvanger na het lezen doet.