Comments on the checksum vulnerabilities

[John Hascall]

I think you were right on target in your blog where you said that
the API needs to make it easier to do the right thing instead of
the wrong thing.

And, yes, better documentation always helps -- particularly where
it shows examples of the right way to do things -- many people are
lazy/pressed for time/etc, better to have them crib from a correct
example than toss together whatever comes off the top of their head.

John

-------------------------------------------------------------------------------
John Hascall, john at iastate.edu
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)
IT Services, The Iowa State University of Science and Technology

> 
> I'd like to draw people's attention to a blog post I made on the
> checksum vulnerabilities.  I would like to start a discussion on what if
> anything we still need to fix and on what we did wrong to get here.
> http://www.painless-security.com/blog/2010/12/03/bad-hair-day-for-kerber
> 
> Initial thoughts:
> 
> * Is it desirable that you have to make an extra step when verifying a
>   checksum to make sure it is keyed?
> 
> * People were probably assuming that if a checksum works with a given
>   key and it is a keyed checksum, then it is a right kind of checksum
>   for that key from a security standpoint.  Roughly, this is close to
>   assuming that checksums should either be unkeyed or work with one kind
>   of key. I think we want to make this actually true going forward.
> 
> * People assumed something similar when finding a keyed checksum.
> 
> * Documentation might have heleped.
> 
> However I feel like there is something I'm missing in here somewhere.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>