Is anyone creating more complicated (practical) password hashing in PHP 7 than the example below?
function encrypt($password) {
$hashed = password_hash($password, PASSWORD_ARGON2I, [‘memory_cost’ => 2048, ‘time_cost’ => 4, ‘threads’ => 3]);
return $hashed;
}
Apparently password_hash() does a great salt itself. I haven’t found anything that suggests you need much more for hashing.
If you are doing something different, please show example code.
Hi there,
The given example is pretty much the best practice for modern day password hashing. Also, see: Crackstation hashing security blogpost
But, I do want to ask, are you asking this to increase the security of an application or just a general question? Because if you’re looking to increase the security of an applicant through more advanced password hashing, you’re tackling only one of the smallest parts of security. Just food for thought. 
A more practical approach?
I don’t like complicated. I just use PASSWORD_DEFAULT with password_needs_rehash so I’m at all times following the recommended hash routine.
Oh, nice link to Crackstation.
My increase in security was due to an upgrade to PHP 7.2. But the reason I started this thread was to discover if I needed to do a bit more. I’m not entirely sure if it’s needed or not. Are you doing more to protect passwords?
Thanks for the reply back, I see your point and it is a great moment to rethink your user security at times like these.
As of this moment I don’t do a lot different from your approach, my code is usually wrapped around a few things due to framework choices but when you reverse it and remove some additional optimization shit, it is pretty much the same.
As for further security, I tend to focus more on my forms (injection and Man in the Middle prevention), the information I’m returning directly back to users and guests (think: errors, general info messages etc.), And adding permission checks, and password/two factor authentication double checks on specific pages like user settings.
As for database stored information, I generally tend to encrypt all the personal information of my users. ( DoB’s, names, general address info etc. ) I’ve written my own encrypt / decrypt Laravel package using bcrypt for dynamic encryption ( to avoid max bit length issues when statically encrypting ). It takes a bit longer (generally 1.7 sec per request) but I prefer the small wait over possibly compromising user data.
I do have to note that I work for a company that works for mortgage advisors and banks so I tend to work with highly personal data, so I’m mostly required by law to add these “extreme measures” on small applications
Hope it helps you with your security audit 
I recently read this page about hashing. It talked about using a “SALT” and I have been using them for years. It does add some extra level of security. I bet this comment will start a long discussion on the subject!
Also, it adds in a “COST” for the overhead of the hashing. This makes it slightly harder for hackers to get in.
Might be worth a read…
Password Hashing…
( From IBM’s Developer’s pages and aimed at PHP5.5 )
Ernie: If you use PHPs password lib (password_hash etc) then you’re already using salts. If you aren’t really sure what you’re doing it’s adviced to keep the default setup as pretty competent people have decided what they should be
Yes, JimL… Just wanted him to understand it further. Wasn’t going to explain it all since it was in an article already.
Unless you are a security specialist this is a really bad idea.
@benanamen : Unless you are a security specialist this is a really bad idea.
Thanks for the concern, this is 100% true. The package is simply encrypting and decrypting the data using existing and proven methods with some added flavour for our own software. ( Dynamic Bcrypt encryption in this exact case, as we encrypt large amounts of text. )
The only reason this became a package is for 3rd party developers that use our software to communicate with personal-data sensitive endpoints in our API.
This sounds strange. Bcrypt isn’t encryption so you shouldn’t be able to decrypt it. Because of the embedded salt, lookups for matching Bcrypt hashes should also be off the question.