Incidentrespons
Wat als iemand de link als eerste opent?
Wat u moet doen wanneer een gevoelige link of een wachtwoord bij de verkeerde persoon terecht kan zijn gekomen.
Gepubliceerd: 15 april 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
Direct antwoord: Collogue kan niet laten zien wie een link heeft geopend. Als de link en het afzonderlijk gedeelde wachtwoord bij de verkeerde persoon terecht kunnen zijn gekomen, behandel de toegangsgegevens dan als mogelijk blootgesteld: trek ze in of roteer ze, controleer de ontvanger via een ander kanaal en maak een nieuw bericht in plaats van dezelfde waarde opnieuw te versturen.
Collogue heeft geen servergebeurtenis voor het lezen en kan daarom niet bewijzen dat iemand een bericht heeft geopend of een kijker identificeren. Een kapotte link of mislukte ontsleuteling kan ook het gevolg zijn van een onvolledige of gewijzigde URL of van het verkeerde wachtwoord.
Als het bericht een wachtwoord, API-sleutel, sessietoken, herstelcode of toegangslink bevatte, behandel de waarde dan als blootgesteld.
- Trek de waarde in of roteer haar.
- Verstuur dezelfde waarde niet opnieuw.
- Bevestig de beoogde ontvanger.
- Maak waar mogelijk een nieuwe tijdelijke waarde.
- Verstuur een nieuwe Collogue-link.
- Onderzoek het bezorgingspad als het probleem zich herhaalt.
Een permanente toegangswaarde veroorzaakt een groter incident dan een tijdelijke. Daarom horen bezorging en het ontwerp van toegangsgegevens bij elkaar.
Niet elk privébericht bevat toegangsgegevens.
Als de inhoud een onkritische notitie was, kan de afzender na bevestiging van de ontvanger een nieuw bericht maken. Het risico hangt af van de gevoeligheid van de tekst en de gevolgen van openbaarmaking.
De dienst kan die beslissing niet voor de gebruiker nemen. Wel kan hij de toestand duidelijk uitleggen.
Alleen als de dienst relevante bewijzen bewust verzamelt en betrouwbaar kan interpreteren – en zelfs dan kan toeschrijving onzeker blijven.
- de beoogde ontvanger;
- een bedrijfsproxy;
- een mobiele provider;
- een VPN;
- een e-mailscanner;
- een gedeeld netwerk;
- een aanvaller.
Een user-agent beschrijft mogelijk software, niet een persoon.
Wek niet de indruk dat een audittrail een mens identificeert als het systeem geen geauthenticeerde ontvangeridentiteit bevat en de claim niet wordt ondersteund.
Test bij terugkerende bezorgingsproblemen binnen één organisatie niet-gevoelige links via hetzelfde e-mailpad en bespreek het beleid van de beveiligingsgateway met de beheerder. Gebruik geen echte toegangsgegevens als testbericht.
- beoordeel de gevolgen van openbaarmaking;
- bevestig of de ontvanger de link heeft geopend;
- herhaal niet meer context dan nodig is;
- gebruik voor gereguleerde informatie het goedgekeurde incidentproces.
Nee. De huidige client verzamelt geen leesgebeurtenissen en een URL-verzoek identificeert geen persoon.
Als een wachtwoordlink niet kan worden ontsleuteld, controleer dan de URL en het wachtwoord. Vervang de toegangsgegevens zodra beide delen mogelijk zijn blootgesteld.
Collogue kan een scanner niet betrouwbaar onderscheiden van een persoon. Publiceer alleen de diagnostische mogelijkheden die de code daadwerkelijk biedt.