Os URLs privados e não mapeáveis são equivalentes à autenticação baseada em senha?

Um URL privado é um pouco mais fraco que a autenticação com credenciais, mesmo que o tamanho de bit do URL seja o mesmo das credenciais. A razão é que o URL pode mais facilmente "vazar". Ele é armazenado em cache no navegador, registrado no servidor e assim por diante. Se você tiver links externos, o URL privado poderá aparecer no cabeçalho do referenciador em outros sites. (Também pode ser visto por pessoas olhando por cima do seu ombro.)

Se vazar (por acidente ou por descuido do usuário), ele pode acabar sendo público e até indexado pelo Google, o que permitiria que um invasor pesquisasse facilmente todos os URLs vazados no seu site.

Por esse motivo, os URLs particulares são normalmente usados apenas para operações de uma só vez, como redefinições de senha, e normalmente eles só ficam ativos por um tempo limitado.

Há um encadeamento relacionado na segurança da informação: Os URLs aleatórios são uma maneira segura de proteger as fotos de perfil ? - uma resposta compartilha esta história: O Dropbox desabilita os links antigos compartilhados depois que as declarações de impostos acabam no Google . Portanto, não é apenas um risco teórico.

Nota:

Muitas pessoas parecem confundir um URL "privado" com autenticação. Além disso, parece haver alguma confusão de que enviar o link por meio de uma entidade confiável é uma tentativa de autenticação de dois fatores. Para ser claro, estamos falando de um recurso de acesso público, embora um que seja suficientemente difícil de adivinhar.

Ao usar um URL privado, você deve sempre assumir que ele pode ser comprometido - você deve criar um URL para que, mesmo que ele seja comprometido, o recurso não vaze informações para o invasor.

URLs privados / difíceis de adivinhar não são equivalentes a autenticação baseada em senha. Por natureza, os URLs privados não são privados - são recursos acessíveis ao público. Eu acho que o termo "privado" URL é um equívoco, mas eles são "obscuros" URLs.

Existem certos casos em que o uso de um URL "particular" é aceitável, mas eles são inerentemente menos seguros do que os métodos de autenticação tradicionais, como autenticação por senha ou autenticação baseada em chave.

Alguns dos lugares que eu geralmente vi URLs "particulares" usados são:

1. E-mails de redefinição de senha
2. Emails de geração de certificado
3. Emails de confirmação da conta / email
4. Entrega do conteúdo comprado (e-books, etc)
5. Outras coisas diversas, como check-in de voo, impressão de cartão de embarque, uso de URLs particulares, além da autenticação tradicional

O ponto comum aqui é que URLs aleatórios são tipicamente bons apenas para operações de um tiro. Além disso, a autenticação tradicional e os URLs aleatórios não são mutuamente exclusivos - na verdade, eles podem ser usados em conjunto uns com os outros para fornecer segurança adicional ao entregar um recurso.

Como Robert Harvey apontou, a única maneira de usar com segurança uma URL aleatória / privada é gerar a página dinamicamente e enviar a URL ao usuário de forma que o usuário possa ser considerado semi-autenticado. Isso pode ser e-mail, SMS, etc.

Normalmente, um URL privado / gerado aleatoriamente tem algumas propriedades:

1. Deve expirar após um tempo razoável
2. Deve ser um URL de uso único: ou seja, ele deve expirar após a primeira vez em que é acessado.
3. Deve adiar a autenticação do usuário para alguma outra entidade em que ele confie para autenticar com segurança o usuário. (Enviando o link via e-mail ou SMS, etc)
4. Deve ser impossível para um computador moderno forçar a URL no período de tempo antes da expiração - seja pela taxa que limita a API que expõe o recurso ou pela criação de um endpoint de url com entropia suficiente de tal forma que não seja possível adivinhar. / li>
5. Não deve vazar informações sobre o usuário. IE: Se a página for redefinir uma senha: a página não deve exibir as informações da conta do solicitante. Se Alice solicitar um link de redefinição de senha e Bob adivinhar o URL, Bob não deve saber qual senha ele está redefinindo.
6. Se vazar informações sobre o usuário, ele deve ser usado em cima da autenticação tradicional, por exemplo, uma página pode considerar um usuário autenticado se tiver um conjunto de cookies ou se o seu session_id ainda for válido.

Recursos diferentes requerem diferentes níveis de segurança. Se você quiser compartilhar uma receita secreta com alguns amigos, por exemplo, seria aceitável usar um URL aleatório / privado para compartilhá-la com eles. No entanto, se o recurso puder ser usado para roubar a identidade de alguém ou comprometer suas contas com outros provedores de serviços, você provavelmente se importaria muito mais em restringir o acesso a esse recurso.

Praticamente todos os esquemas de autenticação se resumem a provar que você conhece um segredo. Você se autentica em algum serviço, provando que você sabe uma senha secreta, ou uma URL secreta ou, ...

Alguns protocolos mais avançados (por exemplo, OAUTH, Kerberos, ...) permitem provar que você conhece o segredo sem realmente transmitir o segredo. Isso é importante porque há mais maneiras de obter um segredo "incognoscível" além de adivinhá-lo.

Eu poderia estar sentado no mesmo cybercafé que você mesmo, escutando sua conexão Wi-Fi ao digitar sua URL "não-solicitável". Nesse ponto, se você não estava usando SSL, ou se eu posso explorar o novo bug mais recente na sua implementação SSL, então eu também saberia seu segredo.

Muitas respostas boas neste tópico, mas para abordar diretamente a questão:

From the perspective of an evildoer who wants to access this resource, are these approaches equivalent? If not, what makes them different?

Deixe-me estabelecer uma definição. "Autenticação" é o fornecimento de credenciais para provar uma reivindicação de identidade. O controle de acesso geralmente é baseado na identificação do usuário.

Seu URL secreto não está vinculado a um usuário específico. Como outros salientaram, ele pode acabar em um arquivo de log de proxy ou em uma solicitação de pesquisa indexada pelo Google ou por muitas outras maneiras de vazar.

Por outro lado, uma senha está vinculada a uma conta de usuário única. Você pode redefini-la ou permitir que ela seja usada apenas a partir do local de origem do usuário ou do endereço IP conhecido ou de qualquer outro número de controles.

Um nome de usuário / senha oferece um controle muito mais granular do acesso.

O controle de acesso permite um acesso de identidade (assunto) a um recurso (objeto). Em seu exemplo de URL, a identidade é "qualquer pessoa que conseguir o URL, por qualquer meio".

Use o nome de usuário / senha, se puder. URLs vazam de todas as formas inesperadas ao longo do tempo.

Uma URL secreta é tão segura quanto uma senha secreta. No entanto, as senhas são mais fáceis de manter em sigilo do que as URLs, porque todos e seus programas sabem que as senhas devem permanecer secretas.

Por exemplo, seu navegador não mostrará uma senha na tela, apenas armazenará senhas com sua permissão e oferecerá meios para proteger o armazenamento de senha (como armazenamento criptografado desbloqueado por uma senha mestra). Em contrapartida, ele sempre mostrará URLs na tela, poderá vazá-los pelo cabeçalho do referenciador e armazená-los automaticamente em seu histórico de navegação sem qualquer proteção adicional.

Da mesma forma, os proxies HTTP geralmente não registram senhas, enquanto URLs são comumente registrados.

O uso de URLs para autenticação também significa que o compartilhamento de URLs compartilha a autenticação, o que dificulta a revogação (ou registro) do acesso individualmente.

E, claro, as URLs secretas herdam todas as fraquezas das senhas secretas. Em particular, usar uma senha para autenticação revelará essa senha para o servidor e qualquer pessoa capaz de ler sua comunicação.

Outro item não mencionado em nenhum lugar é o afogamento de "palpites". Para a maioria dos sistemas de autenticação por senha, você obtém um número limitado de tentativas de adivinhar uma senha para um usuário antes que novas tentativas de autenticação sejam bloqueadas ou limitadas.

Embora você possa fazer algo semelhante com "palpites" em relação ao seu esquema de URL, seria um pouco mais difícil de implementar. Se houver um padrão reconhecível para sua geração de URL, talvez seja difícil impedir que alguém se configure para percorrer seu espaço de URL "aleatório".

Existe outro aspecto que ainda não vi mencionado - encurtadores de URL.

Em uma publicação recente (abril de 2016), foi alegado que os serviços de encurtamento de URL anulam completamente a segurança aumentada fornecida por URLs "unguessáveis" gerados aleatoriamente. O espaço de URL do serviço de encurtamento é consideravelmente menor do que seu URL gerado aleatoriamente - o que significa que qualquer URL "segura" compartilhada com um serviço encurtador pode ser adivinhada de maneira mais fácil do que o esperado.

Para ilustrar - vamos supor que sua URL aleatória tenha 128 bits de comprimento (ou seja, um guid). Além disso, vamos supor que seu gerador de números aleatórios seja realmente strong e que você gere esses bits de maneira uniforme. Adivinhar um número de 128 bits é muito difícil e pode levar um tempo considerável - sua URL é efetivamente protegida por chave de 128 bits.

Então, vamos supor que alguém tenha compartilhado esse URL no encurtador de URL do Google. Hoje esse serviço emite um ID de 10 caracteres, composto de letras e números. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 < 2 ^ 52 - então diminuímos efetivamente a força das chaves de 128 para 52 bits.

Acrescente a isso o fato de que os geradores não usam todo o espaço devido a outras considerações e você pode montar um ataque efetivo que combine força bruta com canais laterais (provavelmente buffers de URL aleatórios pré-alocados).

O artigo original: link
Um post no blog resumindo o artigo (pelo autor): link