Re: Todo for release?

[Rich Felker <dalias@aerifal.cx>]

On Tue, Aug 14, 2012 at 06:49:03AM +0400, Solar Designer wrote:
> > If this issue is as simple to solve as it sounds, it might make sense
> > to allow arbitrary key sizes. After all, programs that could be DoS'd
> > by long keys are already going to be limiting key length themselves.
> 
> That's wishful thinking.

Are you sure? I haven't read the code lately, but I can't imagine any
login daemon is going to be calling realloc() in a loop to read an
arbitrarily long password before authentication. That just sounds
gratuitously broken (i.e. someone went out of their way to write
painful code that does nothing useful and makes their daemon
susceptible to DoS).

> > If time grew superlinearly in key length, I'd say it should definitely
> > be limited, but since the growth is just linear (the expected growth
> > rate for any interface that takes a string argument), I think it's
> > less clear what should be done.
> 
> Yes, it is not clear what should be done.

If it's a toss-up on whether we should limit key length for runtime
considerations, I might just go on a basis of how it affects code
complexity for handling long keys and thus still limit them.

> > something that can never match. By the way, would you agree that all
> > programs that generate new password hashes should do so by calling
> > crypt twice, the second time using the output of the first as the
> > setting/salt, and verify that the results match? This seems to be the
> > only safe/portable way to make sure you got a valid hash and not an
> > error.
> 
> This makes sense, yet it sounds overkill to me.  I'd simply check for
> hash && strlen(hash) >= 13.

Indeed, strlen(hash)>=13 is certainly a necessary condition, but is it
sufficient? I could imagine a hypothetical crypt implementation that
puts error messages in the unmatchable hash as a debugging aid to why
generating the hash failed, but I agree they probably don't exist.
Still, changing your password should not be a frequent action, so it
might make the most sense to do the check the way I suggested.

Rich