Eu o conheço como URL de token seguro, talvez por outro nome lá fora. Mas acho que todos sabem disso.

É uma técnica aplicada principalmente se você deseja restringir a entrega de conteúdo a um determinado cliente, que você entregou um URL específico com antecedênci

Você pega um token secreto, concatena-o com o recurso que deseja proteger, possui-o e quando o cliente solicita esse URL em um de seu servidor, o hash é reconstruído a partir das informações coletadas no pedido e o hash é comparado. Se for o mesmo, o conteúdo será entregue, caso contrário o usuário será redirecionado para o seu site ou outra coisa.

Você também pode colocar um carimbo de data / hora no tempo necessário para permanecer no URL, ou incluir o endereço IP do usuário para restringir a entrega à sua conexã

@This teqnique é usado pela Amazon (S3 e Cloudfront), CDN nível 3, Rapidshare e muitos outros. É também uma parte básica da autenticação de digestão http, embora haja um passo adiante com a invalidação de links e outras coisa

Aqui está um link para oAmazon docs se você quiser saber mais.

Agora, minhas preocupações com esse método são que, se uma pessoa quebrar um token de seus links, o invasor obterá seu texto sem formatação e poderá assinar ele próprio qualquer URL em seu nom

u pior, no caso da amazon, acesse seus serviços em um escopo administrativ

Granted, o hash da string aqui geralmente é bastante longo. E você pode incluir muitas coisas ou até forçar os dados a terem um comprimento mínimo adicionando alguns dados desnecessários à solicitação. Coloque uma pseudo-variável no URL que não é usada e preencha-a com dados aleatório

Portanto, ataques de força bruta para quebrar o sha1 / md5 ou o que quer que você use hash são bastante difíceis. Mas o protocolo está aberto, portanto, você só precisa preencher a lacuna em que está o token secreto e preencher o restante com os dados conhecidos da requisição. E hoje o hardware é incrível e pode calcular md5s a uma taxa de várias dezenas de megabytes por segundo. Esse tipo de ataque pode ser distribuído para uma nuvem de computação e você não está limitado a algo como "10 tentativas por minuto por um servidor de login", o que torna as abordagens de hash geralmente bastante seguras. E agora com o Amazon EC2 você pode até alugar o hardware por um curto período de tempo (vencê-los com suas próprias armas, haha!)

Então, o que você acha? Minhas preocupações têm base ou sou paranóico?

Contudo

o momento, estou projetando uma nuvem de armazenamento de objetos para necessidades especiais (codificação integrada de transferência de mídia e métodos especiais de entrega, como streaming e assim por diante

@Now level3 introduziu uma abordagem alternativa para proteger URLs de token. Atualmente é beta e está aberto apenas para clientes que o solicitam especificamente. Eles chamam de "autenticação proxy".

O que acontece é que o servidor de entrega de conteúdo faz uma solicitação HEAD para um servidor especificado nas configurações (do cliente) e imita a solicitação dos usuários. Portanto, o mesmo caminho GET e endereço IP (como x_forwarder) são passados. Você responde com um código de status HTTP que instrui o servidor a aceitar ou não a entrega de conteúd

Você também pode introduzir algum processo de token seguro nisso e também pode colocar mais restrições. Por exemplo, permita que um URL seja solicitado apenas 10 vezes ou mais.

Obviamente, ele vem com muita sobrecarga porque solicitações e cálculos adicionais ocorrem, mas acho que é razoável e não vejo nenhuma ressalva. Você