Scott Stirling wrote:
> So I guess the only potential use of MD5 by itself here, because it is one
> way, would be to encrypt the password (and why not the username too--that
> way any snoopers wouldn't know which was the password and which was the
> username) and then check that the result of the MD5 encryption matched the
> MD5 of the password for the appropriate username on the other side.
        I'm sorry, you must think I'm quite a curmudgeon now but this isn't
right either. Consider this: How would you know on the other side what
the appropriate username was?  The user on the other side just tossed it
down the MD5 rathole. ;-) I visualize this giant bit grinder grinding
your user into a fine particulate matter. ;-) More importantly, if you
think about it, all you have done is change the 'secret' thing you check
on the other side to MD5(<password>) instead of <password>, that's
really no different from checking <password> itself. All you have done
is made the real password, that is the thing you send to the other side
to demonstrate your authenticity, MD5(<password>).  That is sent in the
clear.  Anyone could just use that exact same bit pattern and get you to
believe he was the claimant.

In order to do this securely you must encrypt with a key known only
between you and the server and you must encrypt the following: username,
password, and some non-repeatable foo called a nonce.   This is so that
an attacker can't just replay the eavesdropped encrypted login
transmission to get you to let them in. If you look at the spec for SSL
you will see that there is quite a bit of protocol dance that happens
before you send your password  and credit card number to Amazon.com.
Https is just http over a secure tcp/ip connection provided by SSL. SSL
essentially allows you, the customer, to send a random key for a
symmetric encryption algorithm (RC4 usually) securely to Amazon by
encoding it with Amazon's public key. In this way only Amazon can
decrypt it. You know it is Amazon's public key because they send you a
X.509 certificate signed by one of the signers (e.g. Verisign) whose
certificates come with Netscape (or MS Explorer if you prefer to finance
Bill's Pleasure Palace in Seattle.) ;-)

> BTW, I thought that, even if inefficient, the compiling of the applet on the
> fly with a built in, unique key was a neat idea.
        What's to stop an attacker from eavesdropping on your applet as it is
passed along to the browser?  Anyone who runs that applet is you or at
least will appear to be you.


--
Take a walk on the wild side: http://www.metronet.com/~gardner/

There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
                                The Grateful Dead ("Ripple")

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.html

Reply via email to