12
My doubt started when I decided to re-examine the method I was using to get the user’s password and store it in the database. After reading that one, that one and that one questions here on the network, in addition to many others on other networks, such as that one and that one, some doubts arose me.
We have old methods, but excellent to the present day, of generating a hash to store in BD. We also have some, which were considered great, but are already falling into disuse (or at least in concept) due to safety, as is the case of md5
and family sha
.
We also have new methods where, as far as I read, it seems to be the strongest candidate to be used for the generation of hash, even more recommended than the bcrypt
or PBKDF2
, which is the case with password_*
in the PHP >= 5.5
.
Some requirements I have observed as ideal in the elaboration of hash would be:
- All hash generated must be created next to a salt;
- All salt generated must be unique per customer;
- The function should be slow, to hinder the attack of brute force;
With that in mind, as far as I can consider this thought to be correct and start using only the method password_*
? It would fit the ideal requirements for generating hash?
What struck me was also the simplicity in terms of code to use password_*
, because with few lines of code we can get the expected result, example:
//Gerar um hash
$salt = $resultadoSalt; //resultado de uma função para obter o salt único
$options = [
'cost' => 14,
'salt' => $salt
];
$hash = password_hash($password, PASSWORD_BCRYPT, $options);
//Validar um hash
if (!password_verify($password, $hash)) return false;
In this case, store the function result password_hash
in the Database would be enough? Ex.: $2y$14$5e7b5f0ef3cccfac9b902uR4sHJTlTYv3RYt3ApP7PvyTXHmdhN7e
or some other process would be recommended?
Remembering that any other considerations on the subject are welcome!
In fact, in PHP 7 it is considered obsolete to inform the
salt
, this is automatically generated by the function. So, I believe that inform thesalt
is not the best option. The criteria you observed is correct, just add "one": usage time and popularity. bcrypt is old (before 2000). There is scrypt, unless mistaken, it was published in 2009. Precisely because it is recent it is not yet "so accepted", it is necessary that it resists for more time alive. But in answer to the question, I believe it would be enough. I think the function was created so, easy, to see if they stop using MD5. :P– Inkeliz
@Inkeliz The problem of using the salt generated by the function is precisely this, being random, that is, when the client is logged in, salt will not be the same generated when he created the account, so the hash would be different, right? At least from the test I took and what I read, that was the conclusion.
– celsomtrindade
When to use the
password_verify
will not compare one hash to another, nor should you insert salt. So salt should be random, even to be unique. The PHP manual does not recommend using a custom salt or re-invent the wheel to generate salt, "It is strongly Recommended that you do not generate your Own salt for this Function.". Try removing thesalt
and it will work the same way, even if it generates a hash that is totally different from each other. How it works I’m waiting for someone to answer it too. : D– Inkeliz
@Inkeliz, I’m gonna run some tests that way, so I don’t remember those details. What confused me was just this phrase "don’t re-invent the wheel, there are already many options available". But there are so many, and so many that say they are good, that I don’t really know what the good is! hahaha
– celsomtrindade
Just to answer the question of
salt
. Thesalt
is already stored in the password itself, or a chunk of it. For example: if thesalt
for of1234567891234567891234
, the password ofabc
will be$2y$14$123456789123456789123uqefxzc/iUTZnhJmbDgxEKiWGTixIZu6
. Note that the second$
indicates thecost
(14), then just salt: being visibly123456789123456789123
, only lacked the4
, the last number, which then I know where it went (but change the last number of thesalt
does not change the hash, so...). Anyway, salt is already embedded in the hash, so it can perform the comparison.– Inkeliz
@Inkeliz Yes, this logic I had even understood. However, as salt does not appear fully, I imagined that there was some other however.. But now I have been able to look at this question differently. And I assume that this has no impact on the security issue, correct?
– celsomtrindade
Why don’t you draw the line at every hour? Thus avoids brute force enough, if the hacker exceeds this limit will have to wait "years", to get back to.
– Gonçalo
@Gonçalo this is a good complement to the application, but it doesn’t solve the hash problem, see the other posts linked in the question itself. The salt and hash are not only to prevent access to the application, but to prevent access to credentials even if the attacker gets a copy of the DB passwords.
– Bacco
In fact the current question seems more like a request for confirmation of understanding, or even a debate about what has already been posted, than a new doubt. When so, I recommend leaving comments in the original posts, which we can try to complement, explain, improve etc.
– Bacco
@Bacchus I understood his answer more as a theoretical and explanatory basis between the methods and characteristics of each. While my question is more about use/security coupled with the simplicity of code thatpassword_* has been offering when compared to other methods, such as
md5
(generating asalt
"manual"), the veryPBKDF2
or other techniques.– celsomtrindade
Do not understand as a theoretical basis only, it is to use in practice even :) But do not just stick to my answer, which is an adaptation of an excellent existing post of the OS in English. There’s a lot of other important information in other answers there, which are pretty interesting. I suggest rereading trying to understand what problems each technique tries to solve, which is easier to see what are the problems of a md5 (collision and speed, for example). But if you can describe more accurately the parts you don’t understand, as I said, we can try to help.
– Bacco
As for the PHP password, for you to know if it is "good enough", it is a matter of understanding the past concepts. I’d say for normal use, with bcrypt, it’s enough for most uses. But only you can really know the value of the information being protected and the risks involved. Security does not have "ready solution" for all cases. Just understanding, and updating. It will always be a race between defender and attacker, balanced by the value of information. Remembering that this value may include a third party password that should not, but can be reused.
– Bacco
@Bacco yes yes, I fully understand your point of view. Maybe this "vision" that you are trying to give me is not so clear yet because of my lack of experience (because I am more of front end - design), but I will reconsider these last topics that you pointed out and reread more calmly! = D
– celsomtrindade