>>> Miles Sabin <[EMAIL PROTECTED]> 10/14/99 4:04:10 PM >>>
>It's also totally insecure ... I hope noone is going to
>rely on it for anything even faintly critical.
Not so. See further down...
>> The only problem with this is how to ensure:
>> 1. that the applet gets sent
>> 2. that the applet is initialised with the key to
>> the cipher text properly
>> and also:
>> 3. how to deal with stuff that must come FROM the
>> client encrypted,
>These are the least of your problems. What's to prevent
>an eavsedropper stealing both your page, *and* your
>applet? The applet is, in effect, your decryption key,
>so it would be *extremely* unwise to send it over an
>insecure channel.
Nope... you have the JS set the key in the applet on the client
side.
The key never travels across the wire.
The way I use it is by having a unique username-key relationship that
is understood on the server.
The user enters their username and their key and their password.
The key encrypts the password, the username and password are
transferred to server, the servlet can then gaurantee that the user is
who they say they are (because the deciphered password should match
what I've got in the password database for that user). I can decipher
the password because I have a one to one match keys to usernames.
Break that.
There is a way actually, an interveening device could alter the
applet as it heads towards the user. This would be very hard though
and could probably be stopped by some simple Java Security checks.
>Cheers,
Enlightened?
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
