Un link corto protetto da password è un URL breve che chiede una password prima di inviare chiunque avanti. Apri il link, ti trovi su una piccola pagina interstiziale invece della destinazione, digiti la password, e solo allora scatta il redirect. Sbaglia la password e rimani sul prompt. La destinazione non viene mai esposta finché il controllo non passa.
Questa è l'idea completa, e vale la pena essere precisi su di essa perché il nome la sopravvaluta. Un gate password è attrito di accesso davanti a un link. Non è la crittografia della pagina dietro il link. Queste sono garanzie diverse, e confonderle è il modo in cui le persone rimangono poi sorprese. Questo post tratta a cosa serve il gate, i casi d'uso che si adattano davvero, come funziona il controllo al redirect, dove finisce la sicurezza, e con cosa combinarlo affinché il tutto regga.
A cosa serve un link corto protetto da password#
I casi utili condividono una forma: stai condividendo un link attraverso un canale che non controlli completamente, e vuoi che ci sia una seconda cosa oltre all'URL richiesta per l'accesso.
Un documento sensibile è quello ovvio. Stai inviando una bozza di contratto, un modello finanziario o un deck interno a qualcuno al di fuori della tua azienda. Le email vengono inoltrate. I PDF vengono re-inviati. Un link corto che chiunque con l'URL possa aprire è privato solo quanto la persona meno attenta che lo ha mai detenuto. Metti una password su di esso e un forward accidentale non significa più accesso automatico.
I deliverable per i clienti sono lo stesso pattern con una scadenza allegata. Un'agenzia consegna un lotto di asset, un montaggio video, un report di campagna. Il cliente dovrebbe raggiungerlo, la rubrica intera del cliente no. Un URL con gate mantiene il deliverable dietro un segreto condiviso che imposti quando crei il link.
Le campagne private e i contenuti con gate completano l'elenco. Una landing page pre-lancio che vuoi che un piccolo gruppo anteprimi. Un'offerta early-access per una lista d'attesa. Una risorsa riservata ai membri dove il pubblico ha già una password da qualche altra parte. In ogni caso il link viaggia via email o chat, e la password è ciò che separa "mi è stato dato questo" da "mi sono imbattuto in questo."
Cosa non si adatta: qualcosa di davvero segreto, qualcosa di regolamentato, qualcosa dove una fuga è un incidente da segnalare. Per quelli, una password di link condivisa è troppo grossolana. Vuoi l'autenticazione per-persona sulla destinazione stessa, che è un controllo diverso a cui tornerò.
Come funziona un gate password al redirect#
Ecco la parte meccanica, perché l'ordine delle operazioni è ciò che rende il gate significativo.
Un link corto normale è un redirect. L'edge cerca lo slug, trova la destinazione, e scrive un 302 nel browser del visitatore. Veloce, stateless, senza domande. Un link corto protetto da password inserisce un passaggio prima del redirect: l'edge vede che il link ha una password impostata, quindi invece di reindirizzare, restituisce una sfida. Il visitatore ottiene una pagina interstiziale che chiede la password. La invia. Il valore inviato viene controllato rispetto all'hash memorizzato. Se corrisponde, il redirect procede. Se non corrisponde, rimane sul prompt e l'URL di destinazione non viene mai inviato al suo browser.
Due dettagli contano per determinare se questo vale qualcosa.
Primo, la password è hashata, mai memorizzata in chiaro. Il segreto memorizzato di un link dovrebbe essere un hash unidirezionale affinché una lettura del database non consegni a un attaccante ogni password di link del sistema. Argon2id è la raccomandazione attuale per l'hashing delle password, ed è ciò che Elido usa per le password dei link, con la verifica eseguita in-process usando un confronto in tempo costante affinché il controllo stesso non faccia trapelare informazioni attraverso il timing. L'API per un link non restituisce mai l'hash; restituisce un booleano che dice se è impostata una password. Un destinatario che colpisce un link protetto ottiene un 401 con un flag password_required e un token di sfida, e deve inviare la password corretta in una richiesta successiva prima che avvenga il redirect. La meccanica di quella memorizzazione è descritta nella checklist di sicurezza degli URL shortener, sezione sulla protezione con password per-link.
Secondo, il controllo avviene prima che la destinazione venga rivelata. Sembra ovvio, ma un numero sorprendente di schemi di link "privati" fanno trapelare la destinazione nel codice lato client o in una catena di redirect che un visitatore determinato può leggere dal filo. Il punto di fare il controllo al redirect, lato server, è che l'URL di destinazione rimane sul server fino a quando la password non è corretta. Se hai mai visto un gate implementato come JavaScript che recupera l'URL reale e poi reindirizza, hai visto un gate che chiunque con gli strumenti di sviluppo del browser può attraversare direttamente. La valutazione lato server è la differenza, lo stesso ragionamento che fa sì che gli smart link vengano instradati all'edge piuttosto che in uno shim JS su una landing page.
I limiti di sicurezza, detti chiaramente#
Questa è la sezione che le persone saltano e poi rimpiangono, quindi va nel mezzo dove è difficile perderla.
Un gate password protegge il link corto. Non protegge la destinazione. Se la destinazione è un URL pubblico che chiunque può raggiungere digitandolo direttamente, allora la password ferma solo le persone che hanno il link corto, non le persone che possono indovinare o imbattersi nella pagina sottostante. Il gate alza la soglia per il caso comune di condivisione, dove tutto ciò che qualcuno ha è il link corto. Non fa nulla per una destinazione che è già esposta.
Quindi la regola è semplice: anche la destinazione dovrebbe essere access-controlled. Un documento dietro un link corto protetto da password dovrebbe anche vivere da qualche parte che controlla chi sei, non solo da qualche parte che per caso ha un lungo percorso indovinabile. L'OWASP Authentication Cheat Sheet e la relativa guida al controllo degli accessi sono il riferimento qui: l'autenticazione prova chi è qualcuno, il controllo degli accessi decide cosa può raggiungere, e una password di link condivisa è una forma debole del primo che non dice nulla del secondo. Usala come livello di convenienza, non come la cosa che sta tra un attaccante e dati regolamentati.
Qualche altro limite onesto.
Una password condivisa è condivisa. Tutti coloro che ce l'hanno sono la stessa identità per il gate. Non c'è una traccia per-persona di chi ha aperto il link, nessun modo di revocare l'accesso di una persona senza ruotare la password per tutti. Se hai bisogno di sapere che Dana in particolare ha aperto il deliverable, una password di link condivisa non te lo dirà.
Il link dovrebbe essere servito su HTTPS, sempre. Una password inviata su plain HTTP è una password inviata in chiaro a chiunque sul percorso di rete. La crittografia del trasporto è il piano, non una funzionalità; la panoramica HTTPS di MDN spiega perché. Elido serve i redirect su HTTPS per default, anche sui domini personalizzati, ma il principio vale ovunque tu metta un gate.
E una password non è un sostituto per la scadenza. Un link che rimane live per sempre è una responsabilità che abbia o meno una password, perché il segreto si diffonde lentamente nel tempo mentre viene incollato in più posti. Abbina il gate a una durata.
Con cosa combinarlo#
Un gate password è un controllo. Funziona meglio impilato con altri che coprono ciò che non può.
La scadenza e i limiti massimi di clic delimitano il link nel tempo e nell'uso. Imposta un expires_at affinché un deliverable per un cliente si oscuri dopo la fine del coinvolgimento, e un limite massimo di clic affinché un link di download monouso si disattivi dopo essere stato aperto una volta. Entrambi vengono applicati al redirect prima che venga registrato qualsiasi evento di clic, il che significa che un tentativo di password errato contro un link già scaduto non raggiunge mai nemmeno il gate. I compromessi sulla durata sono nel post scadenza dei link e link autodistruttivi.
I limiti IP o geo restringono chi può tentare il gate. Se un deliverable per un cliente viene aperto solo da un ufficio, limitare il link a quell'intervallo significa che una password trapelata più un link trapelato fallisce comunque da qualsiasi altra parte. I controlli a livello di regione sono trattati nel post link corti con geo-targeting, e si combinano con la password invece di sostituirla.
Per i team, la risposta giusta di solito non è affatto una password condivisa. È SSO. Quando le persone che dovrebbero raggiungere un link sono dipendenti nel tuo identity provider, porta la destinazione dietro SCIM e SSO affinché l'accesso segua la directory: qualcuno lascia l'azienda, il suo accesso è via, nessuna rotazione della password richiesta. Una password di link condivisa è per la condivisione esterna ad-hoc; l'accesso gestito dalla directory è per qualsiasi cosa dove hai bisogno di revoca per-persona. La guida alla configurazione SCIM e SSO spiega come collegarlo, e la pagina delle soluzioni enterprise copre dove si adatta.
Il principio generale è la difesa a livelli. Nessun singolo controllo qui è forte da solo. Una password ferma l'accesso casuale, la scadenza delimita la finestra, HTTPS protegge il filo, il controllo degli accessi alla destinazione protegge il contenuto, e SSO gestisce il caso del team. Impila quelli di cui la tua situazione ha bisogno.
Una guida pratica#
Se vuoi creare un gate per un link, la forma del lavoro è la stessa indipendentemente dallo strumento.
Imposta la password quando crei o modifichi il link. Le impostazioni del link dovrebbero consentirti di allegare una password; una volta impostata, il link smette di essere un semplice redirect e inizia a restituire la sfida. Scegli una password che non sia banalmente indovinabile e non sia riutilizzata da qualche altra parte, perché un segreto condiviso che sblocca anche la tua email è un cattivo segreto condiviso.
Condividi il link e la password attraverso canali separati. Questa è la singola abitudine di maggior valore. Invia il link corto nell'email o nel documento, e invia la password tramite un messaggio chat, un'email separata o una breve telefonata. Se entrambi viaggiano nello stesso messaggio, un singolo messaggio intercettato consegna tutto, e il gate non ti ha portato nulla. Dividerli significa che un attaccante ha bisogno di due canali, non uno.
Imposta una scadenza allo stesso tempo. Decidi in anticipo per quanto tempo dovrebbe vivere il link e se dovrebbe raggiungere il limite dopo un numero noto di aperture, e impostali quando lo crei piuttosto che prometterti di pulirlo in seguito. Non lo farai.
Verifica che la destinazione abbia il proprio controllo degli accessi se il contenuto è sensibile. Il gate sta facendo il suo lavoro per il caso di condivisione. Se anche il documento sottostante deve resistere a qualcuno che indovina l'URL, quella protezione deve vivere sulla destinazione, non sul link corto. Per un trattamento più completo di come questi elementi si adattano a un modello di minaccia, gli URL shortener sono sicuri illustra il quadro più ampio, e la pagina trust copre la posizione di Elido.
Questa è la versione onesta dei link corti protetti da password. Sono un modo utile e a basso attrito per impedire che un URL condiviso sia aperto da chiunque lo riceva casualmente. Non sono un vault. Usati come un livello in uno stack, con scadenza e una destinazione adeguatamente access-controlled, fanno esattamente il lavoro che dovrebbero. Usati come unica cosa tra un attaccante e qualcosa che conta, ti deluderanno. Imposta il gate, dividi i canali, delimita la durata e blocca la destinazione, e hai un flusso di condivisione che regge.
Se vuoi vedere quali controlli sono disponibili su quale piano, la pagina dei prezzi li elenca, e la funzionalità domini personalizzati copre la gestione dei link con gate sul tuo dominio brandizzato su HTTPS. La configurazione è trattata in come configurare link corti brandizzati.