Manter-se conetado cookies+phpass

[Micilini Roll 49]

Seguinte pessoa quando alguem se cadastra no site a senha do usuario é criptografada no banco de dados ultilizando phpass!

 

Quando a pessoa entra no site ela se loga pra entrar,o sistema pega a senha digitada e pega a senha vinda do banco e ultiliza o phpass para verificar se estao corretas,se estiver correta ele cria uma cookie para manter o usuario logado durante 30 dias,so que neste cookie ele insere a mesma senha criptografada que esta no banco ou seja:

 

Senha que esta no banco : KfcG32b6

Senha que esta no cookie: KfcG32b6

 

Isso nao esta meio estranho nao? Apesar de que eu defini meus cookies para http only! Mas mesmo assim nao me sinto seguro! Eu acho que o forum.imasters ultiliza a mesma tecnica pois eu ja me loguei e sai varias vezes e os cookies de usuario e senha continuam os mesmos!!!

 

Pra min o certo seria antes de criar o cookie pegar a senha do banco e hasheala novamente e inserir no cookie,fazendo assim toda vez que o usuario se loga-se ele iria ver cookies com senhas diferentes!

 

Ou estou pensando tudo errado?

[mangakah 217]

TL;DR

 

Se um atacante conseguir se apropriar deste cookie, ele não conseguirá fazer login com o hash, no entanto, ele pode facilmente recriar os cookies de um usuário logado em outra máquina e assim conseguir acesso a conta deste usuário. Você está usando [inline]httpOnly[/inline], o que ao menos evita que o cookie seja roubado via CSRF ou XSS, mas se a conexão não for segura (isso é, 100% segura, como todos os resources passados via HTTPS), e o usuário estiver acessando em uma rede insegura, as requisições dele, incluindo o cabeçalho HTTP [inline]Cookie[/inline] podem ser interceptadas e o cookie roubado. Já se estiver usando SSL e o cookie estiver com a flag [inline]Secure[/inline], o navegador só irá transmiti-lo em conexões seguras, o que garante certa segurança, só ficando vulnerável mesmo a um ataque avançado, como MITM.

 

De qualquer forma, realmente é um tanto desconfortável...

 

Então vou lhe apresentar as melhores práticas para se implementar esse recurso:

 

Primeiramente, a conexão precisa ser HTTPS para todas as requisições, não apenas para as páginas, mas também para css, js, imagens, etc.

 

O cookie deve ser [inline]httpOnly[/inline] e [inline]Secure[/inline].

 

O valor do cookie dever conter [inline]nome de usuário + um separador + sequencia aleatória[/inline] (vamos chamar isso de "token"). Esse "token" deve ser armazenado no banco de dados, junto com o nome de usuário e a validade do acesso, em uma tabela separada. O separador pode ser qualquer caractere simbólico, como um hífen ou uma barra diagonal, por exemplo. A sequencia aleatória deve ter ao menos 128-bits (16 bytes), eis o PHP para gerar uma:

if (function_exists('openssl_random_pseudo_bytes')) {
    $token = openssl_random_pseudo_bytes(16);
    
} else {
    $token = "";
    for ($i = 0; $i != 16; ++$i) {
        $token .= chr(mt_rand(0, 255));
    }
}

$token_hex = bin2hex($token);

Quando um usuário não logado visitar a página e tiver o token, a presença desse token deve ser verificada no banco de dados e se for confirmada, o registro desse token deve ser excluído. O acesso, obviamente, é negado.

 

Quando um usuário logado visitar a página e com o token, e a autenticação for confirmada (incluindo validar a data de expiração do token), o acesso é permitido, o registro do token deve ser excluído e um token novo em folha deve ser criado e enviado tanto para o banco de dados quanto para o navagador/cookie.

 

Para certas funções, deve ser exigido a redigitação da senha, mesmo que o usuário esteja autenticado:

 

- Alterar senha

- Mudar endereço de email

- Acessar/editar dados pessoais

- Fazer compras

- ...e outras funções da aplicação que forem consideradas sensíveis.

 

Essa "receita" foi apresentada pela primeira vez por Charles Miller e creio que seja uma especie de consenso, quase um padrão para login persistente.

 

 

Alguma dúvida?

[Micilini Roll 49]

Sim tenho algumas duvidas sim! então vamos lá por partes,a primeira coisa a se fazer e que eu ja estava planejando e pegar um certificado SSL (rapidssl),encontrado neste site aqui:

 

https://www.rapidssl.com.br/certificado-digital-ssl/geotrust-true-business-id.php

 

Pois bem no meu programinha eu defini 3 linhas de codigo para gerar um cookie do tipo HTTP ONLY,que é este abaixo:

 

ini_set("session.cookie_httponly", 1);
session_set_cookie_params(0, NULL, NULL, NULL, TRUE);
setcookie("map", $chave_acesso, time()+1296000, NULL, NULL, NULL, TRUE);//Duração de 15 dias com http only

 

Pergunta n°1 - Caso eu pegue o certificado ! como ficaria o comando para o cookie deixar de ser httponly e virar do tipo secure?

 

Ok prosseguindo voce mesmo disse que : devera ser criado no banco de dados uma tabela com o nome token que deverá armazenar:

 

 

nome de usuário + um separador + sequencia aleatória

 

a minha tabela do BD esta da seguinte forma:

 

 

USUARIOS

id - 32

login - micilini

senha - imasters

 

 

TOKENS

id- 45

id_usuario - 32

token - micilini<??>97h4578h9g8g

 

sendo - <??> um separador

 

Pergunta n°2 - esse token de usuario deve ser criado no momento que o usuario faz o cadastro certo? e quando ele se loga o sistema pega a senha do input transforma em um token e verifica se é o mesmo que esta no banco de dados! se for! ele estará logado e, é criado um novo token substituindo o antigo! correto?

 

Pergunta n°3 - Sendo :

 

 

 

$login_user(com base64) e $senha_user(com phpass)

 

Respectivamente o login e senha do usuario vindos do banco de dados como ficaria o token deles? usando este comando:

 

if (function_exists('openssl_random_pseudo_bytes')) {
    $token = openssl_random_pseudo_bytes(16);
    
} else {
    $token = "";
    for ($i = 0; $i != 16; ++$i) {
        $token .= chr(mt_rand(0, 255));
    }
}

$token_hex = bin2hex($token);

 

 

Sera que voce pode,responder as minhas perguntas acima?

[mangakah 217]

Vamos lá...

 

Resposta n° 1: Basta ver a documentação da função setcookie, o sexto parâmetro espera um valor booleano indicando se o cookie será definido como [inline]Secure[/inline] ou não (true ou false), já o sétimo parâmetro define se a flag [inline]httpOnly[/inline] será usada ou não (true ou false).

 

 

Resposta n° 2: Não, o token deve ser criado pela primeira vez quando o usuário fizer login e marcar "Lembrar de mim" e deve ser recriado o tempo todo, sempre que o usuário acessar a página. O segredo está justamente nisso, os tokens são descartáveis. A senha não deve estar presente no token, ele é apenas uma sequencia aleatória de caracteres que deve ser armazenada no banco de dados, enquanto o cookie deve ter o valor nome de usuário + separador + token. Para definir o valor do cookie, já que o nome de usuário (sem base64, tá? encoding não vale de nada) está em [inline]$login_user[/inline] e o separador é "<??>":

 

 

$valor = $login_user . "<??>" . $token_hex;

setcookie ( "login_token", $valor, 60*60*24*30 /* 30 dias */, "/", ".seu-site.com.br", true, true);

 

 

Resposta n° 3: Idem a n° 2.

 

 

Respondido?

[Micilini Roll 49]

estou quaseee lá! +2 pra voce! vamos lá deixa eu ver se eu entendi direito:

 

1-O usuario entrou no meu site e inseriu o nome de usuario e a senha no input e enviou o formulario

2-quando o formulario é enviado pega-se o nome e a senha e verifica se existe o login no banco de dados

3-se existir ele puxa a senha e verifica se a senha esta correta(usando o phpass) se estiver tudo correto

4- Se estiver tudo correto ele verifica se o checkbox "Lembrar de mim",esta clicado.

5-se estiver ele seta cookie:

 

 

1- cookie do login -> contem o login do usuario

2-cookie da senha -> senha do usuario em phpass

3-cookie do token -> contem o login do usuario + seprador + sequencia aleatoria

 

entao ele seta 3 cookies certo!

 

agora quando o usuario sai do website e entra denovo ele faz:

 

1-Veririca se existe este token cookies,pega o cookie verifica no banco de dados se é o mesmo que esta no banco de dados se for!

2-ele pega os 2 cookies de login e senha e verifica no banco de dado se estiver tudo ok!

3- ele pega o token gera um novo armazena no cookie e no banco de dados!

4- usuario logado!

 

seria isso? se nao for! voce pode ir me guiando que nao entendi muuuuito beem!

[mangakah 217]

entao ele seta 3 cookies certo!

Hein? Pra que três cookies?? O cookie da sessão e o cookie do login_token são suficientes. Não cosoloque a senha do usuário em cookies, mesmo que seja apenas o hash. O nome de login também é desnecessário por em cookies.

1-Veririca se existe este token cookies,pega o cookie verifica no banco de dados se é o mesmo que esta no banco de dados se for!

Tá meio confuso... não entendi nada... hehe...

 

2-ele pega os 2 cookies de login e senha e verifica no banco de dado se estiver tudo ok!

Não, apenas reinicie a sessão usando o magic cookie (o PHP já faz isso automaticamente através da função session_start).

 

Por padrão, a duração máxima de uma sessão no PHP não é 30 dias, mas apenas 1440 segundos. Para alterar isso você precisa editar a diretiva session.gc_maxlifetime no php.ini e defini-la com o número de segundos em 30 dias (60*60*24*30 = 2592000). O mesmo deve ser feito com [inline]session.cookie_lifetime[/inline]. Aproveite para definir [inline]session.cookie_secure[/inline] e [inline]session.cookie_httponly[/inline] com o valor "1" para tornar o magic cookie [inline]httpOnly[/inline] e [inline]Secure[/inline].

 

3- ele pega o token gera um novo armazena no cookie e no banco de dados!

Após confirmado que o token é válido, ele deve ser reciclado. O token antigo e já validado é excluído e um novo token novinho em folha é gerado e armazenado no banco de dados e o cookie já com o novo token enviado para o navegador.

 

Isso deve ocorrer a cada requisição, sempre que o usuário logado requisitar uma página/recurso.

 

4- usuario logado!

 

\o/

[Micilini Roll 49]

hm! entao podemos concluir que: nao existe mais os cookies de login e senha! somente existe o token! correto?

 

quando o usuario digita na tela de login e senha os seus dados! os dados sao enviados para o php aonde ira ser feita uma verificação se existem no banco de dados(se eles estao coretos)! correto?

 

se estiver tudo ok ele irá criar um cookie chamado token que irá conter:

 

 

login do usuario vinda do banco + um separador + sequencia aleatória

 

dai ele fica logado certo?

 

se ele sair e entrar novamente(fechar o navegador e entrar) ele verifica se o cookie chamado token existe!

se existir ele pega o valor do cookie e faz uma comparação com o token que existe no banco de dados,se eles forem iguais :

 

1-gera um novo token e com esse valor novo ele insere no cookie token e no banco de dados -> correto?

2-depois ele fica logado? correto?

 

 

seria isso?

estou achando meio estranho isso dai cara? sempre vi em lembrar de min! existir cookies de login e senha!....

 

1-e se ele pegar o cookie token e transferir para outra maquina? o usuario estará logado???

[mangakah 217]

E gera também uma variável de sessão para identificar o status atual do usuário, no caso, "logado".

 

Para identificar se o usuário está logado, basta verificar por exemplo:

function usuarioEstaLogado()
{
    return (isset($_SESSION['logado']) and $_SESSION['logado']);
}

/* logout ou deslogar -- excluir todos os dados da sessão no servidor e no navegador */
function deslogarUsuario()
{
    session_unset();
    session_destroy();
}

[Micilini Roll 49]

entendi! +1 pra vc! agora pra finalizarmos eu tenho 2 perguntas finais para marcar como resolvido!

 

1- Eu pegando o certificado SSL do tipo SSL/TLS GeoTrust True BusinessID , no que isso irá influenciar nas sessions/cookies criadas pelo meu site? supondo que a cookie id tenha valor igual a "Kfc32G8" com o certificado esse valor ainda será o mesmo?

 

2- Percebi que no facebook ele nao cria cookies e sessions como estamos acostumados a ver,envez disso apareçe a mensagem de:

 

 

 

Armazenamento Local

Tamanho 3,0kb

 

O que voce tem a me dizer sobre isso? acha seguro? como se faz?

[mangakah 217]

1 - Uma das funções do certificado SSL/TLS é certificar ao usuário que o site que ele está acessando é o verdadeiro e não uma fraude criada com o objetivo de roubar seus dados. Outra função é possibilitar a transmissão criptografada de dados entre o servidor e o navegador. O que inclui, é claro, todos os cabeçalhos HTTP (como [inline]Cookie[/inline], etc). Por esse motivo é que você precisa de um IP dedicado para usar SSL, pois toda a camada HTTP é criptografada e não é possível detectar o cabeçalho [inline]Host:[/inline] sem antes descriptografar o HTTP.

 

Infelizmente isso tem um custo na performance (o servidor precisará de tempo para criptografar o dados, o aperto de mãos TCP será mais longo pois a chaves criptográficas terão de ser trocadas entre o nav. e o serv. e o nav. precisará descriptografar para enfim renderizar tudo para o usuário), mas se você seguir todas as dicas das Yahoo! Performance Rules, isso será bastante mitigado.

 

 

2 - Alguns sites usam tipos diferentes de cookies (como Armazenamento local, Cookie em Flash e até colocar uma imagem no cache armazenando o nome-valor do cookie no nome do arquivo, exemplo "id-Kfc32G8.png") para tornar mais difícil para o usuário excluir o cookie e impedir o seu rastreamento. Talvez o Facebook, por razões de segurança, esteja sendo criativo na hora de gerar cookies...

 

Quanto a você usar isso, acho desnecessário e paranoico. O FB é compreensível, pois é um site muito atacado...

[Micilini Roll 49]

+1 pra voce! eu iria marcar como resolvido mas um amigo meu programador.me disse o seguinte!

 

 

Use token do mesmo metodo que o rapaz do forum disse mas somente ultilize um token sem reciclar a nao ser se voce queira que cada vez que o usuário acesse uma pagina diferente

 

no caso o usuario nao vai acessar uma pagina diferente! no caso assim que ele se loga ele visualiza o seu perfil completo e os produtos comprados

 

ele tambem disse pra fazer a tabela desta forma:

 

 

 

faz uma tabela assim

id | user_id | token | browser | expire

id: int auto increment

user_id: int id do usuário

token: valor que vai ser gerado na hora que o usuário fizer o login

browser: segundo teste ( evita alguem pegar um cookie no seu pc levar pro dele e continuar funcionando )

expire: timestamp

---------------------------------

primeira coisa verifica se existe o cookie token

se existir

ele verifica no banco de dados se tem algum token válido ( com mesmo user agent, e com timestamp superior ao atual )

se existir ele cria a session do usuário como se fosse um login normal

 

Bom mangakah voce tambem concorca com ele?

 

ele me disse que se eu pegar um ssl terei que fazer algumas alteraçõeszinhas no protocolo? quais alterações?

[mangakah 217]

Usar o UserAgentString (UAS) e associá-lo ao token aumenta a segurança, mas apenas em tese. Quando e se um atacante roubar os cabeçalhos HTTP do usuário, o UAS também será obtido e assim como ele (o atacante) irá definir os cookies exatamente como nas requisições do usuário logado (também irá definir o UAS igual ao deste usuário, assim como todos os outros cabeçalhos), e imitar perfeitamente o usuário autentico. Uma proteção usando o endereço IP é mais eficaz, pois não há como spoofar facilmente o endereço IP, pois ele está fora do HTTP. No entanto, muitos usuários hoje em ainda usam Endereços IP dinâmicos e essa proteção requer que IP seja estático.

 

A idéia de Miller para implementar o cookie do login persistente com segurança é relativamente segura e permite que o sistema detecte se e quando os cookies da sessão persistente forem comprometidos (sempre que o token do cookie não bater com o do banco de dados, então houve acesso não autorizado a conta), mas tem uma falha: se o último token/sessão gerado antes de o usuário fechar a janela/aba do navegador for roubado de alguma forma, o atacante poderá usar essas informações para obter acesso não autorizado a conta do usuário e o sistema só saberá da próxima vez que o usuário logar usando o token, agora já inválido.

 

Digamos que de algum modo o token seja roubado, junto com o cookie de sessão. Neste momento esses dados ainda são válidos e irão conceder acesso ao sistema. O dados são então enviados para um servidor externo onde o cracker poderá utilizá-los mais tarde. No entanto, esses dados já não serão mais válidos após a próxima requisição que o usuário fizer. Se o hacker quiser usá-los, terá de fazer uma requisição mais rapidamente do que o usuário, mas quando o usuário fizer a requisição, ele terá o mesmo token já usado pelo hacker e o seu sistema saberá que o acesso foi comprometido: hora de excluir todos os dados de sessão e exigir novamente o login. No entanto, se você não regenerar o token a cada requisição, o usuário poderia simplesmente logar com a opção "Lembrar de mim" ativa e acessar apenas uma página e fechar a janela do navegador, o token continuaria o mesmo. E se acontecer de este token ser interceptado, o cracker então terá tempo para acessar a conta e usar todas a funcionalidades possíveis que não requeiram redigitação de login, e o sistema só saberá disso na próxima vez que o usuário se logar novamente, o que pode levar dias ou até semanas.

 

Essa sugestão irá apenas tornar essa brecha maior, não é mesmo?

 

Por exemplo, se o usuário logar c/"Lembrar de mim" e acessar a página de "Acompanhamentos de Pedidos", para saber quando sua compra será entregue e registrar essa página nos Favoritos para ficar vendo de vez em quando, como a página será sempre a mesma, o token ficará estático e você não poderá saber se a conta foi comprometida.

 

Outra coisa: 30 dias de duração para a sessão um tempo é muito longo, melhor reduzir isso para uma semana ou duas no máximo...

 

Quanto a protocolo HTTPS, deve estar se referindo a direcionar todo o tráfego para o endereço HTTPS quando vier com HTTP.

 

É só colocar essa regra no .htaccess:

RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{HTTP_HOST}/$1

[Micilini Roll 49]

+1 pra voce topico mais do que resolvido! gostei bastante deste topico abortamos muuuitas coisas aqui! vou ate salvar aqui pra dar uma estudada melhor abraços muito obrigado mesmo! :yes: :yes: :yes: :yes: :yes:

uma coisinha boba! esse negocio de inserir no banco de dados é somente caso estiver a opção de lembrar de min certo? quando nao tem isso nao é necessario certo?