if the app is accessed through a single URL and loadbalanced / proxied, you
still only need the one SSL cert: it's the URL, not the IP address, that
counts.

-----Original Message-----
From: Sam Newman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 3:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Encrypting password


Currently the login is handled by a servlet (actually an RMI client) which
cimmunicates with a remote database to get the info. I just don't want to
send the users password unencrypted over the web. I'm really looking to
avoid using SSL if possible. We want to avoid having to get certificates, as
the app could potentially be on allot of machines rather than one central
point (the whole system is VERY distributed). We already use secure (1024)
encrypted pipes elsewhere, so i may look at using applets as Samson
suggested.

thanks for the info

sam
----- Original Message -----
From: GOMEZ Henri <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 3:18 PM
Subject: RE: Encrypting password


> >The problem with this approach is that, without a
> >challenge-response, having the MD5 digest of the password is
> >as good as having the password.
>
> What is the challenge-response ?
>
> The MD5/SHA1 digest is good over secure line.
>
> 1) Store in DB or LDAP only the MD5 digest of user password
> 2) Use SSL from browser to httpd/tomcat server.
> 3) Send on the SSL link, user log and md5 password and check
>    in servlet/JSP that for that user the password (md5) and
>    the DB/LDAP content are the same.
>
>
>
> >Donnie
> >
> >>>> [EMAIL PROTECTED] 03/12/01 10:05AM >>>
> >You could also use a little javascript to send
> >password coded with md5 and verify in servlet the
> >password for this user via md5 is equal to the
> >password string you received :
> >
> >ie: http://pajhome.org.uk/crypt/md5/index.html
> >
> >
> >
> >>-----Original Message-----
> >>From: Samson, Lyndon [IT] [mailto:[EMAIL PROTECTED]]
> >>Sent: Monday, March 12, 2001 3:44 PM
> >>To: '[EMAIL PROTECTED]'
> >>Subject: RE: Encrypting password
> >>
> >>
> >>You could write a custom applet, which could use any
> >>encryption algorithm
> >>you prefer.
> >>
> >>-----Original Message-----
> >>From: Sam Newman [mailto:[EMAIL PROTECTED]]
> >>Sent: Monday, March 12, 2001 2:35 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: Encrypting password
> >>
> >>
> >>Am I right in saying the only method for encrypting user
> >>entered data (e.g
> >>from client desktopn browser to web server) is SSL?
> >>
> >>sam
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, email: [EMAIL PROTECTED]
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, email: [EMAIL PROTECTED]
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to