Re: Package Proposal: Auth_HMAC

Goog Grief, what *have* I started!? Well, I'd still like some input on *this* thread, and I'll go give my opinions on the other... mess, asap. I'm currently editing my source to use Crypt_HMAC, I don't need anything else from Message (seems there is more to that which I don't need, correct me if I'm wrong) and Crypt_HMAC is faster (according to Derick). - Davey Davey wrote:

OK, I've been working on a new login system for my CMS these last few weeks, and I now believe I have *the* strongest non-SSL login ever. basically, *every* time the login form is generate, a random hash is generated (currently $hash = md5(uniqid(nt_rand(),1));), this is split into two halves and stored in $_SESSION. The hash is output both in the HTML login form (hidden elements, removed with JS) and the JS used with this for client side data-checking. When the user submits the form, JS MD5 hashes the username and password, appending one half of the hash onto each. this mean 1/3 of the username/password hash is unique to each request, and that part is identifiable as supposed to be coming from that client that means anyone packet sniffing must grab the username/password hash, remove the last 16chars of each to get the username/password, and also get their SID, then catch the login of that *same* user again (hashes change upon login too, same hashes won't work twice), grab the new hashes and submit it from their SID all before that user does so. HMAC works similarly but it uses a single 128bit hash, I use 2x64bit hash in the 'CVS' version, it a hidden element defaults to non-JS (so PHP assumes no client-side data-checking and no MD5 etc) with JS changing the value of a hidden input if JS is enabled. This means it'll work with non-JS capable browsers but it won't be as secure (although I can still do some source integrity checking cause the two hashes are available from the form) I propose moving this to the proper HMAC implementation except with my random key instead of the fixed HMAC server key. I would also consider making it an extension onto the Auth package, and implementing by adding another argument to the constructor (optional so that current code doesn't break) which would then disregard any current set login form set using loginFunction() and use my JS enabled (assuming client is JS enabled) form. Note that there is already a HMAC method in the Message package, whilst I've not looked at it, I may be able to use that from that package as it is (although thats a dependency) or if it's not quite compatible (I'm assuming the dynamic hash might not be compatible) I can simply copy and paste and make the small (I would assume) changes that are needed. (thus voiding the dependency too) Any comments/suggestions on this would be welcome. I will try to clean up my code and implement HMAC within the next couple of days or so and show it to you all. - Davey