Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Must we authenticate login forms (using SSL?)?

Subject: RE: Must we authenticate login forms (using SSL?)?
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 form 
encryption 
that provides the same mechanism that the public/private 
key entails.

Check out my just published release at 
http://www.nshb.net/secure-form-post-with-javascript-without-ssl

erm... 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
 

<Prev in Thread] Current Thread [Next in Thread>