Keyed Hash?

[Rob Landley]

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.