Originally Posted By Elias WagnerRegister Globals habilitado realmente é uma falha grave, inclusive as novas versões já vem desabilitada por default. Mas um código deve ser escrito independente das configurações do ambiente.

Se eu ainda escrevesse coisas em PHP, não sentiria dó de colocar um if(ini_get(’register_globals’)) die(’Desligue o register_globals seu admin burro’); no começo de cada arquivo .php

Agora eu discordo que é correto armazenar na mesma tabela junto com o hash, como eu disse um SQLi você pega o hash também

Ué, e qual o problema de pegar o hash e o salt com um SQL injection? Se a entropia do salt for boa (salt grande com boa aleatoricidade – que pode ser gerado com mcrypt por exemplo), a probabilidade de encontrar a senha precomputada é ínfima.

De maneira nenhuma concordo com o texto do seu artigo que diz que uma senha hardcoded é mais segura que uma senha encriptada com esquema de salt só porque ela está em um banco de dados e as estatísticas dizem que ataques SQL injection são mais encontrados que LFI e outros. É preciso utilizar criptografia decente sempre, seja onde a a senha estiver armazenada.

O mais adequado nestes casos é armazenar uma string no código ou em um arquivo no server, como o wordpress faz por exemplo. Óbvio que quem configura deve alterar a string padrão.

O que você quis dizer com isso? Armazenar um código em um arquivo no servidor e usar como salt? Se for isso, é extremamente inseguro. Um bom salt é um salt aleatório e totalmente independente para cada usuário diferente. Você poderia fazer hash do código do arquivo no servidor com o nome de usuário, mas mesmo assim não seria tão bom quanto um salt aleatório, pois todos os salts estão sendo tirados da mesma função e não são independentes entre si. Formalmente, teríamos uma grande quantidade de informação mútua entre salts diferentes.

Uma abordagem interessante seria armazenar um pre-salt no banco de dados junto com os demais dados do usuário e aplicar um hmac com uma senha contida em arquivo no servidor a esse pre-salt para gerar o salt verdadeiro.

Mas, sinceramente? Acho desnecessário tanta complicação se o salt usado for realmente bom, segundo os critérios que já citei. É mais provável a incidência de uma falha que permita acesso aos arquivos do servidor que a ocorrência de um salt repetido, dependendo do tamanho do salt.

Para quem acha que não é necessário validar o $_SERVER['SCRIPT_NAME'] segue aqui uma série de falhas explorando SCRIPT_NAME:

http://osvdb.org/show/osvdb/35502
http://drupal.org/node/324875
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-2431
http://www.milw0rm.com/exploits/3816
http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2010-02/msg00385.html

Muito gente acha que por ser recomendado o SCRIPT_NAME como opção mais segura para o PHP_SELF ele não deve ser validado e isto é incorreto.

Sobre o Salt, concordo que além de armazenar errado a entropia do Salt é baixa, previsível. Agora eu discordo que é correto armazenar na mesma tabela junto com o hash, como eu disse um SQLi você pega o hash também, por exemplo um SQLi como este: http://www.otavioribeiro.com/videos/MSSQL.html

O mais adequado nestes casos é armazenar uma string no código ou em um arquivo no server, como o wordpress faz por exemplo. Óbvio que quem configura deve alterar a string padrão.

Abs.

2) O código de salt do livro não apresenta a vulnerabilidade que você disse. É preciso sim armazenar o salt, todo mundo faz isso. Se você pegar o formato de senha encriptado do /etc/shadow por exemplo, ele vai ter primeiro um identificador do tipo de hash, depois o salt, e depois o hash, concatenados numa mesma string.

O problema no código do livro é outro. O salt é muito previsível, por ser baseado somente no tempo, e isso reduz a complexidade de um ataque por rainbow table, pois é necessário armazenar uma pequena faixa de salts. Se o salt tivesse uma boa aleatoriedade, o espaço de salts possíveis seria bem maior, aumentando a complexidade do ataque.

É claro que é sempre recomendável usar a função crypt do PHP para encriptar senhas, que aliás é capaz de usar hash baseado em blowfish como algoritmo, que é computacionalmente mais complexo que o hash sha1 que ele usou.