Säkerheten med lösenordsskyddade länkar — vad händer när du klickar
Du kan lägga till ett lösenord till din korta länk. Vi visar vad som händer under huven — utan att använda fackspråk — och varför det överhuvudtaget är värt det.
Hälften av guiderna om lösenordsskyddade länkar börjar med meningen att det är ett "extra säkerhetslager". Och det är där det slutar. Enligt min åsikt är det just det minst viktiga man kan säga om det.
Eftersom "säkerhetslagret" inte förklarar någonting. Det berättar inte för dig vad som händer med det här lösenordet, vem som ser det, eller när det överhuvudtaget är meningsfullt. Och det är de enda frågorna som är värda att ställa sig innan man klickar på "Lägg till lösenord".
Så här är det, steg för steg.
Lösenordet på länken är inte samma sak som hänglåset på grinden
Människor föreställer sig att ett lösenord låser en länk helt och hållet. Så är det inte. Säkerheten med lösenordsskyddade länkar fungerar snarare som en konsertbiljett: den som har en biljett kommer in. Den som ger bort den till någon annan släpper också in någon.
Det låter som en defekt. Det är det inte. Man måste bara veta vad den här mekanismen är till för.
Tre situationer där det verkligen är till nytta:
Prislista för premiumkunder eller ett dokument i betaversion, innan det går ut i världen. Utan lösenord kommer en sådan länk förr eller senare att hamna på Google eller gå från hand till hand.
Innehåll med utgångsdatum. Erbjudande gäller endast på fredag. Material från konferensen uteslutande för deltagare. Lösenordet skapar en kontrollerad åtkomst via länken — du vet att någon fick den av dig, och inte hittade den av en slump.
Och en sak som du lägger ut helt offentligt, men som du vill hålla koll på. Länken kan cirkulera. Utan lösenord kommer ingen ändå in.
Och nu det som denna guide inte skulle utelämna
Du skriver in lösenordet i formuläret. I samma ögonblick försvinner det. Bokstavligt talat. Det faktum att du ställde in "tajne123" upphör att existera i läsbar form innan du ens hunnit släppa knappen.
Vad finns kvar i databasen? Inte lösenordet. Ett fingeravtryck efter det. Professionellt: hash. En sträng av tecken som matchar ditt lösenord endast om någon skriver exakt samma sak som du. I sig själv avslöjar den ingenting.
Jag säger det rakt ut, för det är viktigt: jag, som tjänstens administratör, har inget sätt att läsa ditt lösenord. Inte för att jag är snäll. Utan för att det fysiskt inte finns något att läsa. Om någon skulle bryta sig in i databasen, skulle de bara ta med sig en hög av dessa fingeravtryck och det var allt.
Algoritmen som beräknar detta är avsiktligt långsam. Jag vet att "långsam" låter som en klagan, men det är en fördel. Syftet är att någon som har stulit databasen måste lägga absurt mycket tid på att gissa ett enda lösenord. Vi pratar om år, inte sekunder.
Klick från andra sidan
Någon får din länk och klickar. Istället för att komma direkt till målet ser de skärmen: "denna länk är lösenordsskyddad", ett fält för inmatning, en knapp.
Skriver in. Servern jämför det som skrivits in med det sparade avtrycket. Stämmer det? Får en sessionstoken giltig i ett dygn. Under nästa 24 timmar återvänder man till länken utan att behöva skriva in någonting. Behöver inte komma ihåg, behöver inte anstränga sig.
Inte rätt? Fel. Fem felaktiga försök från samma IP-adress och åtkomsten blockeras i fem minuter. En bot som försöker gissa lösenord i rad är slående mot en vägg.
Vad som helt enkelt inte finns här
Vi sparar inte lösenord i klartext. Ingenstans. Inte ens i loggarna som jag tittar i när jag letar efter fel.
Vi skickar inte lösenord via e-post. Det betyder att om någon glömmer sitt lösenord, så kan jag inte skicka det till dem, eftersom jag inte känner till det. Du måste skicka det själv, via samma kanal som tidigare.
Och vi lämnar inte ut lösenord till externa parter. Ingen analys, ingen marknadsföring, inget AB rör dessa data. (Detta är faktiskt en regel som gäller för hela cutty.dev, inte bara här.)
Två vanor som gör skillnad
Första: hitta inte på ett lösenord i huvudet. Företagsnamn plus grundningsår är en gåva till alla som känner dig. En generator i webbläsaren spottar ur sig något bättre på en sekund.
Det andra, viktigare: skicka inte lösenordet via samma kanal som länken. Gick länken via e-post? Skicka lösenordet via SMS. Eller tvärtom. Poängen är att om en inkorg blir komprometterad, så får ingen tillgång till hela setet.
En liten detalj som få känner till: du kan skapa flera länkar som leder till samma adress, men med olika lösenord. Du ger tillgång till fem personer, en separat länk för varje person. Är det någon som ska sägas upp? Du blockerar dennes länk, resten kommer inte ens att märka det.
Du kan ändra lösenordet utan att skapa en ny länk. Panel, "Redigera", nytt lösenord. Obs: alla aktiva 24-timmarssessioner avbryts omedelbart. Alla måste skriva in lösenordet på nytt.
En gräns som det är värt att känna till i förväg
Låt oss återgå till konsertbiljetten. Lösenordet skyddar mot sökmotorer och mot oväntade gäster. Det skyddar inte mot någon som känner till lösenordet och bestämmer sig för att dela det med världen.
Om ditt scenario låter "det här ska bara ses av exakt den här personen och ingen annan", så räcker inte ett lösenord. Här behöver du konton, inloggning, auktorisering. En annan liga, ett annat problem.
Men handen i luften, hur ofta har du verkligen ett sådant scenario? I min erfarenhet sällan. I de allra flesta fall handlar det om ett enkelt "jag vill inte att någon från gatan ska komma hit". Och för det mottot räcker det med marginal.
Om du vill se hur det ser ut inifrån — när du skapar en länk, expandera "Avancerade alternativ" och markera "Lägg till lösenord". Resten sker automatiskt.