Veiligheid van links met wachtwoord — wat er gebeurt als je klikt
Je kunt een wachtwoord toevoegen aan je korte link. We laten zien wat er onder de motorkap gebeurt — zonder jargon — en waarom het überhaupt de moeite waard is.
De helft van de handleidingen over links met een wachtwoord begint met de zin dat het een "extra beveiligingslaag" is. En dat is het. Naar mijn mening is dat juist het minst belangrijke wat je erover kunt zeggen.
Want een "beveiligingslaag" legt niets uit. Het vertelt je niet wat er met dat wachtwoord gebeurt, wie het ziet, of wanneer het überhaupt zin heeft. En dat zijn de enige vragen die het waard zijn om jezelf te stellen voordat je op "Wachtwoord toevoegen" klikt.
Dus één voor één.
Het wachtwoord op de link is niet hetzelfde als het hangslot aan de poort
Mensen stellen zich voor dat een wachtwoord een link volledig afsluit. Dat is niet zo. De veiligheid van links met een wachtwoord werkt eerder als een concertticket: wie een ticket heeft, mag naar binnen. Wie het aan iemand anders geeft, laat ook iemand binnen.
Dat klinkt als een fout. Dat is het niet. Je moet gewoon weten waar dit mechanisme voor dient.
Drie situaties waarin het echt nuttig is:
Prijslijst voor premium klanten of een document in bètaversie, voordat het de wereld in gaat. Zonder wachtwoord zal een dergelijke link vroeg of laat in Google belanden of van hand tot hand gaan.
Inhoud met vervaldatum. Aanbod alleen op vrijdag. Materiaal van de conferentie uitsluitend voor deelnemers. Het wachtwoord maakt van de link een gecontroleerde toegang — je weet dat iemand het van jou heeft gekregen, en niet per ongeluk heeft gevonden.
En iets wat je volledig publiekelijk plaatst, maar waar je toch de vinger aan de pols wilt houden. De link kan rondgaan. Zonder wachtwoord kan er toch niemand naar binnen.
En nu datgene wat deze gids niet mocht missen
Je typt een wachtwoord in het formulier. Op datzelfde moment verdwijnt het. Letterlijk. Dat je "tajne123" hebt ingesteld, houdt op te bestaan in leesbare vorm voordat je de toets loslaat.
Wat blijft er in de database staan? Niet het wachtwoord. De vingerafdruk die daarna komt. Vakjargon: hash. Een reeks tekens die alleen overeenkomt met je wachtwoord wanneer iemand precies hetzelfde typt als jij. Op zichzelf onthult het niets.
Ik zeg het maar gewoon recht voor zijn raap, want het is belangrijk: ik, de beheerder van de service, kan jouw wachtwoord niet lezen. Niet omdat ik beleefd ben. Maar omdat er fysiek niets te lezen valt. Als iemand zou inbreken in de database, zouden ze slechts een stapel van deze vingerafdrukken meenemen en dat is alles.
Het algoritme dat dit berekent, is opzettelijk traag. Ik weet dat "traag" klinkt als een klacht, maar het is een voordeel. Het doel is dat iemand die de database heeft gestolen, absurd veel tijd moet besteden aan het raden van één enkel wachtwoord. We hebben het over jaren, niet over seconden.
Klik aan de andere kant
Iemand krijgt je link en klikt erop. In plaats van direct bij het doel aan te komen, ziet hij een scherm: "deze link is beveiligd met een wachtwoord", een invoerveld, een knop.
Hij typt het in. De server vergelijkt wat is ingevoerd met de opgeslagen vingerafdruk. Komt het overeen? Hij ontvangt een sessietoken dat 24 uur geldig is. Gedurende de volgende 24 uur kan hij via de link terugkeren zonder iets te hoeven typen. Hij hoeft het niet te onthouden, hij hoeft zich niet te moeite te doen.
Niet eens? Fout. Vijf fouten vanaf hetzelfde IP-adres en de toegang wordt voor vijf minuten geblokkeerd. Een bot die probeert achter elkaar wachtwoorden te proberen, loopt tegen een muur op.
Wat hier gewoon niet is
Wij slaan geen wachtwoorden op als platte tekst. Nergens. Zelfs niet in de logs die ik bekijk bij het zoeken naar fouten.
Wij sturen geen wachtwoorden via e-mail. Dat betekent dat als iemand zijn wachtwoord vergeet, ik het niet naar hem kan sturen, omdat ik het niet weet. Je moet het zelf verzenden, via hetzelfde kanaal als voorheen.
En we geven geen wachtwoorden door aan de buitenwereld. Geen enkele analyse, geen marketing, geen AB raakt deze gegevens. (Dit is precies het principe dat geldt voor de gehele cutty.dev, niet alleen hier.)
Twee gewoontes die het verschil maken
Eerste: bedenk niet zelf een wachtwoord. De bedrijfsnaam plus het jaar van oprichting is een cadeau voor iedereen die je kent. Een generator in de browser spuugt binnen een seconde iets beters uit.
De tweede, belangrijkere: stuur het wachtwoord niet via hetzelfde kanaal als de link. Is de link per e-mail verzonden? Stuur het wachtwoord via SMS. Of andersom. De essentie is dat het overnemen van één inbox niemand de volledige set geeft.
Een klein detail dat weinig mensen weten: je kunt meerdere links maken die naar hetzelfde adres leiden, maar met verschillende wachtwoorden. Je geeft vijf personen toegang, elk met een eigen link. Moet er één afscheid nemen? Je blokkeert haar link, de rest zal het niet eens merken.
Je kunt het wachtwoord wijzigen zonder een nieuwe link te maken. Paneel, "Bewerken", nieuw wachtwoord. Let op: alle actieve sessies van 24 uur vervallen onmiddellijk. Iedereen moet het wachtwoord opnieuw invoeren.
De grens waar je op tijd vanaf moet weten
Laten we teruggaan naar het concertticket. Het wachtwoord beschermt tegen de zoekmachine en tegen een onbedoelde gast. Het beschermt niet tegen iemand die het wachtwoord kent en besluit dit met de wereld te delen.
Als je scenario luidt: "dit moet precies deze ene persoon zien en niemand anders", dan is een wachtwoord niet voldoende. Hier heb je accounts, inloggen en autorisatie nodig. Een andere klasse, een ander probleem.
Maar even een hand opsteken, hoe vaak heb je dit scenario echt? In mijn ervaring zelden. In de overgrote meeste gevallen gaat het om het simpele "ik wil niet dat er iemand van de straat hier binnenkomt". En met die reden is er meer dan genoeg.
Als je wilt zien hoe het er van binnen uitziet — bij het maken van een link, vouw "Geavanceerde opties" uit en vink "Wachtwoord toevoegen" aan. De rest gebeurt vanzelf.