So I know a lot of people are saying that you shouldn’t be creating your own password algorithm. The question is. If I use a built-in hash algorithm (such as hash) with a generated salt and a secret key. Will this be secure or will it be considered “creating a new algorithm”? The secret key will be a default string.
Since PHP has a password algorithm “built in” - why recreate the wheel? The built in password algorithm defaults to automatically using the best hashing algorithm available so even if you recreate the current functionality your password algorithm will be less secure than the built in one just as soon as a more secure hashing algorithm is introduced.
This uses the bcrypt algorithm and is widely considered the best way to store passwords. It’s also extremely simple to use.
@felgall Ok, that would mean that using the old “hash” algorithms would be bad right? Such as hash(“sha…”, $password); or md5(…); right?
I do know of course that the new algorithms have generated a random set of salt, but how would you be able to save that salted hash without the actual password into the database?
I have a user who signs up. So in order to validate that the user is a legitimate user instead of a bot. I generate a salt plus encrypt their password, then I send them an email verification in case they aren’t legit.
So by using the new algorithms, would the salt be saved in it’s own separate row or do I have to find a way to grab the salt from the hashed password or do I just use the generated hashed password and then compare it to see if the submitted password equals the same one from the database in which the legitimate user was using?
From the docs felgall linked to, there looks to be at least a clue as to what would be needed to be done
password_get_info — Returns information about the given hash password_hash — Creates a password hash password_needs_rehash — Checks if the given hash matches the given options password_verify — Verifies that a password matches a hash
@Mittineague Ok thanks. I’ll dig a little deeper into this. It was late in the morning when I replied and saw felgall’s post. I’ll make a test file to ensure that I’m doing it properly so that it doesn’t break my actual application.
Ok, now my biggest concern is that I can only do this for good practices. I just remembered that my hosting server only supports 5.2, 5.3, and 5.4. These new methods aren’t supported until 5.5. So I’m not sure if I will be able to implement them on my application. Rather, I guess for now I can study on this and make good use of it for better practices.
Edit: Ok, I think I found an alternative to use the new algorithms.
Had to download this library in order for the password_hash functions to work.
Try asking your host about the chances of them installing PHP version 5.5, btw I can’t think of any good reason why any host would support version 5.2 of PHP as it must be at least 4 or 5 years since that version was dropped
Ok, now I get it. The reason why I was seeing version 5.2 is because it was a previous version that they had. When I hovered my mouse over their question mark. The tooltip said that it is no longer supported on their end. I believe it’s just there for older applications because again, not everyone knows that those versions aren’t supported anymore.
I don’t really care though. At least they have a some what newer version, I’m happy to use it. Also, since I found the alternative way to use the password_hash functions, I’m happy as well.
I’m starting to get the hang of what it’s doing. The $2y is the algorithm part, the $10 is a default cost. The next line after $10 is the salt and after the period on every string, it’s a hashed password. It actually looks really simple to use. My only concern with password_hash is that since the cost makes it harder for someone to brute-force, what is the recommended or desired cost amount? I know for fact that it varies on your web server because I’ve read some where that it will use up a lot of CPU the higher the cost.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.