Existe alguma maneira de ter um armazenamento persistente (independentemente de quão pequeno) do lado do cliente via Web?

Question

Ok, já que nenhum de vocês gosta da minha pergunta, deixe -me reformular.

O usuário faz login em um formulário HTML. Com o JavaScript, sua senha é hashed localmente (salgada também). O servidor sabe qual deve ser a senha + sal, o usuário já está registrado, Blahblahblah. Agora o usuário solicita uma página. O servidor envia um ID aleatório para o usuário. Quando o usuário carrega a próxima página, esse ID aleatório é anexado à chave que possui localmente armazenados, é hash de hash e é enviado ao servidor. O servidor sabe o que é a chave e o ID aleatório, executa o mesmo hash e se compara. Se eles correspondem, parabéns, ele veio do computador adequado. Caso contrário, alguém está farejando seu tráfego TCP/IP.

Tudo isso é obviamente sem SSL, caso contrário, isso seria altamente redundante.

Minha pergunta - como faço para armazenar a chave em um PC cliente?

Postagem original:

Olá;

Estou trabalhando no desenvolvimento de um sistema de gerenciamento de conteúdo PHP e criei um sistema de login seguro. O único problema é que isso exigiria alguma forma de armazenamento do lado do cliente (para uma chave muito pequena, 40 caracteres de comprimento) - caso contrário, o usuário precisaria digitar sua senha em cada página de carregamento.

Existe uma maneira de, usando PHP ou JavaScript, posso armazenar uma pequena corda de 40 caracteres no PC de um cliente e recuperá-la mais tarde?

EDIT: Os cookies não são uma opção. Essa string de 40 caracteres não pode deixar o computador do cliente e todos os cookies conjuntos são enviados com cada cabeçalho HTTP.

EU REPITO - Os cookies são inseguros e não é uma opção viável para isso.

Deixe -me retrabalhá -lo assim - o cliente envia um formulário HTTP. Com algum idioma de script (por exemplo, JavaScript), a senha é retirada do formulário, não enviada ao servidor, criptografada e é mantida no lado do cliente, que eu posso recuperar e verificar (por hash com uma chave enviada ao usuário do usuário do o servidor). Esta verificação é enviada ao servidor, nunca a chave.

Answer 1

Você pode usar alguns truques diferentes para manter o estado no cliente, pode manter um quadro de nível superior e armazenar uma variável JavaScript lá.

Você pode usar o Flash Local "SharedObject",

Silverlights 'IsolatedStorage

ou o equivalente no Google Gears.

mas..

Não siga esta linha de pensamento. Você precisa de ssl. Você não vai construir algo seguro, criará algo que atire em você ou alguém usando seu aplicativo no pé.

Answer 2

Já existe um sistema baseado em navegador que usa teclas para proteger a transferência de dados. É chamado de SSL.

Answer 3

Primeiro, vou responder à pergunta de "Posso armazenar dados do lado do cliente sem usar um cookie":

• Você poderia usar um flash SharedObject, mas é claro que requer flash, e o usuário precisa clicar em uma caixa de confirmação para permitir.
• O HTML5 possui bancos de dados do lado do cliente, então há outra opção emergente para você.
• Use o Google Gears no lado do cliente e use seus locais API do banco de dados

Mas - para seus propósitos, você pode projetar um formulário de login que não transmite a senha, mas envia um hash dela. Seu script PHP enviaria um formulário que incluía um valor secreto de sal e, em seguida, você tem algum JavaScript que liga o evento de envio e substitui a senha inserida pelo hash salgado.

Answer 4

Não sou um desenvolvedor de PHP, mas eu defendia que você procure por sistemas de autenticação pré-existentes. Eles costumam ser um pouco mais seguros do que o que você escreveria (como esse seria o objetivo principal deles). Isso também permitiria revisar o código e ver como eles fizeram isso e descobrir o porquê.

Edit: você quase sempre deseja lidar com a autenticação no servidor. É aceitável transferir informações da sessão para o usuário na forma de um cookie ou param de URL, mas o processamento real deve ser feito no servidor. Você está se abrindo para os principais riscos de outra forma.

Answer 5

Use um cookie se quiser salvá -lo entre as visitas do navegador. Será armazenado na máquina do cliente.

Use uma sessão se desejar salvá -la por uma duração mais curta. Será armazenado no servidor da web.

Answer 6

Se você quisesse criar algo que nunca viajasse pela Internet, basicamente teria que fazer tudo isso no JavaScript.

Primeiro, crie um código que inicie algo como o Google Gears. Use o banco de dados no Google Gears para armazenar a chave.

Em seguida, no restante das páginas, tenha um JavaScript que verifique a chave no banco de dados do Google Gear. Se a chave não for válida, exclua a chave, redirecione o usuário e faça com que faça login novamente.

Answer 7

Os cookies são a maneira de fazer isso, mas você não armazena nenhuma senha em um cookie, é (quase) um pedido ;-).

Você pode usar a sessão para armazenar informações entre o carregamento da página no lado do servidor.http://fr.php.net/manual/en/book.session.php

Answer 8

Além do que Bryan diz, se você pode usar a especificação HTML 5, poderá aproveitar o armazenamento local.

http://ajaxian.com/archives/webkit-does-html5-lient-side-database-storage

Answer 9

Eu vejo problemas com sua abordagem. A primeira carga do JavaScript inicial pode ser farejada, portanto, o algoritmo de sal não está protegido do hacker. Então o ID também é "público". Ou seja, parece que você tem o próximo esquema (por favor me corrija se eu estiver errado):

password + SHA1 => hashed password
hashed password + (ID from server) + (salt from server) => mega hashed password

Eu realmente tenho um problema para ver por que a "mega hashed senha" é mais segura do que hashed.