I think you are close, but are probably doing way too much work. First let's define a function HMAC_MD. HMAC is defined in RFC2104 and represents the current best current practice for using a hash to "sign" a data value. It takes:
result = hmac_md(key, value) You can use hmac with MD5, SHA1, SHA256... whatever. You will likely find libraries that already implement this in various languages. Below "SHA" means SHA1, SHA256, your choice. We'll assume each user has a password which is stored on the server. For a bit of extra security I would have the server store it as a SHA hash of the actual password.) For authentication you do a challenge response. Server Client nonce ====> <=== username, hmac_md(sha(password), nonce) The trick is to ensure that the nonce is not re-used. There are several ways to do this. One way is to store it in a table: crate table nonces ( nonce varchar(128), # Probably enough ts timestamp, used Boolean ) When the server gets the reply it looks up the user's "sha(password)" which is stored in the user account table. It then verifies that the nonce value is in the nonces table and that used is False. It then verifies that the timestamp is "fresh" (you can decide this). Upon use, the nonces table is updated to set used to True. A second login attempt would require a separate nonce. Once a nonce is no longer "fresh" it can be purged from the nonces table (so you don't have to store these forever). Obviously the server computes hmac_md(sha(password), nonce) and verifies it is the value received from the client. There are a copy of gotchas here. The biggest is how you initially setup the shared secret (aka the password). Without public key operations there is no good way to create accounts (unless this is done administratively, effectively "off line"). SSL of course can solve this (but you don't want to use SSL). You can also attempt to implement RSA in javascript and PHP (well, I'm sure routines exist for PHP). You can then download a public key in your javascript code for account registration. The user's browser can then compute sha(password) and send it encrypted in the public key (or encrypted in a data encrypting key which is encrypted in a public key). I don't know how amenable javascript is to doing RSA. Years ago (when computers were much slower) I wrote a Java Applet that did RSA in the applet for account registration at MIT. It wasn't very fast, but it was good enough for a one-time registration applet. Heh heh, we still use it today! Now of course I really cannot end this message without throwing in the obvious caution that without SSL your authentication is pretty weak. Even though you have not exposed the user's password, once logged in PHP uses a session cookie. This cookie, although of limited lifetime, is now available to the eavesdropper to steak and abuse. I'm not even sure that PHP ensures that a cookie is coming from the same IP address it was issued to (and in fact you cannot usually implement such a restriction because some environments [aka large NATs and other crud] can result in a legitimate user's traffic coming from different IP addresses even within the same web session!). And of course all of your data is also exposed, both for viewing and for modification in flight. Last I checked, SSL certificates could be had for the $20/year range, so I don't see how that is cost prohibitive! Modern hardware also does SSL pretty darn fast. You really have to have a very high traffic site before it becomes a problem. There actually aren't that many high traffic sites out there. Most organizations may think their sites are high traffic, but they rarely are. -Jeff ----- "Rene Veerman" <rene7...@gmail.com> wrote: > Hi. > > Recently, on both the jQuery(.com) and PHP mailinglists, a question > has arisen on how to properly secure a login form for a non-ssl > web-application. But the replies have been "get ssl".. :( > > I disagree, and think that with a proper layout of authentication > architecture, one can really secure a login system without having the > administrative overhead of installing SSL everywhere, and the monetary > cost for a SSL certificate for each domain. -- ======================================================================== Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu ======================================================================== --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com