Criptografia - MD5 [RESOLVIDO]

paulocamboim
(usa Slackware)

Enviado em 19/01/2009 - 11:40h

Pessoal,
Estou com uma grande dúvida sobre a utilização de criptografia com php. Caso eu use a função md5:

md5('teste'); Isso vai gerar um hash que em qualquer site eu posso descobrir qual o texto a partir do hash.

Entao eu estava lendo que vc pode "salt" o texto para dificultar por exemplo:
$chave = 'qq_coisa_aqui_12345';
md5('teste'.$chave);

Mas como esse codigo acima vai evitar que descubram do mesmo jeito o texto criptografado.

Obrigado.

Paulo

elgio
(usa OpenSuSE)

Enviado em 23/01/2009 - 18:57h

Escrevi um artigo sobre isto (procura no meu perfil, senhas no Linux)

O salt deve ser ALEATORIO e grande, senão não ajuda muito. Coloca ai uns 15 cars de salt e aleatório. O salt é armazenado junto com o hash, pois precisa dele.

Exemplos (usando o md5sum do shell)

Senha teste (user pedro)
1ca308df6cdb0a8bf40d59be2a17eac1

Ai tu armazena no arquivo:
pedro:1ca308df6cdb0a8bf40d59be2a17eac1

ok?

Bom, é certo que a palavra teste já está em BDs de hashes, pois existe apenas UM ÚNICO hash para a palavra teste. Agora se tu escolhe aleatoriamente a sequencia de salt "01Abcd564%" (10 cars) e gera o hash para 01Abcd564%teste terá:

echo 01Abcd564%teste |md5sum
12c145b93ba9e7b2f8e1284978c3dbde

E tu DEVES armazenar no arquivo:
pedro:01Abcd564%:12c145b93ba9e7b2f8e1284978c3dbde

Sim, o salt É ARMAZENADO!
para quando o usuário pedro digitar a sua senha, tu le no arquivo o salt para concatenar a senha que ele digitou.

A diferença é que é IMPOSSÍVEL alguém compilar todos os possíveis hashes md5 para todos os salt para uma única palavra!

logo, IMUNE ao ataque rainbow tables.

mas ainda é fraco pelo ataque de força bruta, pois teste é muito fácil.

MD5 é seguro ainda se bem usado:
- senhas de no mínimo 8 cars, misturando letras e números par evitar força bruta e dicionário.
- salts ALEATÓRIOS de no mínimo SEIS cars para evitar Raibow tables.

Se tu te interessa pelo assunto, leia meu artigo. Leia o email que linkei no artigo e na minha página tem códigos fontes em C para gerar aleatoriamente os salt numbers.

elgio
(usa OpenSuSE)

Enviado em 23/01/2009 - 19:02h

Veja o código "Codigo C para gerar hash DES e MD5 Unix". Aproveite a etapa de geração de salts randomicos.
http://gravatai.ulbra.tche.br/~elgio/disciplinas/?DISC=outras&MAT=VOL

Meu artigo sobre Senhas:
http://www.vivaolinux.com.br/artigo/Armazenamento-de-senhas-no-Linux/

Detalhes sobre como são as senhas no Linux mesmo:
http://gravatai.ulbra.tche.br/~elgio/senhas.html

paulocamboim
(usa Slackware)

Enviado em 26/01/2009 - 11:28h

Elgio
Valeu pela resposta!

Li seu artigo e gostei muito. Muitas duvidas foram esclarecidas. Agora surgiu outra hehehe, nao sei se eu nao entendi direito alguma parte mas aqui vai.

Tipo ... Queria implementar usando "random salt". Agora a duvida que ficou foi:

Como voce disse:
$1$F1CsIATU$HUmNHU5PSCRmRA.EYHYy0.

$1$ = MD5
F1CsIATU = salt number usado
HUmNHU5PSCRmRA.EYHYy0. = hash da palavra teste com o salt number.

A minha duvida eh de como eu iria autenticar esse usuario? ja que o salt poderia ser qualquer um.

Mesmo eu armazenando o salt como eu poderia fazer isso ? ja que o salt que foi armazeado tb foi o hash. Se eu armazenar o salt em 'plain-text' nada disso iria fazer sentindo neh?

pois é isso, valeu pela atenção.

Paulo

removido
(usa Nenhuma)

Enviado em 26/01/2009 - 11:57h

"md5('teste'); Isso vai gerar um hash que em qualquer site eu posso descobrir qual o texto a partir do hash"

Até o momento não é possível descobrir o texto original através do hash MD5. Pode ser usado como criptografia de senhas sem problemas...

elgio
(usa OpenSuSE)

Enviado em 26/01/2009 - 14:04h

virtualboy: infelizmente sua observação acima não é mais verdade. Sem salt numbers (SEM SALT NUMBERS!!!), praticamente qualquer senha de até 8 caracteres pode ser quebrada em sites da Internet que usam a técnica de Raibown tables. Ao invés de sair tentando descobrir qual a palavra cujo hash é XXX, estes site já possuem um enorme banco de dados pre-compilado com todas as possíveis combinações de letras e números (isto leva tempo, mas os sites estão processando a anos e dizem que já tem tabelas completas até 8 cars, independente da mistura de números e letras).

O uso do salt number simplesmente BOICOTA o uso desta técnica, pois para a mesma palavra "teste" existem milhões de hashes diferentes e não teria como os sites compilarem todas. De qualquer maneira, vale a máxima de que para senhas fáceis, não importa o método, a senha é FRACA.

Respondendo a outra pergunta, sobre como lidar com salt numbers, vamos a um exemplo.

Pedro é um usuário legítimo e vai criar sua senha pela primeira vez. O sistema armazena os dados de um usuário em um arquivo simples, com campos serarados por dois pontos (o que acarreta que dois pontos não pode ser um car válido para salt).

a) Pedro cadastra sua senha.
O login de Pedro é pedro e ele digita sua senha para ser cadastrada (estou usando o md5sum do shell, pois assim qualquer um pode seguir estes passos)

senha: Ab#k,l56 (pedro é um usuário consciênte e gera senhas difíceis!)

O sistema sortei um salt absolutamente aleatório para pedro: 89Jkjm,jjY8j

E o método de geração do hash é bastante simples: md5("salt""senha") (ambos concatenados)

$ echo "89Jkjm,jjY8jAb#k,l56"|md5sum
e1cd6a07671f4ec720ec02387ddbce90

O sistema armazena no arquivo o login, o salt e o hash:
pedro:89Jkjm,jjY8j:e1cd6a07671f4ec720ec02387ddbce90

Senha gerada e hash armazenado.

b) Pedro tenta logar-se
login: pedro
senha: Ab#k,l56 (ele acerta a senha)

O sistema ve no arquivo a linha correspondente ao pedro e obtem o salt: 89Jkjm,jjY8j
O sistema recalcula o hash com o salt armazenado e a SUPOSTA senha correta de pedro:

$ echo "89Jkjm,jjY8jAb#k,l56"|md5sum

Se o hash md5 calculado for IGUAL ao armazenado, pedro acertou a senha, caso contrário ele erro.

Este método de hash+salt é ótimo porque a senha nunca é armazenada. Se a senha de pedro for boa e o número de cars de salt satisfatório, NÃO TEM COMO DESCOBRIR a senha de pedro. Nem mesmo o root/admin (ele pode sobrescrever a senha a qualquer momento, mas não descobrir ela).

paulocamboim
(usa Slackware)

Enviado em 26/01/2009 - 15:08h

Elgio,

Então no caso de um atacante ter acesso ao seu sistema e conseguir acesso ao banco de dados ele teria como descobrir a senha não? Ja que no banco de dados teriamos a string de "salt" para aquele password. tipo:

$pass = "minha_senha";
$salt = "123minha_string_completa456";
hash = xxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
ou seja, eu iria saber que o hash foi originado por: $pass.$salt


Ai eu li no seu artigo:

"[...] banco de dados (alguém pode pensar que o BD tem maior segurança porque exige autenticação. Ora, em um ataque supõe-se que o atacante invadiu a máquina e teve plenas condições de ler os fontes de teu PHP para ver a senha do Banco de Dados!). [..]"

Então poderia por brute force tentar qualquer senha concatenado com $salt ?


Obrigado pela atenção =)

Paulo

vsmoraes
(usa Arch Linux)

Enviado em 26/01/2009 - 15:26h

Desculpem me intrometer assim, mas achei muito pertinente o assunto e não pude evitar de comentar.

Em relação à "hashs" (MD4, MD5, SHA-1, etc.) não há como 'descobrir' (vamos colocar assim) de outra forma se não o brute-force. Por isso, "hashs", não são considerados criptografia, até por que sua criação não teve este intuito. Os "hashs" são gerados através de vários cálculos complexos de forma que não haja meios de calcular de forma inversa, chegando aos valores iniciais. Este é o motivo de não haver uma "decifragem" dos "hashs".

Mesmo afirmando que não há caminho inverso nos cálculos, em muitos destes já foram descobertos falhas que torna seu uso não muito seguro, o algorítimo MD5 é um destes. Contudo, o tempo gasto com processamento para chegar à um resultado satisfatório é completamente impraticável, por isso surgiram as "Rainbow tables", já citadas.

Todo "hash" tem um princípio simples de que, quando qualquer bit seja alterado, todo o "hash" é alterado de uma forma estupidamente diferente. Isso justifica o uso dos "salts".
Mesmo que o atacante consiga o "salt" usado em determinada senha, ele não teria sucesso ao procurar tais combinações nas "Rainbow tables", já desconsiderando a possibilidade de um ataque de "brute-force" que, segundo cálculos, pode demorar anos.

elgio
(usa OpenSuSE)

Enviado em 26/01/2009 - 15:26h

Veja!

O pior método é armazenar a senha em arquivo ou BD. Rouba-se e já era.
No caso o que é armazenado é o hash, não a senha.

Se for roubado, o atacante conhecerá o hash e o salt number, mas terá que descobrir a senha. Ou seja, qual a string que juntamente com o salt (que ele conhece) resulta naquele hash que ele tem?

Isto exige ataque do dicionário (pegará senhas fáceis) ou força bruta (INVIÁVEL para senhas realmente complexas).

Sem salt numbers, o atacante ainda tem o ataque de Rainbow tables que é muito mais fácil!

"Então poderia por brute force tentar qualquer senha concatenado com $salt ?"

SEMPRE!
Força bruta não tem defesa. Sempre o atacante poderá tentar ela. O desafio é tornar o sucesso tão remoto que inviabiliza (com md5, mesmo como o melhor computador, levaria-se Décadas processando em força bruta).

Se a senha for de 8 cars, apenas letras e numeros (a-zA-Z0-9) tem-se um total de 62^8 (cada cars pode ser um dentre 62 possíveis e são 8 cars). Isto dá um total de 218.340.105.584.896 possíveis senhas. Um sistema que consiga testar 10 milhões por segundo levaria 218.340.105 segundos, ou 2527 dias processando. Considerando que ninguém é tão azarado (de acertar na última) assim como também não é tão sortudo e acertar na primeira, é correto considerar que se quebrará na metade das tentativas. Isto ainda deixa 1263 dias (quase 3 anos e meio).

MAS ISTO FALANDO DE FORÇA BRUTA para uma senha de 8 cars!

O fato é que alguns sites já compilaram e armazenaram boa parte destes hashes de sorte que hoje é possível consultar esta base. Isto não pode ser confundido com força bruta!

Se usar uma senha de 8 cars e um salt number de 15 cars, a força bruta continua sendo o mesmo exposto acima. O salt NÃO MELHORA A FORÇA DO ALGORITIMO! Não o torna mais forte e menos imune a força bruta. Ele apenas inviabiliza o ataque por RT e faz com que dois usuários com a mesma senha não tenham os mesmos hashes.

Mesmo com salt numbers dois ataques ainda são possíveis (considerando a posse do arquivo de senhas pelo atacante):

a) Ataque do dicionário: quando o atacante tenta senhas fáceis, baseadas em login, nome, sobrenome, palavras do dicionário. É INCRÍVEL como este ataque pega 99% de senhas de usuários. Quem é o culpado? os usuários que insistem em colocar a data de aniversário como senha!

b) Ataque moderado de força bruta: neste se faz um força bruta moderado. No meu exemplo anterior, com senha de 8 cars, considerei que o usuário usou letras (MAI E MIN) e números. Mas raramente um usuário faz isto. Se for fazer um força bruta apenas com números (de 00000000 a 99999999) o ataque descobre com sucesso a senha em poucos minutos!

Claro, ainda tem o "pure brute force", considerando todas as possibilidades, mas isto é suicídio e ninguém em sá consciência tentaria este ataque (a menos que disponha de um mega cluster e possa usar ele anos e anos a fio!)

elgio
(usa OpenSuSE)

Enviado em 26/01/2009 - 15:31h

Vide a explicação do Vinícius!

É exatamente isto.
matematicamente não tem como reverter o MD5, mas isto não quer dizer que não possa ser quebrado.

paulocamboim
(usa Slackware)

Enviado em 26/01/2009 - 15:33h

Ahh ok então

Quando eu tava dizendo em guardar a "senha" no bd eu queria dizer armazenar o hash.
Obrigado ae pela paciência. Tirou todas as minhas dúvidas sobre isso! =)

T+ =)
Paulo

elgio
(usa OpenSuSE)

Enviado em 26/01/2009 - 15:33h

a propósito.

A conclusão é óbvia: toda a senha gerada em Windows é insegura, pois o Windows jamais usou salt numbers! Lampasswd (passado) é brincadeira de criança. NTpasswd vá lá, mas sem salt, é muito provável que todos os hashes em um universo de até 6 cars já estejam computados!