There are some things missing here. What we are really talking about
is a digest authentication scheme like that which is used in the
HTTP/1.1 specification (RFC2617). But since (I presume) we are talking
about form based authentication, a number of pieces of RFC 2617 don't
apply.
Let's discuss those points that do, however. There are three
components of the authentication scheme that are applicable even to
form based, namely the username, realm, and userpassword. Realm is
just a fancy word for the scope of the authorization. The concept of
realm is no different here than in HTTP Basic Authentication.
Your servlet/jsp page requires access to an MD5 (or SHA) hash comprised
of the username, realm, and plaintext password. This forms the basic
credential. The form of that data is h(username:realm:userpassword).
The h() notation merely refers to that fact that it's the hash of that
3 element, colon separated string, and not the actual plaintext.
When you generate the login form, you must include the plaintext realm
for which the login applies, plus a challenge. The challenge should be
a random generated ASCII string. I don't recollect the RFC specifying
a particular length -- I've tended to make mine 64 characters long.
You can either restrict the contents of the string to a-zA-Z0-9, escape
it as required, of base64 encode it (if you do the latter, don't forget
to undo the mechanism is order to reclaim the challenge as originally
generated.
You javascript at the browser will now have access to all the same
elements the servlet/jsp has. You now want to make two separate
MD5/SHA passes.
You first need to generate the same h(username:realm:userpassword) as
is stored on the server. You then need to append the challenge string
so that you end up with: h(h(username:realm:userpassword):challenge).
Since the servlet/jsp on the server end already has access to the first
component (i.e., h(username:realm:userpassword) ), and since your
servlet/jsp generated the challenge, it's a simple process to compute
h(h(username:realm:userpassword):challenge) at the server end and
compare it to the browser response.
As far as whether to do MD5 or SHA, it really depends on the ease of
computing those hashes at the browser. There are javascript MD5
algorithms available on the web, but I'm not aware of any SHA (you can
always write you're own). You could also do it inside an applet, but
if you're not otherwise using applets and you can't also be assured
that folks are permitting applets and/or are using the plugin, you may
find yourself in a world of hurt. Javascript, therefore, is probably
the better solution, but ultimately only you know your client base.
-- Rob
--On Monday, March 12, 2001 04:18:06 PM +0100 GOMEZ Henri
<[EMAIL PROTECTED]> wrote:
>> 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]
>
_ _ _ _ _ _ _ _ _ _
/\_\_\_\_\ /\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_/ /\/_/
/\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
