Exactly the point! I didn't see SSL mentioned in the prior discussions, so I assumed
that it was just a digest of the password over http.
Answering the question "what is the 'challenge-response'", that is the standard
technique used to ensure that every digest/encryption of a shared secret key is unique
and unpredictable. For example, the server issues a challenge which consists of a
secure random number. The browser responds with an MD5 hash of that challenge plus the
shared secret key (plus typically some other chaff). If someone intercepts that
response, they can't reuse it as-is like they could if the hash was of just the shared
secret key.
Donnie
>>> [EMAIL PROTECTED] 03/12/01 10:20AM >>>
JMHO,
but I think the point is if you have ssl available, why send
a digest, and if you don't, then you are sending the md5 digest
in the clear where it can be sniffed.
Jin
> -----Original Message-----
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 12, 2001 10:18 AM
> To: [EMAIL PROTECTED]
> 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]
