use strict;
use Digest::SHA1;
my $plaintext="Test1ng";
#generate a two char salt...
my $salts= "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345
+6789./";
my $s1 = rand(64);
my $s2 = rand(64);
my $salt = substr($salts,$s1,1) . substr($salts,$s2,1);
my $sha1 = Digest::SHA1->new;
$sha1->add($salt.$plaintext);

# the enc pass is presented with the plaintext salt as the first two c
+hars.
my $encpass = $salt. $sha1->hexdigest;
print "$encpass\n";

This outputs:

kcc68a68507e8636a1a9a6badc059342b19a12c58e

And to test the password:

use strict;
use Digest::SHA1;
my $storedpass='kcc68a68507e8636a1a9a6badc059342b19a12c58e';
my $plaintext="Test1ng";
#pull salt from the saved password so you can compair...
my $salt = substr($storedpass,0,2) ;

my $sha1 = Digest::SHA1->new;
$sha1->add($salt.$plaintext);

# the enc pass is presented with the plain-text salt as the first two 
+chars.
my $encpass = $salt. $sha1->hexdigest;
print "if $encpass = $storedpass the password is correct...\n";

which outputs:

perl testpass.pl
if kcc68a68507e8636a1a9a6badc059342b19a12c58e = kcc68a68507e8636a1a9a6
+badc059342b19a12c58e the password is correct...
[download]

Okay, that looks pretty good. The main reason I wanted a premade module is that I've seen a lot of examples where people tried to impliment their own encryption/security schemes instead of going with something that's been proven and got burned by it. When it comes to something like cryptography that I don't fully understand, I'd prefer to use code written by someone that has a better understanding than myself.

Crypt::PasswdMD5 is, in practice, easy to use. The salt is prefixed to the the returned password hash, so you don't need to use a constant one. Just extract that substring from the stored hash and use it as salt for the offered password, then compare strings. When you first store a password hash, any random salt will do. The randommer, the better.

The purpose of salt is to make wordlist dictionarys impractically large.

It's fairly straightforward how to implement this yourself - check the hashed password against the database for an auth request, hash and store the password when creating a user or changing a password. What else did you need to know?

Adding salt does two things:

1) It makes it harder to brute force the password list.

2) If person A knows his password hashes to the same value as person B's -- some websites stupidly publish users that had the same password hash -- person A could login as person B using their own password without even knowing person B's password. Adding salt would create different hashes (even for the same password), eliminating this problem.

usually based on some input from the user record or the password itself

Salts are usually random. Ideally, each user has a different salt. They must definitely NOT be based on the password since the salt must be known. Basing it on the password would leak info about the password.

Crypt::PasswdMD5 creates a salt for you if you don't specify one, according to the documentation.

I'm not sure how salt really adds anything useful to the picture

Salt makes your passwords less vulnerable to dictionary attacks.

    use Crypt::PasswdMD5;

    $cryptedpassword = unix_md5_crypt($password, $salt);
[download]

Because there have been multiple documented attacks against MD5. You don't need the password if you can run out and come up with a new plaintext that ends up with the same digest.


-Waswas

Oh, I didn't mean that using the module would be too much trouble. In fact, it looked like the easiest thing to do. I was refering to how the module worked internally, it looks like there's some extra stuff that it does just so it can be compatible with Unix and Apache MD5-based crypt. That, and like I mentioned, it is just MD5.

Personally though, I'd work more on making sure the database is secure from prying eyes, rather than hashing stored passwords. Storing passwords as irreversable hashes means there's no way to retrieve the password if the password is forgotten, meaning in turn that you need a secondary verification system - which is always less secure and usually fairly easy to social engineer. If you ARE going to make passwords irreversable, make them short (no more than 3-4 alphanumeric characters), with lock-out of IP / user on failure to log in 3 times in a row. A short password is much easier to remember, and pretty much eliminates the need for a secondary verification system.

The weakest link is almost never site security, but rather human laziness and inability to remember things.

I think you miss the purpose of a salt trap door encrypted password. The goal for a salted password is to be any reproducible process which does not expose any information about the password and that changes the final digest value so that A: users with duplicate passwords are not apparent, and B to brute force a given plaintext against a database of passwords is takes N (computationally expensive) digest attempts where N is the number of usernames. The salt should be easily guessable, in fact most of the time it is plaintext. What you suggest in your opening paragraph is to create your own digest or encoder -- this is not good idea. LOTS of time and research goes into trap door encryption and digests to make sure that the they are secure -- there is good reason for this. MD5 for example had a ton of eyes looking at it over the years and is only recently broke. I do not know you personally Ted, but I would not bet money on the fact that you could produce a new un-bruteforcable (or even worse yet, un-flat-out-breakable) trap door encryption scheme. At best it would be OBFU. They are very hard to do well.

One (of many) reason almost all secure apps use trap door encryption for passwords is that it is not reversible. That is KEY. One such attack that this defeats is your system administrator, which has access to all of your accounts and passwords, knowing the passwords when he gets laid off next week. To reset or change your password other sources of information are used for verification such as your email address with a click back, or all the way up to physical request in person with multiple forms of ID. Having plain text stores of passwords totally blows the user:pass concept of proving identity. Just think of this: if your server is compromised, and you can determine the break in exploit and time table, with plain text passwords in your database you cant roll back to the pre-exploit time and patch the issue. you have to have everyone on the system reset their password.


-Waswas

There is more than a few chinks -- MD5 is broke, its getting worse day by day.

look here (offsite:rub.de) for an article that explains the current publicly announced state of things. I as this gets more eyes on it, it will get even worse. MD5 digests should be considered almost as insecure as mad XOR magic. =)

Update: just wanted to add that SHA-1 has some of the same weaknesses as MD5, but as of yet they have not been able to break it like MD5. If you are really worried you can goto something like Digest::SHA256 for a digest, but it may not be worth it yet.


-Waswas

No, not at all. I may not know too much about the math behind hashing functions, but I know enough to know that I shouldn't even try to make my own for real world use! :-)

Incidently, I fail to see how any security method is going to save you if the person with root gets pissed off. He can social engineer people; he can redirect himself a copy of their user names and passwords on login; he can scan data streams and memory; etc. All he needs is a few logins to make your entire database unsafe, unless you know exactly which ones he has. Face it, you're screwed. The only thing you can prevent is him knowing everyone's password in one easy step, but why would that matter when he has root? He controls everything.

EDIT: I suppose if you know who logged in when and also when it was he inserted the redirect, you could identify which users he had the login info for and reset just their passwords. To prevent this, he'd also have to edit the logs before every site backup, which I admit would add a level of complexity to things. Still, anyone with half a brain would most likely have no trouble doing this.

All I can say is that there is very good reason that unix password files have been trap door encrypted for decades. One of the foundational principles in security is that given enough time and want any system can be broken. This does not mean that you give up on the details. You have a few doors with locks on them at your house, what is the point when you have very breakable windows right next to them? Thats what I read in your response.

You Said: Just merge the user name and password and salt in such a way that the hash is unique for every user name and password pair, and completely unguessable through dictionary attack or brute force

Which is one of the things in your post that made me realize you did not have your eye on the prize. Salt guess-ability is not a factor, they do their job while being totally known and visible. in fact you could just inc 01 .. N for salt on each new username and be done --all that matters really is that they are different per password. All your suggestion does in this post is to try to obfu salt into the password/hash -- this buys you nothing.

Later on you say: Personally though, I'd work more on making sure the database is secure from prying eyes, rather than hashing stored passwords. Storing passwords as irreversible hashes means there's no way to retrieve the password if the password is forgotten, meaning in turn that you need a secondary verification system - which is always less secure and usually fairly easy to social engineer. If you ARE going to make passwords irreversible, make them short (no more than 3-4 alphanumeric characters), with lock-out of IP / user on failure to log in 3 times in a row. A short password is much easier to remember, and pretty much eliminates the need for a secondary verification system.

which I see so many issues with I cant really spend the time going into it in detail. All I will say is that the second level password reset systems are as secure as they are designed to be -- while your posting account on perlmonks may be easy to get reset, your cert and pass at a DOD installation may require physical request with ID. It is all in the design and risk assessment of the particular site -- You have to remember at the end of the day user:pass systems are there to verify identity. If anyone on your system can freely grab user:pass info -- they can't be used to verify identity.




-Waswas