Reversible encryption is not usually used for authentication. Instead, a crypt or MD5 digest of the password is stored. On login, the offered password is digested and compared to the stored hash.

That improves password security by making it impossible for anyone (including root) to read a password from the host. Sites which observe this elementary precaution cannot mail you a password reminder, only a new password - which should be changed on first use.

After Compline,
Zaxo

Encrypt when you first get (and have verified) the password and store. When the user enters the password, encrypt it, retrieve the encrypted copy from the store and compare the encrypted versions. Never decrypt.

If you want to have a 'send me my password' link. Generate a new password, encrypt it and overwrite their old (encrypted) one in the store and send them the newly generated one.

You never store the unencrypted passwords, so even if the store is compromised, it doesn't open you up, because they only have the encrypted and you ask for the unencrypted.

By never needing to decrypt, you can use a one-way encryption, so noone can ever find the decryptions code. Of course the encryption code is probably around somewhere, but if the encryption is any good, they still have to do a brute force encrypt every word in the dictionary until they get a match for a password, before they can exploit it, and that ought to take a long time unless they get lucky.

Another precaution is to have a bunch encrypted passwords in the file derived from passwords that you wouldn't allow when your validating new passwords--things like 'password', 'secret', 'root' & 'admin'.

When people are logging in, don't validate, just encrypt it and see if it matches, then check the unencrypted against your 'no no' list. If you ever get a successful login using a word on your no no list, you know you've been Tango'd compromised. It would probably never happen, but for the effort involved, it's a simple sanity check.

When a user chooses a password it is encrypted and stored. Then when they log in, what they type is encrypted again and compared with the stored version.

More knowledgeable monks please feel free to correct me if i'm wrong....

Cheers!

Update: I see Zaxo beat me by 'that much' to an explanation that is far better than mine. Oh well.

1. Encrypt it on the client side, for instance by using SSL.
2. Decrypt it on the server side.
3. Encrypt it again (usually using a different method, say crypt). Store the encrypted password, and don't use a reversable encryption process.
4. Don't send unencrypted passwords by email.

Abigail

You really want to use a module for this:

• Crypt::PasswdMD5 -- Puts the password through an MD5sum. Be warned that MD5 makes a lot of people nervous and probably shouldn't be used for new things.
• Apache::Htpasswd -- Compatible with Apache's .htpasswd format, though you don't have to be using Apache to use it.

If you're not familer with the term "salt", just know that it is a random value stored in plaintext with the password. It's there to make brute-force cracking on the password file a lot harder. (A recent program claiming that it could break most WinNT/2k/XP passwords in a few minutes works because Microsoft didn't use salt).

If you're not familer with cryptography in general, I recommend reading through the Cryptogram (external link) archives before using it a lot. Just slapping a module from the Crypt:: namespace isn't enough--you have to use it correctly. As hard as making a secure cipher is, it turns out that it's the easy part. At least creating ciphers has thousands of years of mathmatics behind it so that its security can be anyalized mathmatically. Even a code with theoretically perfect security (like the one-time pad) can be utterly broken if you don't manage your keys correctly, or you use a bad random number generator, or you leave a copy of the plaintext laying around, or . . .

----
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

Why shouldn't MD5 be used for new things? I know there's the problem of possible collisions, but I was under the impression that the real-world chances of that happening were very small. If not MD5, then what hashing function would you recommend?

Sorry it took so long to reply--I've been on vacation for a week.

MD5 had its compression function broken. This doesn't hurt its security, but it does mean that one of MD5's design goals is destroyed. IIRC, this also stops MD5 from being used in one of those cute tricks where you use a cryptographic hash as a block cipher (which isn't common, but could be useful in countries where normal encryption is outlawed).

I haven't read too deeply on the subject, but I know there are other problems with potential collisions that do effect security.

MD5 isn't dead, but it is bleeding pretty bad. It is intresting to note that both MD5 and SHA1 are very similar to MD4, but SHA1 has subtle changes that make various attacks against MD4 and MD5 impossible.

In short, use SHA1 if you can. It's not just that has a larger hash value, but its an all-round tougher algorithm.

----
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 think he's overstating "a lot of people". Many seem to preferr SH1 over MD5, but typically this is because of the key length (160bit instead of 128bit) - not because of weaknesses in the algorithm itself. Most people wouldn't try to brute force either. The primary weakness in passwords is almost ALWAYS the fault of those who pick them. Take a look at how 'John the Ripper' works, and you see interesting trends in passwords.

It becomes easy when you make your employees use a VPN to access yor exchange server directly and have a smarthost mail server (sendmail, qmail, whatever that is set up secure) on a dmz that actualy is exposed to the internet at large. To the ISP the VPN traffic does not look like SMTP. You lose complexity and gain encrypted comunications.

Also if you are just using imap/pop other systems (besides echange) can be set up with the imap/pop auth allowing inbound imap/pop connections.

-Waswas

We are currently setting up CIPE to do just that. It seems to be working pretty well but we are still testing it. I was really curious though, if there was a viable solution in its current setup. Thanks for the reply.