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.

In reply to Replacing crypt() for password login via a digest - looking for stronger alternative by davebaker

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.