Estou implementando login com cookie no meu site. A maioria dos exemplos mostra login salvando apenas um atributo, por exemplo: email ou username. Entretanto percebo que essa pratica não é segura.
Se o meu sistema usar um cookie com o email do usuario, qualquer um que consiga modificar os cookies e saiba o email de outro usuário pode entrar na conta deste outro usuário.
Eu imagino a seguinte solução: usar mais de duas informações, tipo email e um id especifico que os usuarios não tem acesso publico.
Vocês tem alguma dica?
Que linguagem está usando?
Recomendação geral é usar sessions ao invés de cookies. Com isso, o estado de login é armazenado no servidor, não no cliente.
Sim, o uso de sessions envolve cookies, mas de uma forma diferente, menos insegura no geral.
Abraço.
Esstou usando php.
No php um cookie com o id da session é criado. Então pra acessar uma session de outro usuário é só modificar o cookie, certo?
Eu vejo que salvar um conjunto de “chaves” “impossíveis” de adivinhar seria mais seguro.
O que me vem à mente é: uma session salva um id em um cookie. Eu vejo que usar apenas o id da session é muito inseguro, é pouca informação pra validar com segurança o acesso aos dados no servidor.
Se eu usar um cookie diretamente e salvar em vez de um session id um conjunto de chaves(ids), ou seja, almentar a complexidade pra se forjar uma identificação.
Assim o “hacker” em vez de tentar adivinhar um id teria que adivinhar um conjunto de chaves bem mais complexo.
Se eu usar cookies dessa forma não seria mais seguro do que uma session, visto que eu estou apenas armazenando no cookie uma “session id” mais complexa.
Ps: Neste caso eu validaria informações no banco de dados.
Por mais complexa que seja esse conjunto de chaves, qualquer um que copiá-lo vai ganhar acesso à sessão. O fato é que quando se trata de segurança, por mais robusto que seja, um único mecanismo não é garantia de segurança. Na prática, você precisa adotar um conjunto de medidas para tornar o seu aplicativo seguro. No caso de proteger a sessão, além de usar o session id no cookie, as informações sensíveis devem trafegar somente via HTTPS, que é um canal criptografado. Outras diretrizes sobre segurança de sessão você pode encontrar aqui:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Properties
2 curtidas
É realmente perigoso fazer isso?
Os aplicativos da Web não devem misturar conteúdos criptografados e não criptografados (páginas HTML, imagens, CSS, arquivos Javascript, etc.) no mesmo host (ou mesmo domínio - veja o atributo de cookie “domínio”), como o pedido de qualquer objeto da Web por um não criptografado O canal pode revelar o ID da sessão.
As aplicações da Web, em geral, não devem oferecer conteúdo público não criptografado e conteúdo criptografado privado do mesmo host. Recomenda-se, em vez disso, usar dois hosts diferentes, como www.example.com sobre HTTP (não criptografado) para os conteúdos públicos e secure.example.com sobre HTTPS (criptografado) para conteúdo privado e sensível (onde as sessões existem). O antigo host só possui a porta TCP / 80 aberta, enquanto o posterior só possui a porta TCP / 443 aberta.
Se eu usar ssl no meu site vou ter que hospedar meus arquivos públicos em um host diferente?
Você pode colocar tudo como HTTPS. Quantos % das suas páginas não vão ter o cookie da session? Geralmente é irrelevante.
O session faz o mesmo que o cookie, mas de forma mais segura, poís os dados são salvos no servidor, o ideal é usar o login com session, mas se uma pessoa souber a id da sessão de outro usúario o cookie pode ser alterado para acessar.
Isso é chamado de roubo de sessão, para evitar isso em seu sistema o ideal é autenticar a sessão.
Você pode criar uma sessão diferente para cada usúario baseada no dispositivo do usúario ($_SERVER[‘HTTP_USER_AGENT’]) e pelo ip do usúario $_SERVER[‘REMOTE_ADDR’]), assim o usúario receberá um nome aleatorio para cada dispositivo, porém, tem uma falha, ele gera o mesmo nome para navegadores iguais no mesmo ip, ou baseado no mesmo navegador (tipo chrome e brave)
você pode ativar o httponly com a função session_set_cookie_params() para só poder ser manipulado com php.
Uma opção também é limitar o usúario no login se já tiver logado, pedindo confirmação ou em funções como alterar senha, mudar email, e etc. pedir uma confirmação da senha