This is how, for example, APOP works. But since /etc/passwd only stores password hashes, it requires a separate database storing passwords in plaintext. This is fine if you don't need to use the passwords from /etc/passwd. The password hashes are generated using the crypt(3) library function, which provides 4096 different ways of hashing a given string. The only reason this is used is so that you can't "pre-hash" a list of words and then simply compare these to those passwords in /etc/passwd, which would make it easier to crack large password lists. When you talk about "salting a salt" and "encrypting two characters," I think you're extremely confused.

I think it's impossible to do what you're attempting, since there are only one-way functions involved. If all you have is a list of hashed passwords, and the client sends you hash(strcat(password,challenge)) then there's no way to verify that they match. But if you have the list of passwords, you can easily compute hash(strcat(password,challenge)) yourself.

You CAN do what you're trying to do using Public Key cryptography. Server generates a key pair K=(public,private) and sends the public key to the client. The client encypts the password with the public key and sends that to the server. The server deciphers this using the private key, recovering the password. Then the server applies the hash function and compares to /etc/passwd or whatever.

Just storing plaintext passwords on the server is probably the most direct thing to do and can be made as secure as general system security. You can use MD5 for the hash function, it's a good and standard thing. Otherwise there's the traditional Unix crypt() which is based on DES.

That's not secure, because an evesdropper would get both the one time pad, and the OTP-encrypted password-equivalent.

That is the big problem with one-time-pads: it's just as difficult to deal with the OTP as it is the original plaintext.

Don't bother trying implement the encryption *algorithm* yourself, unless you want the exercise; it's hard to do right, and hard to do efficiently; and there are many good libraries already extant.

I advocate the APOP-style keep-plaintext-on-server, send challenge, reply with hash(password + challenge). It's easy to implement, secure, and functional.

It is an issue, because the eavesdropper can get exactly whatever it is you're trying to protect!

In this case, that's the hashed password, which has become "password equivalent". Someone could easily write a program to send the hashed password (instead of generating a password hash) and your system would be compromised. It amounts to "trusting the client" which is a big no-no.

sorry for using the wrong terms, and thanks MUCH for all the help with this. I hope it makes for a better system (actually, chances are nobody will try to hack this thing so nobody will run into the fact that I'm trying to do security "right and proper", but...) :)