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

Quero expor um recurso na web. Quero proteger esse recurso: garantir que ele seja acessível apenas a certos indivíduos.

Eu poderia configurar algum tipo de autenticação baseada em senha . Por exemplo, eu só podia permitir o acesso ao recurso por meio de um servidor Web que verifica as solicitações recebidas por credenciais corretas (talvez em alguns bancos de dados de usuários) antes de enviar o arquivo.

Como alternativa, eu poderia apenas usar um URL privado . Ou seja, eu poderia simplesmente hospedar o recurso em algum caminho impossível de adivinhar, por exemplo https://example.com/23idcojj20ijf..., que restringe o acesso àqueles que conhecem a string exata.

Da perspectiva de um malfeitor que deseja acessar esse recurso, essas abordagens são equivalentes? Se não, o que os torna diferentes? E quanto à capacidade de manutenção, existem prós e contras em qualquer uma das abordagens que eu deveria estar ciente antes de implementar uma ou outra?

Um URL privado é um pouco mais fraco que a autenticação com credenciais, mesmo que o tamanho do bit do URL seja o mesmo que o das credenciais. O motivo é que o URL pode "vazar" com mais facilidade. Ele é armazenado em cache no navegador, conectado ao servidor e assim por diante. Se você tiver links de saída, 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 ele vazar (por acidente ou devido ao descuido do usuário), 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 privados geralmente são usados ​​apenas para operações de uma só vez, como redefinições de senha, e geralmente são ativas apenas por um tempo limitado.

Existe um tópico relacionado em Segurança da informação: os URLs aleatórios são uma maneira segura de proteger fotos de perfil ? - uma resposta compartilha a história: o Dropbox desativa os links compartilhados antigos depois que as declarações fiscais acabam no Google . Portanto, não é apenas um risco teórico.

Nota:

Muitas pessoas parecem estar confundindo um URL "privado" com autenticação. Além disso, parece haver alguma confusão de que o envio do link por uma entidade confiável é uma tentativa de autenticação de dois fatores. Para deixar claro, estamos falando de um recurso acessível ao público, embora 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 seja comprometido, o recurso não vaze informações para o invasor.

URLs privados / difíceis de adivinhar não são equivalentes à 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 URL "privado" é um nome impróprio, mas são URLs "obscuros".

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

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

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

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

Como Robert Harvey apontou, a única maneira de usar com segurança um URL aleatório / privado é gerar a página dinamicamente e enviá-lo ao usuário de uma maneira que o usuário possa ser considerado semi-autenticado. Pode ser email, SMS etc.

Um URL privado / gerado aleatoriamente geralmente possui algumas propriedades:

1. Deve expirar após um período de tempo razoável
2. Deve ser um URL de uso único: ou seja, deve expirar após a primeira vez que for acessado.
3. Deve adiar a autenticação do usuário para outra entidade em que confia para autenticar com segurança o usuário. (Enviando o link por e-mail ou SMS, etc)
4. Deveria ser impossível para um computador moderno forçar com força o URL no período anterior à expiração - limitando a taxa da API que expõe o recurso ou criando um ponto de extremidade de URL com entropia suficiente para que não possa ser adivinhado.
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 de alguma forma adivinhar o URL, Bob não deverá ter como saber de quem está redefinindo a senha.
6. Se vazar informações sobre o usuário, ele deverá ser usado em cima da autenticação tradicional; por exemplo, uma página pode considerar um usuário autenticado se ele tiver um conjunto de cookies ou se o ID da sessão ainda for válido.

Recursos diferentes requerem diferentes níveis de segurança. Se você deseja compartilhar uma receita secreta com alguns amigos, por exemplo, seria aceitável usar um URL aleatório / privado para compartilhá-lo 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 com a restrição de 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 ao provar que conhece uma senha secreta ou um URL secreto ou, ...

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

Eu poderia estar sentado no mesmo cibercafé que você mesmo, espionando sua conexão Wi-Fi quando você digita seu URL "indescritível". Nesse ponto, se você não estivesse usando SSL ou se eu puder explorar o novo bug mais recente na sua implementação de SSL, também conheceria seu segredo.

Muitas respostas boas já estão neste tópico, mas para abordar diretamente a pergunta:

Da perspectiva de um malfeitor que deseja acessar esse recurso, essas abordagens são equivalentes? Se não, o que os torna diferentes?

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 já apontaram, ele pode acabar no arquivo de log de um proxy, ou em uma solicitação de pesquisa indexada pelo Google ou em muitas outras maneiras pelas quais ele pode vazar.

Por outro lado, uma senha está vinculada a uma conta de usuário exclusiva. Você pode redefini-lo ou permitir apenas que ele seja usado no local de origem do usuário, no endereço IP conhecido ou em 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 que uma identidade (assunto) acesse um recurso (objeto). No seu exemplo de URL, a identidade é "qualquer pessoa que obtenha o URL, por qualquer meio".

Vá com o nome de usuário / senha, se puder. Os URLs vazam de várias maneiras inesperadas ao longo do tempo.

Um URL secreto é tão seguro quanto uma senha secreta. No entanto, as senhas são mais fáceis de manter em segredo do que os URLs, porque todos e seus programas sabem que as senhas devem permanecer em segredo.

Por exemplo, seu navegador não mostra uma senha na tela, apenas armazena senhas com sua permissão e oferece meios para proteger esse armazenamento de senhas (como armazenamento criptografado desbloqueado por uma senha mestra). Por outro lado, ele sempre mostra os URLs na tela, pode vazá-los através do cabeçalho do referenciador e os armazena automaticamente no seu histórico de navegação sem nenhuma proteção adicional.

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

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

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

Outro item não observado em qualquer lugar é a limitação de "suposições". Para a maioria dos sistemas de autenticação de senha, você recebe um número limitado de tentativas de adivinhar uma senha para um usuário antes que outras tentativas de autenticação sejam bloqueadas ou limitadas.

Embora você possa fazer algo semelhante com 'suposições' contra o seu esquema de URL, seria um pouco mais difícil de implementar. Se houver um padrão reconhecível na sua geração de URL, pode ser difícil impedir que alguém configure seu caminho através do espaço de URL 'aleatório'.

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

Em uma publicação recente (abril de 2016), foi reivindicado que os serviços de encurtador de URL anulam completamente o aumento da segurança fornecida por URLs "não-assistíveis" gerados aleatoriamente. O espaço de URL do serviço mais curto é consideravelmente menor que o URL gerado aleatoriamente - o que significa que qualquer URL "seguro" compartilhado com um serviço de encurtador pode ser adivinhado de maneira mais fácil do que o previsto.

Para ilustrar - vamos supor que seu URL aleatório tenha 128 bits de comprimento (ou seja, um guia). Além disso, vamos supor que seu gerador de números aleatórios seja realmente forte 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 - seu URL é protegido 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 por letras e números. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - então reduzimos pela metade a força da chave de 128 para 52 bits.

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

O artigo original: http://arxiv.org/pdf/1604.02734v1.pdf
Uma postagem no blog que resume o artigo (pelo autor): https://freedom-to-tinker.com/blog/vitaly/gone-in- URLs de seis caracteres curtos considerados prejudiciais para serviços em nuvem /