Re: Package Proposal: Auth_HMAC

JMC, Thanks for your response, much appreciated :) Thanks for clearing up some stuff to do with HMAC, I am still a little confused as to what PEAR::Message *does*. I was under the impression that it was for verifying messages, and as such was built specifically for that task using HMAC, how would I go about integrating that into my login? (I know without seeing my code thats not the easiest thing to answer. BTW JMC, you are one of the people who looked at my original code :D) I think that sticking to one type of hash may be vital, so as to keep the code trimmed, although allowing for variable length hashes wouldn't be too hard I don't think. See, the problem lies on a few things: a) if the hash isn't %2 it would have to have a character removed before splitting it, that would need to be stored in $_SESSION alongside the hash(es) b) when taking the string apart, we'd need to know how long the original hashes where c) would the PEAR::Message class do the 'verification' of the hash? or would it be upto me? is there any difference between what PEAR::Message does and Crypt_HMAC does (as far as MD5/SHA1 goes at least, not including the mcrypt stuff either). One other thing on this subject, I think that moving the PHP fallback implementations of SHA1 and MD5 to Crypt_HMAC (no need, its already there) and Crypt_SHA1 and then using those from within PEAR::Message would allow people who don't want to use Mcrypt at all, or just want MD5 or SHA1, to just use those on their own. - Davey Jesus M. Castagnetto wrote:

Davey, --- Davey <davey@pixelated-dreams.com> 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

That is only true if you are using MD5. In general, it depends on the actual hashing algorithm you are using. If you look at the HMAC test vectors from RFC 2202, you can use SHA1, so the actual output digest will be longer when using SHA1 (for example). You can see the examples in 'Message/misc/rfc2202_testvectors.php'

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 am not sure about your definition of a 'proper' HMAC implementation. The HMAC RFC (2104) does not dictacte anything about your server key, so in principle your server can use a codebook approach to create keys with a given lifetime and that will not repeat, or will repeat after a long period of time.

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)

You can use your approach w/ PEAR::Message, there are factory methods as well as static methods, depending on whether you just want the digest or you want to get an object. BTW, you can pass an array as the data payload, and tell the method how to serialize the information before hashing it, so your username/password/whatever can easily be done.

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

The PEAR::Message class also has fallback methods in case the installation does not have mhash, in that case you can do HMAC with MD5 and SHA1 only, if you have mhash, you can use *any* of mhash's hashing algorithms. Cheers. ===== --- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Personal: http://www.castagnetto.org/ __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com