If the data is not too sensitive, it is pretty easy. If the data is sensitive, then you will want to at least encrypt the stuff going back and forth. My opinion on passwords: Never store the actual password, store the CRC of the password. The applet should not send the password over the web, it should send the CRC. If the CRC's match, then the password is good.
I don't want to get into an argument, but surely sending the CRC and comparing it on the server is actually less secure than using the password. A CRC is a numeric value, and thus limited in range, (say a Java int limited to 32 bits, or even a long at 64 bits), whereas an arbitrary length character string has far more possibilities, and thus a lesser chance of being found by random or sequential selection. For real security, you need an algorithmic approach such as the server sending a challenge, and the applet replying with the correct answer, which depends on the challenge.
What about encryption, or is that what you are refering to Frank?
Joined: Jan 07, 1999
Well, encryption by itself doesn't help much for password authentication. An attacker can copy the encrypted password as easily as the unencrypted one. The challenge-response mechanism, on the other hand works like this: 1. The server asks a question 2. The client answers it 3. The server checks the answer agains the question. As a very simple example, consider a system where both the client and the server each have a copy of an array of 1000 randomly generated numbers, created when the system was compiled. When the client trys to log in, the server chooses a random index from 1 to 1000 and asks the client for the number at that position in the "code book". Simply intercepting the datastream between the client and the server is not enough to be able to spoof the login process. The answer won't be the same next time. This approach can be made as complex as you like, and include things like the date, time or IP address of the client in the reply for extra security.