Um link curto protegido por palavra-passe é um URL curto que pede uma palavra-passe antes de enviar alguém para a frente. Abre o link, depara-se com uma pequena página intermédia em vez do destino, escreve a palavra-passe, e só então o redirect dispara. Erre a palavra-passe e fica no pedido. O URL de destino nunca é exposto até a verificação passar.
Essa é toda a ideia, e vale a pena ser preciso sobre ela porque o nome promete demasiado. Um portão de palavra-passe é fricção de acesso à frente de um link. Não é encriptação da página por trás do link. Essas são garantias diferentes, e confundi-las é como as pessoas acabam surpreendidas mais tarde. Este artigo cobre para que serve o portão, os casos de uso que realmente se adequam, como a verificação funciona no redirect, onde a segurança termina e com o que combiná-lo para que tudo se mantenha.
Para Que Serve um Link Curto Protegido por Palavra-passe#
Os casos úteis partilham uma forma: está a partilhar um link através de um canal que não controla totalmente, e quer uma segunda coisa além do URL para ser necessária para entrar.
Um documento sensível é o mais óbvio. Está a enviar um rascunho de contrato, um modelo financeiro ou uma apresentação interna para alguém fora da sua empresa. E-mails são reencaminhados. PDFs são reenviados. Um link curto que qualquer pessoa com o URL pode abrir é apenas tão privado quanto a pessoa menos cuidadosa que alguma vez o teve. Coloque uma palavra-passe e um reencaminhamento acidental já não significa acesso automático.
As entregas a clientes seguem o mesmo padrão com um prazo associado. Uma agência entrega um lote de ativos, uma edição de vídeo, um relatório de campanha. O cliente deve acedê-lo, não toda a lista de endereços do cliente. Um URL com portão mantém a entrega por trás de um segredo partilhado que define quando cria o link.
Campanhas privadas e conteúdo com portão completam a lista. Uma página de aterragem de pré-lançamento que quer que um pequeno grupo pré-visualize. Uma oferta de acesso antecipado para uma lista de espera. Um recurso apenas para membros onde o público já tem uma palavra-passe de outro lado. Em cada caso o link viaja por e-mail ou chat, e a palavra-passe é o que separa "fui dado este" de "tropeçei nisto".
O que não se adequa: qualquer coisa verdadeiramente secreta, qualquer coisa regulamentada, qualquer coisa onde um vazamento é um incidente reportável. Para esses casos, uma palavra-passe de link partilhada é demasiado grosseira. Quer autenticação por pessoa no próprio destino, que é um controlo diferente e a que voltarei.
Como Funciona um Portão de Palavra-passe no Redirect#
Aqui está a parte mecânica, porque a ordem das operações é o que torna o portão significativo.
Um link curto normal é um redirect. A borda consulta o slug, encontra o destino e escreve um 302 no browser do visitante. Rápido, sem estado, sem perguntas. Um link curto protegido por palavra-passe insere um passo antes do redirect: a borda vê que o link tem uma palavra-passe definida, por isso em vez de reencaminhar, devolve um desafio. O visitante obtém uma página intermédia a pedir a palavra-passe. Submete-a. O valor submetido é verificado contra o hash armazenado. Se corresponder, o redirect prossegue. Se não corresponder, fica no pedido e o URL de destino nunca é enviado para o seu browser.
Dois detalhes importam para que isto valha alguma coisa.
Primeiro, a palavra-passe é tratada com hash, nunca armazenada em texto simples. O segredo armazenado de um link deve ser um hash de sentido único para que uma leitura de base de dados não entregue a um atacante cada palavra-passe de link no sistema. Argon2id é a recomendação atual para hash de palavras-passe, e é o que a Elido usa para palavras-passe de links, com a verificação feita em processo usando uma comparação de tempo constante para que a própria verificação não vaze informação através de timing. A API para um link nunca devolve o hash; devolve um booleano que diz se uma palavra-passe está definida. Um destinatário a aceder a um link protegido obtém um 401 com um sinalizador password_required e um token de desafio, e tem de submeter a palavra-passe correta num pedido de seguimento antes de o redirect acontecer. A mecânica desse armazenamento está exposta na lista de verificação de segurança de encurtadores de URL, secção sobre proteção de palavra-passe por link.
Segundo, a verificação acontece antes de o destino ser revelado. Isso parece óbvio, mas um número surpreendente de esquemas de links "privados" vaza o destino em código do lado do cliente ou numa cadeia de redirect que um visitante determinado pode ler na rede. O ponto de fazer a verificação no redirect, do lado do servidor, é que o URL de destino fica no servidor até a palavra-passe estar correta. Se alguma vez viu um portão implementado como JavaScript que obtém o URL real e depois redireciona, viu um portão que qualquer pessoa com as ferramentas de desenvolvimento do browser pode atravessar diretamente. A avaliação do lado do servidor é a diferença - o mesmo raciocínio que faz os smart links encaminhar na borda em vez de num shim JS numa página de aterragem.
Os Limites de Segurança, Ditos Claramente#
Esta é a secção que as pessoas saltam e depois lamentam, por isso vai no meio onde é difícil de ignorar.
Um portão de palavra-passe protege o link curto. Não protege o destino. Se o destino é um URL público que qualquer pessoa pode alcançar escrevendo-o diretamente, então a palavra-passe está apenas a parar pessoas que têm o link curto, não pessoas que podem adivinhar ou tropeçar na página subjacente. O portão eleva a fasquia para o caso de partilha comum, onde tudo o que alguém tem é o URL curto. Não faz nada para um destino que já está exposto.
Por isso a regra é simples: o destino também deve ter controlo de acesso. Um documento por trás de um link curto protegido por palavra-passe também deve viver algures que verifica quem você é, não apenas algures que por acaso tem um caminho longo e difícil de adivinhar. A Folha de Dicas de Autenticação do OWASP e a orientação sobre Controlo de Acesso companheira são a referência aqui: a autenticação prova quem alguém é, o controlo de acesso decide a que pode alcançar, e uma palavra-passe de link partilhada é uma forma fraca da primeira que não diz nada sobre a segunda. Use-a como uma camada de conveniência, não como a coisa que se encontra entre um atacante e algo que importa.
Mais alguns limites honestos.
Uma palavra-passe partilhada é partilhada. Toda a gente que a tem é a mesma identidade para o portão. Não há um rasto por pessoa de quem abriu o link, nenhuma forma de revogar o acesso de uma pessoa sem rodar a palavra-passe para todos. Se precisar de saber que a Diana especificamente abriu a entrega, uma palavra-passe de link partilhada não lhe dirá.
O link deve ser servido sobre HTTPS, sempre. Uma palavra-passe submetida sobre HTTP simples é uma palavra-passe enviada em claro para qualquer pessoa no caminho de rede. A encriptação de transporte é o mínimo, não uma funcionalidade; a visão geral do HTTPS da MDN explica porquê. A Elido serve redirects sobre HTTPS por defeito, incluindo em domínios personalizados, mas o princípio aplica-se em qualquer lugar onde coloque um portão.
E uma palavra-passe não é substituto para expiração. Um link que fica ativo para sempre é uma responsabilidade quer tenha uma palavra-passe ou não, porque o segredo vaza lentamente ao longo do tempo à medida que é colado em mais lugares. Combine o portão com um tempo de vida.
Com O Que Combiná-lo#
Um portão de palavra-passe é um controlo. Funciona melhor empilhado com outros que cobrem o que ele não pode.
Expiração e limites máximos de cliques limitam o link no tempo e no uso. Defina um expires_at para que uma entrega a um cliente fique inativa após o fim do compromisso, e um limite máximo de cliques para que um link de download de uso único desative após ter sido aberto uma vez. Ambos são aplicados no redirect antes de qualquer evento de clique ser registado, o que significa que uma tentativa de palavra-passe errada contra um link já expirado nunca chega sequer ao portão. As trocas em torno do tempo de vida estão no artigo expiração de links e links autodestrutivos.
Limites de IP ou geo reduzem quem pode tentar o portão de todo. Se uma entrega a um cliente só é aberta de um escritório, restringir o link a esse intervalo significa que uma palavra-passe vazada mais um link vazado ainda falha de qualquer outro lugar. Os controlos ao nível da região estão cobertos no artigo links curtos com geo-targeting, e compõem-se com a palavra-passe em vez de a substituir.
Para equipas, a resposta certa normalmente não é uma palavra-passe partilhada de todo. É SSO. Quando as pessoas que devem aceder a um link são funcionários no seu fornecedor de identidade, coloque o portão no destino atrás de SCIM e SSO para que o acesso siga o diretório: alguém sai da empresa, o acesso desaparece, sem rotação de palavra-passe necessária. Uma palavra-passe de link partilhada é para partilha externa ad-hoc; o acesso gerido por diretório é para qualquer coisa onde precisa de revogação por pessoa. O guia de configuração de SCIM e SSO percorre a ligação, e a página de soluções empresariais cobre onde se adequa.
O princípio geral é defesa em camadas. Nenhum controlo único aqui é forte por si só. Uma palavra-passe para o acesso casual, a expiração limita a janela, HTTPS protege a rede, o controlo de acesso no destino protege o conteúdo e SSO gere o caso de equipa. Empilhe os que a sua situação necessita.
Como Fazer na Prática#
Se quiser colocar um portão num link, a forma do trabalho é a mesma independentemente da ferramenta.
Defina a palavra-passe quando criar ou editar o link. As definições do link devem permitir-lhe associar uma palavra-passe; uma vez definida, o link deixa de ser um redirect simples e começa a devolver o desafio. Escolha uma palavra-passe que não seja trivialmente adivinhável e não reutilizada de outro lado, porque um segredo partilhado que também desbloqueia o seu e-mail é um mau segredo partilhado.
Partilhe o link e a palavra-passe por canais separados. Este é o hábito de maior valor único. Envie o link curto no e-mail ou no documento, e envie a palavra-passe por uma mensagem de chat, um e-mail separado ou uma chamada rápida. Se ambos viajam na mesma mensagem, uma única mensagem intercetada entrega tudo, e o portão não lhe comprou nada. Separá-los significa que um atacante precisa de dois canais, não de um.
Defina uma expiração ao mesmo tempo. Decida desde o início por quanto tempo o link deve viver e se deve terminar após um número conhecido de aberturas, e defina isso quando o cria em vez de se prometer a si mesmo que o limpará mais tarde. Não o fará.
Verifique que o destino tem o seu próprio controlo de acesso se o conteúdo for sensível. O portão está a fazer o seu trabalho para o caso de partilha. Se o documento subjacente também precisa de resistir a alguém que advinha o URL, essa proteção tem de viver no destino, não no link curto. Para um tratamento mais completo de como estas peças se encaixam num modelo de ameaças, os encurtadores de URL são seguros percorre o quadro mais amplo, e a página de confiança cobre a postura da Elido.
Essa é a versão honesta dos links curtos protegidos por palavra-passe. São uma forma útil e de baixa fricção de impedir que um URL partilhado fique aberto a qualquer pessoa que o receba. Não são um cofre. Usados como uma camada numa pilha, com expiração e um destino com controlo de acesso adequado, fazem exatamente o trabalho que devem. Usados como a única coisa entre um atacante e algo que importa, irão dececcioná-lo. Defina o portão, separe os canais, limite o tempo de vida e bloqueie o destino, e terá um fluxo de partilha que se mantém.
Se quiser ver quais os controlos em cada plano, a página de preços lista-os, e a funcionalidade de domínios personalizados cobre servir links com portão no seu próprio domínio com marca sobre HTTPS. A configuração está coberta em como configurar links curtos com marca.