https URL com o parâmetro token: o quão seguro é?

Question

Em nosso site, nós fornecemos aos usuários uma simulação com base em sua informação privada (dada por meio de um formulário). Nós gostaríamos de lhes permitir voltar em seus resultados de simulação mais tarde, mas sem forçá-los para criar uma conta de login / senha.

Temos pensado em enviar um e-mail com um link, a partir do qual eles poderiam obter de volta os seus resultados. Mas, naturalmente, temos que garantir essa URL, porque os dados privados está em jogo.

Então, nós estamos com a intenção de passar um token (como uma combinação de 40 caracteres de letras e dígitos, ou um hash MD5) na URL e para usar SSL.

Finalmente, eles iriam receber um email assim:

Oi,
Volte seus resultados em https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

O que você acha sobre isso? É seguro o suficiente? O que você me aconselharia para a geração de token? Que tal passar parâmetros de URL em uma solicitação https?

Answer 1

SSL irá proteger os parâmetros de consulta em trânsito; no entanto, enviar e-mail em si não é seguro, e o e-mail pode saltar ao longo de qualquer número de servidores antes de chegar ao seu destino.

Além disso, dependendo do servidor web o URL completo pode ficar logado seus arquivos de log. Dependendo de quão sensível a dados é que você pode não quer que seus TI pessoas tendo acesso a todas as fichas.

Além disso, o URL com a string de consulta seria salvo na história do seu usuário, permitindo que outros usuários da mesma máquina para acessar a URL.

Finalmente, e o que torna este muito inseguro é, o URL é enviado no cabeçalho Referer de todos os pedidos de qualquer recurso, até mesmo recursos de terceiros. Portanto, se seu usando o Google Analytics, por exemplo, você vai enviar ao Google o URL de token e tudo para eles.

Na minha opinião esta é uma má idéia.

Answer 2

Eu usaria um cookie para isso. O fluxo de trabalho deve ser assim:

1. usuário chega ao seu site pela primeira vez.
2. Site define um cookie
3. O usuário digita dados. Os dados são armazenados no DB usando alguma chave que é armazenada no cookie.
4. Quando as folhas de usuários, você envia um e-mail com um https: Link
5. Quando o usuário voltar, descobre sítio o cookie e pode apresentar ao usuário com os dados antigos.

Agora, o usuário deseja usar um navegador diferente em uma máquina diferente. Neste caso, oferecer um botão de "transferência". Quando o usuário clica neste botão, ela vai ter um "token". Ela pode usar este token em outro computador para redefinir o cookie. Desta forma, o usuário decidir como garantir que ela quer transferir o token.

Answer 3

SSL protege o conteúdo dos dados em trânsito, mas não tenho certeza sobre o URL.

De qualquer maneira, uma maneira de mitigar um atacante reutilizar essa URL token é para se certificar de cada token só pode ser usado uma vez. Você pode até mesmo definir um cookie para que o usuário legítimo pode continuar a usar o link, mas após o primeiro acesso que só irá funcionar para alguém com o cookie.

Se o email do usuário é comprometida e um atacante recebe o link primeiro, bem, você está hosed. Mas o usuário também tem problemas maiores.

Answer 4

E-mail é inerentemente inseguro. Se alguém pode clicar no link e obter os dados, você não está realmente protegendo-o.

Answer 5

Bem, o token é seguro quando está sendo passado através de SSL. O problema que você vai ter é que é avilable para pessoas (aqueles que ele não se destina a) por ser capaz de visualizar a URL.

Se é informação privada como SSN Eu não acho que eu iria enviar uma URL por e-mail. Eu preferiria ter-los a criar um nome de usuário e senha para o site. É muito fácil para comprometer um e-mail com esse tipo de informação em jogo para você e para eles. Se a conta de alguém é comprimised entrará em quesion quem é a culpa realmente é. O mais seguro o melhor que você está a partir de um ponto de vista estritamente CYA.

Answer 6

Eu realmente não que consideram que o suficiente seguro para uma situação onde há questões de privacidade graves. O fato de que você está enviando a URL em um e-mail (presumivelmente cleartext) é de longe o elo mais fraco. Depois disso é o risco de ataques de força bruta sobre os tokens, que (falta a estrutura de um mecanismo de autenticação real) são susceptíveis de ser mais vulneráveis ??do que uma configuração de usuário e senha bem-construído.

Não há problemas em tudo com os parâmetros em um https solicitar, aliás.

Answer 7

Como é, seria uma má idéia. Você vai scarify de segurança com o uso fácil. Como disse antes SSL só irá proteger a transferência de informações entre o navegador do servidor e do cliente e só irá impedir o ataque homem médio. E-mails são muito arriscado e inseguro.

O melhor seria um nome de usuário e autenticação de senha para acessar as informações.

Eu gosto da idéia de cookie mais ou menos. Você deve criptografar as informações do cookie também. Você também deve gerar o token com sal e frase-chave mais o $ _SERVER [ 'HTTP_USER_AGENT'] para limitar a probabilidade de um ataque. Loja o máximo de informações não sensíveis sobre o cliente no cookie para o uso de verificação.

A frase-chave pode ser armazenado no cookie para o uso fácil, mas tenha em mente que também cookie pode ser roubado = (.

É melhor deixar o cliente digitar a frase-chave que ele fornecido, que também é armazenado no banco de dados juntamente com os seus dados.

Ou, a chave pode ser usado no caso da pessoa usa uma máquina diferente que difere nos $ _SERVER [ 'HTTP_USER_AGENT'] parâmetros ou simplesmente perde o cookie. Assim, o cookie pode ser transferido ou set.

Certifique-se também que os dados sensíveis são criptografados no banco de dados. Você nunca sabe;)

Answer 8

Você está ciente de que se qualquer hacker acesso chegar ao seu banco de dados de um monte de informações personnal pode ser dado livremente?

Depois disso, eu diria que isso não é ruim como idéia. Eu não usaria MD5 ou SHA1 como eles não são muito seguros para hash. Eles podem ser "decifrada" (eu sei que não é criptografia) com bastante facilidade.

Caso contrário, eu talvez usar um segundo informações que não seria enviado por e-mail uma espécie de senha. A razão é bastante simples, se o acesso de alguém get para e-mail do usuário (muito fácil com hotmail se você não matar a sua sessão) ele terá acesso a quaisquer informações que o usuário enviou.

Note que o HTTPS irá assegurar e dados cripta enviados a partir de seu site para o usuário final. Nada mais, tomá-lo como um tunel seguro. Nada mais nothign menos.

Answer 9

Pelo que eu entendo de sua idéia, em teoria, alguém poderia digitar uma seqüência de 40 caracteres aleatórios ou hash MD5 e obter alguma outra pessoa detalhes. Enquanto isso pode ser altamente improvável que só deve acontecer uma vez.

A soloution melhor seria para enviar ao usuário um símbolo, em seguida, pedir-lhes para entrar em alguns dos detalhes, como nome, código postal, ssn ou uma combinação destes.