Yikes. Another 8-1/2 billion passwords have been leaked.

Have a login system for my web app that has a couple hundred users. To log in, a user enters a password, the submitted password is run through my authentication script that uses crypt() and compares the result to a hashed string (i.e., a digest) stored in a text file on my server (because crypt() had created that digest when the user first created his or her account). If the crypt() result is the same as the digest, we have a match, so c'mon in.

I've done enough research to see that such a system is a commonly-used one and has the advantage of not storing passwords in plain text, or even storing passwords at all, but that crypt() uses an encryption method that isn't very strong, at least nowadays.

So I'm thinking there is a security vulnerability in the event a black hat were to obtain the plain text file by breaking into my server. Then the black hat runs a rainbow table against each user's digest to find a password that produces that same string. Then the black hat takes the user's password to the user's bank web site and uses that same password to empty the account, because so many people use the same password for multiple websites. It's not so much the user's information on my website that's confidential, it's the empty-the-bank-account scenario that's troubling.

This issue always has been present with the use of a digest for purposes of password checking, but I'm thinking it becomes more of an issue when a couple billion more possible passwords are released that can be used to make the rainbow table more effective. Hence the risks of damages to my users has gone up, and my risk of getting sued has gone up. Do you agree?

So I'm thinking that it would be good to replace:

grant_website_access() if ( $password_entered_on_web_form eq crypt( $u
+ser_specific_hash_stored_in_text_file_on_server, $password_entered_on
+_web_form );
[download]

with

grant_website_access() if ( $password_entered_on_web_form eq something
+_stronger_than_crypt( $user_specific_hash_stored_in_text_file_on_serv
+er, $password_entered_on_web_form );
[download]

An article on Password Storage with Salted Hashes recommends Crypt::SaltedHash, with an example that seems to use the module's methods to achieve the same effect as my code. The author also recommends the use of SHA-512 with Crypt::SaltedHash rather than the considerably less secure SHA-1 or MD-5.

That's a good solution, it appears, to my perceived problem. I've checked threads back through 2012 here on PM and find none better, although Authen::Passphrase::BlowfishCrypt is intriguing.