Versleutelingssleutels
Waar is de ontsleutelingssleutel?
Waarom Collogue een afzonderlijk ingevoerd wachtwoord gebruikt in plaats van de sleutel in de URL te zetten.
Gepubliceerd: 28 februari 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
Versleuteling vervangt één moeilijk probleem door een ander.
Sleutels zijn klein. Hun gevolgen niet.
Met een symmetrische versleutelingssleutel kan de browser van de ontvanger geauthenticeerde ciphertext weer omzetten naar platte tekst.
``text https://collogue.net/m/example-message#example-key-material ``
Gebruik dit voorbeeld alleen als het overeenkomt met de werkelijke architectuur.
Het fragment is het deel van een URL na #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
De browser bewaart #key-material lokaal en maakt het beschikbaar aan de geladen pagina.
Maar drie waarschuwingen zijn belangrijk.
Ten eerste kan JavaScript dat door de pagina wordt geladen het fragment lezen. Ontsleuteling in de browser vereist dit of een gelijkwaardig mechanisme.
Ten tweede is de volledige link nu een machtiging. Iedereen die hem verkrijgt, kan zowel de verwijzing naar de ciphertext als de sleutel krijgen.
Ten derde kunnen fragmenten nog steeds uitlekken door menselijk gedrag, screenshots, gekopieerde tekst, browserextensies, klembordgeschiedenis, synchronisatietools of gewijzigde clientcode.
Een fragment is een nuttige protocolgrens. Het is geen krachtveld.
- toegangslogs;
- logs van reverse proxies;
- browsergeschiedenis;
- gekopieerde diagnostische gegevens;
- referrergegevens, afhankelijk van beleid en navigatie;
- monitoringsystemen.
In dat geval moet het openbare artikel de werkelijke blootstelling uitleggen in plaats van fragmentgedrag te beschrijven.
Een gedenkwaardige wachtwoordzin en een uniform willekeurige sleutel zijn niet uitwisselbaar. Afleidingsparameters zijn belangrijk.
Gebruikers nemen soms aan dat een versleutelde link veilig openbaar kan worden geplaatst omdat die “alleen versleutelde gegevens bevat”.
Die conclusie is onjuist wanneer de link ook de machtiging om te ontsleutelen levert.
- openbare issuetrackers;
- gedeelde kanalen met onnodige leden;
- URL-analysebedrijven;
- openbare URL-verkorters;
- documenten met brede toegang.
Bezit van de link kan aantonen dat iemand de link bezit. Het stelt niet noodzakelijk de identiteit vast.
Als een aanvaller de URL vóór de beoogde ontvanger verkrijgt, kan de cryptografie voor die aanvaller perfect werken.
Dat is de terugkerende les van bearer-machtigingen: autorisatie wordt door bezit vertegenwoordigd.
Controleer bij geheimen met een hoger risico de ontvanger en overweeg een apart kanaal voor context of extra authenticatie. Beschrijf aparte kanalen niet automatisch als veilig; ze veranderen alleen de voorwaarden voor een aanval.
- de afzender deelt de verkeerde link;
- de ontvanger stuurt de link door;
- malware in de browser leest het fragment;
- een kwaadaardig paginascript legt platte tekst vast;
- de klembordgeschiedenis bewaart de URL;
- een linkscanner vraagt de pagina op;
- de ontvanger bewaart het ontsleutelde bericht.
Het kan een nuttig ontwerp zijn omdat het fragment normaal gesproken niet in HTTP-verzoeken wordt meegestuurd. De veiligheid hangt nog steeds af van de geleverde pagina, de browseromgeving, de verwerking van de link en het gedrag van de ontvanger.
Ja. JavaScript dat op de pagina draait, kan het fragment benaderen. Zo verkrijgt client-side ontsleuteling vaak het sleutelmaterial.
Als Collogue de sleutel niet bewaart of afleidt, kan verlies van het vereiste linkmateriaal het bericht onherstelbaar maken. Bevestig de implementatie voordat u dit publiceert.