Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Ecrypting passwords

by hardburn (Abbot)
on Oct 06, 2003 at 13:55 UTC ( #296937=note: print w/replies, xml ) Need Help??

in reply to Ecrypting passwords

Avoid MD5 for anything new. Its made people in the cryptographic community so nervous that they actually suggest using something from the NSA (namely, SHA1) instead of MD5. Its not outright broken, but it doesn't look too good.

If you can, use SHA1 instead. You'll need to grab Digest::SHA1 off CPAN.

The way I normally do it is to have a table containing usernames and a seperate related table (1-to-1 relationship) containing the encrypted password for that user. This is because it is more difficult (though not impossible) to carry out a cross-table SQL attack. The schema looks something like this:


When encoded in hex, SHA1 produces a string 40 characters long. You can change the size of the passwd field for other encodings if you want.

Encoding the password looks something like this (in psudo-code):

plaintex_passwd = The plaintext password from the user hex() = Hex encoding function SHA1() = SHA1 digest function salt = Random 32-bit value (doesn't need to be a cryptographically s +ecure random num) + = String concat hex( SHA1( salt + SHA1( salt + plaintext_passwd ) ) )

IIRC, MySQL's PASSWORD() function uses MD5, so avoid it.

IMHO, an often overlooked part of cryptography is that you need to code your application so that you can change crypto algorithms easily. In this case, that means you need to code so that you can replace SHA1 with something else if tommarow it turns out that SHA1 is totally broken. The Digest module is good for this purpose.

Update: Fixed typo.

I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Ecrypting passwords
by neilwatson (Priest) on Nov 04, 2003 at 20:19 UTC
    Something I don't understand. Perhaps someone could enlighten me?

    If we encrypt the password via SHA1 and store it in database how will we compare it at login? Doesn't SHA1 encrypt the same string into a random hash each time? So if we encrypt the user given password and compare it to the stored password aren't the hashes going to be different?

    If we somehow unencrypt the hashes how is that done? I don't see that mentioned in the SHA1 docs.

    Sorry for being dense.

    Neil Watson

      If you put the exact same data into SHA1 (or any other reasonable hashing algorithm), the exact same hash value will come out. It's only when you have different data (even as small as one bit) that a cryptographic hash will give a different output. Non-cryptographic hashing algorithms (such as the one used by Perl's hash data structure) may produce collisions for different data, which usually need to be handled by the program in question.

      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        I am not experiencing that :(. Consider this code example:
        # encrypts password using # SHA-1 algorithm my $sha1 = Digest::SHA1->new; # reset algorithm $sha1->hexdigest; # encrypt $salt = 1658087940; my $secret = $sha1->sha1_hex($passwd . $salt);

        Run in a shell script the hash is the same each time the salt and password are the same (as you said). However, when inserted into a web page (HTML::Mason but, on the same machine) the hash is different each time.

        Neil Watson

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://296937]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2021-04-18 06:46 GMT
Find Nodes?
    Voting Booth?

    No recent polls found