Sikker deling af adgangskoder i teams: 5 metoder sammenlignet

Kontrolleret den 2. oktober 2026. Slacks standard for opbevaring og tallene for SIM-swapping er dokumenteret i kilderne sidst i denne guide. LinkPilots adfærd svarer til siden om sikkerhedsarkitekturen.

Fælles bokse i en adgangskodeadministrator

Til loginoplysninger, der lever i månedsvis, er en fælles boks i en adgangskodeadministrator som 1Password, Bitwarden, Keeper, Psono og andre det rigtige standardvalg. Adgangskoden ligger ét sted, og når den skiftes, er den opdateret for alle. Adgang gives pr. samling. Når nogen stopper, fjerner man blot vedkommendes licens, og teamplaner har hændelseslogs. Ulempen er, at alle, der skal bruge adgangskoden, skal være med i boksen. En kunde, en freelancer eller en nyansat, der endnu ikke har fået adgang, kan derfor ikke få et element fra boksen.

Et krypteret engangslink

Til selve overdragelsen er et hemmeligt engangslink det rette værktøj. Du indsætter adgangskoden, får en URL og sender den gennem den kanal, du allerede bruger. Modtageren åbner den én gang: Indholdet vises og destrueres derefter, og den URL, der ligger tilbage i tråden, peger på ingenting. Tilføj et kort udløb, så et uåbnet link dør af sig selv, og en adgangssætning, som du sender ad en anden kanal, så et opsnappet link alene er ubrugeligt. Du kan oprette et nu uden konto. LinkPilot vs. Password Pusher og sådan deler du API-nøgler sikkert gennemgår samme mekanik for tokens.

Chatapps (Slack, Teams, Signal)

Chat føles flygtigt, men er det modsatte. Ifølge Slacks egen dokumentation bliver data på betalte planer ”som standard opbevaret, så længe dit arbejdsområde findes”, og ejerne af arbejdsområdet kan eksportere dem. Teams og Google Chat er underlagt regler for opbevaring og eDiscovery, som netop er lavet, så beskeder ikke kan bringes til at forsvinde. Signal er bedre, med forsvindende beskeder og ingen historik på serveren, men der ligger stadig en kopi på to telefoner, med skærmbilleder og sikkerhedskopier, du ikke har kontrol over. Alle chatklienter henter desuden en forhåndsvisning af links, så snart de bliver sendt, og derfor skal et engangslink være bygget, så en forhåndsvisning ikke kan slette det.

E-mail

En adgangskode sendt via e-mail ligger i klartekst på afsenderens mailserver, på modtagerens, i sikkerhedskopierne af begge og på hver enhed, der har synkroniseret postkassen. Den overlever videresendelse, arkivering og kompromitterede konti, og et brud på postkassen mange år senere afslører alle loginoplysninger, der nogensinde er sendt gennem den. E-mail er fint til at sende et link til en hemmelighed, men aldrig til selve hemmeligheden.

Mundtligt, telefon og sms

Læser du en adgangskode højt i samme rum, opstår der ingen kopi overhovedet. Det er den eneste metode på denne side, der ikke efterlader spor, og den eneste, der ikke kan skaleres. Sms er den farlige fætter: Beskeden bliver liggende på begge telefoner og i teleselskabets registre, og telefonnumre bliver stjålet. FBI's Internet Crime Complaint Center registrerede 1.611 klager over SIM-swapping med tab på over 68 millioner dollar alene i 2021, mod 320 klager i hele perioden 2018–2020. Sms er acceptabel til en kort adgangssætning, der er ubrugelig uden det link, der sendes separat, men ikke til selve adgangskoden.

Krypteringen sker i din browser

Siden den 29. september 2026 krypteres indholdet på klientsiden med AES-GCM-256 og en nøgle på 256 bit, der genereres i din browser, før noget sendes. Det, der når frem til os, er chiffertekst i tabellen secret_links, som er adskilt fra tabellerne med klikstatistik. Vedhæftede filer krypteres på samme måde med en nøgle, der er afledt af hemmelighedens egen nøgle, så ét link åbner begge dele. Tekniske detaljer: kryptering på klientsiden ved deling af hemmeligheder.

Nøglen står efter # i linket

Delingslinket ser sådan ud: shrd.link/s/<slug>#k=<key>. Alt efter # er dekrypteringsnøglen, og browsere sender aldrig den del af linket til nogen server, hverken til os eller til det CDN, der leverer siden, hvor hemmeligheden vises. Vi modtager aldrig nøglen, så vi kan ikke læse hemmeligheden, gendanne den, hvis linket går tabt, eller genskabe URL'en senere. Sagt ligeud: Alle, der har hele linket, har nøglen.

Adgangssætninger tilføjer en ekstra faktor

På Pro bliver en adgangssætning strakt med PBKDF2-SHA256 (210.000 iterationer) og kombineret med linkets nøgle via HKDF-SHA256, så hverken linket eller adgangssætningen alene kan dekryptere hemmeligheden. Separat sendes en SHA-256-hash af adgangssætningen, så serveren kan nægte at udlevere chifferteksten til en, der ikke kender den. Selve adgangssætningen bliver aldrig skrevet i vores database eller logs. Forsøg er begrænset til 5 pr. IP-adresse pr. minut pr. hemmelighed, og hvert mislykket forsøg havner i revisionsloggen. Til sammenligning kræver NIST SP 800-63B, at gemte huskede hemmeligheder saltes og hashes med en nøgleafledningsfunktion som PBKDF2 med mindst 10.000 iterationer.

”Slet efter læsning” sker atomart

Et link med ”Slet efter læsning” giver modtageren én chance for at se indholdet. Visningen registreres gennem en enkelt databasefunktion med låsning på rækkeniveau, så to personer, der åbner linket i samme øjeblik, ikke begge kan læse det. Når grænsen for visninger er nået, skifter status til slettet, og det gemte indhold overskrives med [REDACTED]. Senere besøg får HTTP 410 og en tydelig side om, at hemmeligheden ”allerede er vist”. Udløbne og tilbagekaldte hemmeligheder overskrives på samme måde, og der er med vilje ingen gendannelse.

Forhåndsvisninger af links kan ikke slette hemmeligheden

En GET mod endpointet til visning returnerer kun metadata: status, og om der kræves en adgangssætning. En visning registreres kun ved den eksplicitte POST, som et menneske udløser ved at klikke på Vis, og alle svar med indhold har Cache-Control: no-store. Chatklienter og sikkerhedsgateways til e-mail henter links som almindelige GET-forespørgsler, så deres forhåndsvisninger ser intet og sletter intet. En test, du selv kan køre: linkscannere og engangshemmeligheder.

Det kan vi stadig se: tre ærlige begrænsninger

1. Hemmeligheder, der er oprettet før den 29. september 2026, blev gemt i klartekst, indtil de udløb. De blev aldrig omskrevet i det skjulte. De virkede som før og forsvandt, når de udløb. En medarbejder med driftsadgang kunne have læst en af dem, mens den var aktiv. Vedhæftede filer, der blev uploadet før den dato, forblev gemt som almindelige filer.
2. Alle, der har hele linket, har nøglen. Kryptering på klientsiden fjerner os, vores database og vores edge-netværk fra tillidsgrænsen. Den beskytter ikke et link, der er blevet videresendt, fanget på et skærmbillede eller logget hos modtageren.
3. En fils navn, størrelse og type kan vi stadig se. Det er metadatakolonner, indholdet er ikke. For hvert forsøg på at vise hemmeligheden gemmer vi også et tidsstempel, en hashet IP-adresse (SHA-256 med et salt, der skiftes dagligt, afkortet), en grov geografisk placering og user agent. Vi gemmer aldrig hemmeligheden, selve adgangssætningen eller den rå IP-adresse, og der sættes ingen cookies hos modtageren.

1. Adgangskoder, API-nøgler, tokens og forbindelsesstrenge skrives aldrig i e-mail, chat eller sms. Ikke én gang, heller ikke ”bare denne ene gang”.
2. Fælles loginoplysninger, der bruges længe, ligger i teamets boks. Del elementet i boksen, ikke værdien.
3. Enkeltstående overdragelser sker med et hemmeligt engangslink med det korteste udløb, der fungerer, og med ”Slet efter læsning” slået til.
4. Linket og adgangssætningen sendes ad hver sin kanal (linket via e-mail, adgangssætningen via telefon eller en direkte chatbesked), og adgangssætningen genbruges aldrig.
5. Ved onboarding får en nyansat sine første loginoplysninger som engangslinks, og de skiftes ved første login. Ved rolleskift eller offboarding justeres adgangen til boksen samme dag, og alle loginoplysninger, personen havde uden for boksen, skiftes.
6. Alt, der nogensinde er indsat i chat eller e-mail, skiftes, næste gang nogen rører ved det, og chatbeskeden slettes. En uventet visning i en hemmeligheds tidslinje udløser et øjeblikkeligt skift.