On Sunday 26 September 2010 13:08:59 Matthew Stoltenberg wrote: > > My question was really about the purpose of this HMAC thing. If you > > _can_ just prepend (or append) the password to the input data, what's > > HMAC for? > > Generally, HMAC is used as follows: > > C - client (has the hashed password as input by the luser) > S - server (has the hashed password stored in a database) > T - token (random series of bits; not really sure how random it has to be) > > C - > S request T > S -> C sends T (and stores it for a set period of time) > C -> S hmac(password, T) the actual hash is interchangeable (sha1, > md5, etc) as long as C and S use the same hash > S also does hmac(password, T) and compares the result to what C sent; > it also should discard the T at this point > S -> C Grant/Deny based on result of comparison > > > This allows plaintext authentication where we don't care if any of the > authentication messages are sniffed. The password hash itself is > never sent, just the combination of it with the token that expires as > soon as its used. > > There's at least two problems with this authentication mechanism: > 1) further communications between C and S aren't secure > 2) getting the password hash to S is an exercise left up for > implementation (especially given 1) > > > Matt
I note that I have, from time to time, catted an sha1sum hash as one of the inputs into the generation of a new sha1sum hash. (Basically so I'm not keeping their cleartext password around locally.) If getting said password hash from point A to point B is still an exercise left to the reader, I'm still not seeing where modifying the sha1sum algorithm enters into it... Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
