http://qs321.pair.com?node_id=961371


in reply to Password Encryption and Decryption

The thing about passwords is that you don't need to encrypt/decrypt them. Instead, all you need to do is store a cryptographic hash (also known as a "message digest") of the password. A hash cannot be 'decrypted' back to the original plain text but when you want to validate a login attempt, you just hash the supplied password and compare the result to the hash you have stored.

So for example if you want to accept the password "SmokeScreen" you might use the SHA1 hashing algorithm like this:

use Digest::SHA1 qw(sha1_hex); print sha1_hex("SmokeScreen"), "\n"; # Prints "95cb0bfd2977c761298d9624e4b4d4c72a39974a"

You could then store this 40 character string.

Later when someone attempts to log in they'll provide a plaintext password which you'll feed through the same sha1_hex function and if the result is the same 40 character string then they obviously supplied the right password.

A flaw with this plan is that if two people have the same password then they'll have the same 40 character hash (even on another server that uses the same hashing algorithm) - this could be useful information to an attacker.

A slightly more complex approach is to generate a few bytes of random "salt" when you initially hash the password. You'll add the salt bytes on the start of the plaintext before hashing and also on the start of the hash that you store. Then to validate a password you take the salt value from the stored hash and add it on the start of what the user provides. Because the salt bytes are random at the time the password is initially set, then two people with the same password will have different hash values.

Replies are listed 'Best First'.
Re^2: Password Encryption and Decryption
by slayedbylucifer (Scribe) on Mar 24, 2012 at 11:27 UTC
    thanks grantm. What you have suggested can get me my head spinning towards a whole new approach. I will play around in my spare time. That's a really good suggestion. thanks.
      You can check out Crypt::SaltedHash which implements this - http://search.cpan.org/~esskar/Crypt-SaltedHash-0.06/lib/Crypt/SaltedHash.pm
        I'm not sure that will work as he's trying to login to his AD account with this script. With this password so his script having a hash won't help him unless he's prepared to put the password in again and if he is then his script can't be automated. I'm faced with the same issue, we can't have plaintext passwords, but we want to automate the process of logging into the system to make sure it's avaialble for use. What is the preffered secure way of doing this? Even if we create a service account for this we can't reduce the priviledges enough to satisfy security so there has got to be a way that makes sense. What about something like this: The passwords are stored in an ecrypted file in another location other than the script. The script decrypts the file reads the password and then makes the appropriate checks. (Someone mentioned this earlier I know) The problem is how to do this securely so that the person cannot get the password from the script even if he just runs the code written in the script? When an admin user on a windows system wants to setup a service to run using a specific account they do punch the password into an window that stores the password somewhere for future use. This must be protected somehow no? Perhaps the method is in binary so it makes it a bit harder to thwart?