PHP 5.4.36 Released

Gerando hash seguro de senha

Esta seção explica as razões por trás do uso de funções de hash para proteger senhas, bem como fazê-lo de forma eficaz.

Por que eu deveria gerar hash das senhas fornecidas pelos usuários da minha aplicação?

Gerar hash de senha é uma das considerações mais básicas de segurança que deve ser feita ao projetar qualquer aplicativo que aceita senhas dos usuários. Sem gerar hash, todas as senhas armazenadas em seu banco de dados da aplicação podem ser roubadas, e então imediatamente usada para comprometer não só a sua aplicação, mas também as contas de seus usuários em outros serviços, se eles não usarem senhas únicas.

Aplicando um algoritmo de hash para a senha de seus usuários antes de armazenar em seu banco de dados, dificulta um atacande determinar a senha original, enquanto ainda é possível de comparar o hash resultante para a senha original no futuro.

É importante observar, entretanto, que hash de senhas só protege de comprometer em seu armazenameto de dados, mas não necessariamente protege de serem interceptadas por um código malicioso injetado em sua própria aplicação.

Por que são comuns funções de hash tais como md5() e sha1() inadequados para senhas?

Algoritmos de hash como MD5, SHA1 e SHA256 são projetados para serem muito rápidos e eficientes. Com técnicas modernas e equipamento de informática, tornou-se trivial de "força bruta" a saída desses algoritmos, a fim de determinar a entrada original.

Por causa da rapidez com que um computador moderno pode "inverter" esses algoritmos de hash, muitos profissionais de segurança sugerem fortemente contra a sua utilização para hash da senha.

Como devo criptografar minhas senhas, se as funções hash comuns não são adequadas?

Quando gerar hash de senhas, as duas considerações mais importantes o custo do cálculo, e do salt. O algoritmo de hash computacionalmente mais caro, mais tempo vai demorar para saída de força bruta.

PHP 5.5 fornece uma API de hash de senha nativo que lida de forma segura tanto gerando hash e verificando senhas de forma segura. Há também » uma biblioteca de compatibilidade PHP puro disponivel para PHP 5.3.7 e posterior.

Outra opção é a função crypt(), que suporta vários algoritmos de hash em PHP 5.3 e posterior. Quando utilizar esta função, você tem a garantia de que o algoritmo que você selecionou está disponível, como PHP contém implementações nativas de cada algoritmo suportado, no caso de um ou mais não são suportados pelo seu sistema.

O algoritmo sugerido para usar ao gerar hash de senhas é Blowfish, que também é o padrão usado pela API de hash da senha, pois é significativamente mais caro computacionalmente que MD5 ou SHA1, enquanto continua a ser escalável.

Note que se você estiver usando crypt() para verificar uma senha, você terá que tomar cuidado para evitar ataques de tempo usando uma string de comparação de tempo constante. Nem operadores == e === do PHP nem strcmp() realizam comparações de seqüências de tempo constante. Como password_verify() vai fazer isso por você, você será fortemente incentivado a usar a API de hash de senha nativa sempre que possível.

O que é um salt?

Um salt de criptografia são dados que são aplicado durante o processo de hash, a fim de eliminar a possibilidade da saída ser analisada se numa lista de pares pre-calculadas de hashes e sua entrada, conhecida como uma tabela rainbow.

Em termos mais simples, um salt é um pouco de informação adicional, que faz com que seus hashes seja significativamente mais difícil de decifrar. Há uma série de serviços on-line que fornecem listas extensas de hashes pré-calculado, bem como a entrada original para os hashes. O uso de um salt faz com que seja improvável ou impossível encontrar o hash resultante em uma dessas listas.

password_hash() será criado um salt aleatório se não for fornecido, e isso geralmente é a abordagem mais fácil e mais segura.

Como faço para armazenar meus salts?

Ao usar password_hash() ou crypt(), o valor de retorno inclui salt como parte do hash gerado. Este valor deve ser armazenado na íntegra no seu banco de dados, uma vez que inclui informações sobre a função hash que foi usado e pode, então, ser dada diretamente para password_verify() ou crypt() ao verificar senhas.

O diagrama a seguir mostra o formato de um valor de retorno de crypt() ou password_hash(). Como você pode ver, eles são auto-suficientes, com todas as informações sobre o algoritmo e salt necessário para futura verificação da senha.


        Os componentes do valor retornado pelo password_hash e crypt: em
        ordem, o algoritmo escolhido, as opções do algoritmo, o salt utilizado,
        e o hash da senha.

add a note add a note

User Contributed Notes 6 notes

up
22
alf dot henrik at ascdevel dot com
9 months ago
I feel like I should comment some of the clams being posted as replies here.

For starters, speed IS an issue with MD5 in particular and also SHA1. I've written my own MD5 bruteforce application just for the fun of it, and using only my CPU I can easily check a hash against about 200mill. hash per second. The main reason for this speed is that you for most attempts can bypass 19 out of 64 steps in the algorithm. For longer input (> 16 characters) it won't apply, but I'm sure there's some ways around it.

If you search online you'll see people claiming to be able to check against billions of hashes per second using GPUs. I wouldn't be surprised if it's possible to reach 100 billion per second on a single computer alone these days, and it's only going to get worse. It would require a watt monster with 4 dual high-end GPUs or something, but still possible.

Here's why 100 billion per second is an issue:
Assume most passwords contain a selection of 96 characters. A password with 8 characters would then have 96^8 = 7,21389578984e+15 combinations.
With 100 billion per second it would then take 7,21389578984e+15 / 3600 = ~20 hours to figure out what it actually says. Keep in mind that you'll need to add the numbers for 1-7 characters as well. 20 hours is not a lot if you want to target a single user.

So on essence:
There's a reason why newer hash algorithms are specifically designed not to be easily implemented on GPUs.

Oh, and I can see there's someone mentioning MD5 and rainbow tables. If you read the numbers here, I hope you realize how incredibly stupid and useless rainbow tables have become in terms of MD5. Unless the input to MD5 is really huge, you're just not going to be able to compete with GPUs here. By the time a storage media is able to produce far beyond 3TB/s, the CPUs and GPUs will have reached much higher speeds.

As for SHA1, my belief is that it's about a third slower than MD5. I can't verify this myself, but it seems to be the case judging the numbers presented for MD5 and SHA1. The issue with speeds is basically very much the same here as well.

The moral here:
Please do as told. Don't every use MD5 and SHA1 for hasing passwords ever again. We all know passwords aren't going to be that long for most people, and that's a major disadvantage. Adding long salts will help for sure, but unless you want to add some hundred bytes of salt, there's going to be fast bruteforce applications out there ready to reverse engineer your passwords or your users' passwords.
up
9
fluffy at beesbuzz dot biz
2 years ago
The security issue with simple hashing (md5 et al) isn't really the speed, so much as the fact that it's idempotent; two different people with the same password will have the same hash, and so if one person's hash is brute-forced, the other one will as well.  This facilitates rainbow attacks.  Simply slowing the hash down isn't a very useful tactic for improving security.  It doesn't matter how slow and cumbersome your hash algorithm is - as soon as someone has a weak password that's in a dictionary, EVERYONE with that weak password is vulnerable.

Also, hash algorithms such as md5 are for the purpose of generating a digest and checking if two things are probably the same as each other; they are not intended to be impossible to generate a collision for.  Even if an underlying password itself requires a lot of brute forcing to determine, that doesn't mean it will be impossible to find some other bit pattern that generates the same hash in a trivial amount of time.

As such: please, please, PLEASE only use salted hashes for password storage.  There is no reason to implement your own salted hash mechanism, either, as crypt() already does an excellent job of this.
up
2
loveun1x at yahooc dot om
1 year ago
The section "Why are common hashing functions such as md5() and sha1() unsuitable for passwords?" is completely wrong. No one says MD5 and SHA-1 aren't suitable for password hashing due to their speed. (MD5 is broken for digital signatures but not yet for password hashing, but not because it is fast.) A single round of them is unsuitable, but that is not a problem with the underlying algorithms themselves.

Always use a salt, preferably a big (e.g. at least 16 characters) salt. Always run through multiple rounds of of the hashing. Most implementations today use several tens of thousands or hundreds of thousands of rounds, for example 7-zip's encrypted format uses 262,144 rounds of SHA-256.
up
4
sgbeal at googlemail dot com
2 years ago
sha1 in conjunction with one or more salt values need not be as insecure as the above makes it out to be. e.g. the Fossil SCM creates an sha1 password hash based on a user's clear-text password combined with the user's name and a shared secret known only to the specific source repository for which the user is set up.
up
-15
user at wample dot com
9 months ago
password hashing may be better with the use of "phpass"
up
-38
owlstead
1 year ago
Clearly you should by now use PBKDF2, bcrypt or scrypt to store secure "hashes" of passwords. Unfortunately the PHP crypto implementations and documentation keeps propagating insecure protocols and algorithms. Isn't there a single PHP programmer that could clean up the cryptographic functions and libraries?
To Top