The Old Joel on Software Forum: Part 3 (of 5) - Encryption of Passwords

Encryption of Passwords - what are the options?

Hi:

I am newly undertaking, as a bit player, a project for encrypting our passwords - we are mainly a Solaris/Oracle environment.

We use a number of encryption classes - MD5, CryptoUtil etc.

The extrenal applications that authenticate will bve VPN, SAP R3, CrownPeak CM tool and an exchange server.

There are some enryptions that would be more practical than others in this environment. Has anyone some pointers on where to go for a good start-point on lessons learned on implementations like this with respect to encryption?

There seems to be tremendous potential for possible errors - I hope to do as much advance research as possible.

Ram Dass
Thursday, January 22, 2004

>We use a number of encryption classes - MD5...
Technically MD5 doesn't encrypt. It's more a hashing function as you can't decrypt the output:-)

SC
Thursday, January 22, 2004

What do you actually need to do with the passwords once they are encrypted?

If you just want the user to enter it and then store it in a database so you can supply it to the VPNs and other applications then I assume you could use any encryption method you want to store it in the database, and then decrypt it before passing it to the VPN etc.

We do it this way (for our application - i.e. store usernames and passwords in the users table encrypted) - except we NEVER decrypt the password, i.e. there is no decryption code in our program, when authenticating a user we encrypt the PW they entered and compare that to the encrypted PW in the DB. We just use a class (in Visual FoxPro in our case) that makes use of the standard MS Crypto API.

But to me it seems you want to encrypt passwords before passing it directly to the VPN, I would have thought any external app would need to recieve a decrypted password for authentication - if this is what you are trying to do, I would say your best bet is to encrypt the actual communications links between you and the VPN using SSL or whatever - otherwise you would just be wasting your time encrypting the passwords?

Chris Ormerod
Thursday, January 22, 2004

I personally like the benefits of using a hash like MD5 for security. It prevents people that have good intentions from accidentally invading someone's privacy in being able to look up or decrypt the password.

(Quick summary if you're not aware how it works)
Hash password, store result in database. To confirm, rehash entered password, compare to known value. If password is lost, confirm identity, set value in database to a hash of a known value, send the person the known value, and require them to change it.

Elephant
Thursday, January 22, 2004

A useful tweak on the "store hashed value in database rather than password" is to use a "salted hash".

The basic idea is that you don't hash just the password, you hash password + salt, where the "salt" is a random string. You store the hashed result and the salt.

To authenticate, you get the password from the user, look up the salt in the database, calculate hash( password + salt) and compare what's in the database.

This prevents a problem: if two users have the same password, then they'll have the same hash value. Adding the salt guarantees that everyone will have a different hash in the DB.

Chris Tavares
Thursday, January 22, 2004

what are you trying to do?
create a keychain?
authenticate users with a password?
both are different--you can use a hash for authentication, but for keychains you need the password and thus are potentially creating a central database of all your users passwords (read: target).
thus explaining why NTLM (and Kerberos?) have delegation concepts, and why schemes like Passport exist.

mb
Thursday, January 22, 2004

Using the username as the "salt" is also quite effective.

T. Norman
Thursday, January 22, 2004

Only if the username is unchangeable (or you store the "salt" username separately from the real username, at which point you're back to just having a random salt equivalent).

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, January 22, 2004

The username can be changed without having to separately store a "salted" username. Just ask for the old username and password when changing the username (or changing the password).

T. Norman
Thursday, January 22, 2004

And you don't even have to ask for the username, since you'd know it once the user logged in.

T. Norman
Thursday, January 22, 2004

First of all, in my experiance, a CS degree does not teach you how to be a good professional developer. You learn all of the academic background of computing, learn some useful techniques, etc but not about what makes a productive programmer in a business setting.

I don't have a CS degree, but did take some CS classes when I was in school. I work with/manage a bunch of programmers who have a range of education from CS, Math, and Engineering PHDs to basically self taught. There isn't a strong correlation as to who's better.

If you want to get out of your rut, try going to university and getting a degree in something other than CS and take some CS classes on the side. Or, just keep with your job and take some CS theory classes at night and read the suggested books.

Good luck

pdq
Friday, January 23, 2004

Thank you for all your help.

I will post progress reports on JoS as we progress through the decision phases.

Ram Dass
Friday, January 23, 2004