WebApp Sec mailing list archives
RE: Must we authenticate login forms (using SSL?)?
From: "Nathaniel S. H. Brown" <nshb () inimit com>
Date: Fri, 30 Sep 2005 01:17:29 -0700
On Thu, Sep 29, 2005 at 10:02:00PM -0700, Nathaniel S. H. Brown wrote:I have created a very unique, yet simple method of a formencryptionthat provides the same mechanism that the public/privatekey entails.Check out my just published release at http://www.nshb.net/secure-form-post-with-javascript-without-sslerm... this sounds like a plain old challenge-response mechanism. Or maybe I don't understand what you mean with "private key" and "public key" in your description.
Surprise, surprise. I had no idea about this RFC. The principles of RFC 2195 are exactly along the same lines as what I had implemented with the web post. However, it seems as though the downside is that the secret with my 1.0 as well as the RFC 2195 has to be available in plain text at both ends exclusively. Within the news post referenced above, I made alluded to the next iteration, which involves a more complex and secure authentication mechanism which does not require the password to be stored as plain text within the database, but will still be used on the client side as they need to manually acknowledge they know what it is to properly authenticate. Only on the client computer which creates the hash that is transmitted has access to the clear text password. To adjust the system would be quite simple. Based on a fixed username, when a user creates or changes their password, the password field associated to that user record would store a md5(username+password) in the database. Now, on the client side, it uses a precomputed hash as the password which combines the clear text password with the username combined to form the hash. So on the form, the insertHash JavaScript function would md5(username + md5(username + password) + timestamp + publicKey), and on the reverse, the server side script would compare against md5(post.username + database.password + post.timestamp + post.publickey). This would result in the password being stored in an encrypted, MD5 format within the database, and still transmit the private key (password) through the same fashion as CRAM-MD5 in a double layer MD5 hash ensuring its security. - Nathan -------------------------------------------------------------- Nathaniel S. H. Brown Toll Free 1.877.4.INIMIT Inimit Innovations Phone 604.724.6624 www.inimit.com Fax 604.444.9942
Current thread:
- Must we authenticate login forms (using SSL?)? Amir Herzberg (Sep 28)
- <Possible follow-ups>
- Re: Must we authenticate login forms (using SSL?)? info (Sep 29)
- Re: Must we authenticate login forms (using SSL?)? Antoine Martin (Sep 29)
- RE: Must we authenticate login forms (using SSL?)? Nathaniel S. H. Brown (Sep 29)
- Re: Must we authenticate login forms (using SSL?)? Peter Conrad (Sep 30)
- RE: Must we authenticate login forms (using SSL?)? Nathaniel S. H. Brown (Sep 30)
- Re: Must we authenticate login forms (using SSL?)? Rogan Dawes (Sep 30)
- Re: Must we authenticate login forms (using SSL?)? Antoine Martin (Sep 30)
- Re: Must we authenticate login forms (using SSL?)? Eoin Keary (Sep 30)
- Re: Must we authenticate login forms (using SSL?)? Antoine Martin (Sep 30)
- Re: Must we authenticate login forms (using SSL?)? Antoine Martin (Sep 29)