Hotmodeller
Varför Collogue-länkar inte är engångslänkar
Varför en lösenordsskyddad krypterad länk skiljer sig från en engångshemlighet eller en hemlighet med utgångstid.
Publicerad: 5 maj 2026
Gränser för den aktuella implementationen
Den aktuella klienten krypterar texten i webbläsaren och bär det krypterade innehållet i URL:en. Webbläsaren använder Web Crypto API: PBKDF2-SHA-256 med 310 000 iterationer härleder en 256-bitars AES-GCM-nyckel från det separat angivna lösenordet, med ett slumpmässigt salt på 16 byte och ett IV på 12 byte. Den aktuella klienten skickar ingen API-begäran till applikationen för att skapa, hämta eller lagra meddelanden.
Lösenordet är inte kodat i länken. Implementation ger inte engångsvisning, radering på serversidan eller någon utgångstimer. Behandla hela länken som känslig och skicka lösenordet genom en separat kanal.
Mer sammanhang
En länk som fungerar en gång kan minska exponeringen, men personen som öppnar den först vinner ändå.
Den meningen fångar både fördelen och begränsningen.
Föreställ dig att du skickar ett tillfälligt lösenord via e-post.
De flesta av dessa kopior orsakar aldrig en incident. Problemet är att de finns kvar långt efter att deras syfte upphörde.
Det är en verklig minskning av varaktig exponering.
- hur sannolik åtkomst är;
- hur länge åtkomst förblir möjlig.
En hemlighet som är tillgänglig i tio minuter är inte automatiskt säker. Den är vanligtvis exponerad kortare tid än samma hemlighet som ligger i en inkorg i tre år.
Detta är riskminskning, inte osårbarhet.
Ändå är felet användbart. Bob och Alice vet nu att de inte ska lita blint på inloggningsuppgiften.
För en åtkomsttoken eller ett lösenord är den säkra reaktionen vanligtvis att återkalla eller rotera det och skapa ett nytt.
Vanlig e-post i klartext ger sällan denna varning. Den fortsätter att visa hemligheten oavsett hur många som har läst den.
Om länken fungerar som en bärar-befogenhet kan Collogue veta att rätt URL presenterades. Tjänsten vet kanske inte att personen är Bob.
- verifiera destinationsadressen;
- bekräfta mottagaren genom en etablerad kanal;
- ta inte med onödigt sammanhang tillsammans med länken;
- använd en tillfällig inloggningsuppgift med begränsad omfattning;
- kräv lösenordsbyte eller tokenrotation;
- aktivera MFA på målkontot.
Gör inte den privata länken till det enda identitetsbeviset för en åtgärd med mycket hög behörighet.
Människor skickar ibland halva lösenordet via e-post och halva via SMS.
Det kan tvinga en angripare att kompromettera två kanaler, men skapar också komplexitet, avskriftsfel och två kvarvarande delar. Värdet beror på om kanalerna verkligen är oberoende och hur delarna skapas.
Ett annat sätt är att skicka Collogue-länken genom en kanal och bekräfta mottagaren eller ge icke-hemligt sammanhang genom en annan.
Ingen av metoderna skapar automatiskt multifaktorautentisering. De är leveransval, inte universella bevis.
- ett tillfälligt lösenord;
- en kortlivad API-token;
- en återställningskod;
- en Wi-Fi-inloggning;
- en engångsinloggning för en kund;
- ett privat konfigurationsvärde;
- en kort känslig anteckning.
- långvarig delning av teaminloggningar;
- återkommande åtkomst;
- starkt reglerade poster som kräver granskningsflöden;
- stora filer;
- hemligheter som inte kan roteras;
- fall som kräver stark verifiering av mottagarens identitet.
En lösenordshanterare, secrets manager, ett system för privilegierad åtkomst eller ett godkänt verktyg för företagsöverföring kan vara bättre i dessa fall.
Det kan minska varaktiga läsbara kopior och aktiv livslängd. Säkerheten beror fortfarande på länkleverans, kryptering, mottagarverifiering, slutpunktssäkerhet och hemlighetens egen livscykel.
Nej. Det bevisar bara det applikationstillstånd som registreras. Den första läsaren kan ha kopierat innehållet, och tjänsten kanske inte vet vem läsaren var.
Föredra tillfälliga, begränsade och återkalleliga inloggningsuppgifter. En säkrare leveranskanal reparerar inte en överdrivet privilegierad eller permanent hemlighet.
Collogue kan minska varaktig exponering i e-post och chatt, men kan inte skydda en komprometterad enhet eller kontrollera vad en mottagare gör efter läsningen.