From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1580 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Todo for release? Date: Mon, 13 Aug 2012 22:58:05 -0400 Message-ID: <20120814025805.GE27715@brightrain.aerifal.cx> References: <20120813185329.GA20024@brightrain.aerifal.cx> <20120813213154.GI20243@port70.net> <20120813222058.GB8817@openwall.com> <20120814014652.GC27715@brightrain.aerifal.cx> <20120814021317.GA10036@openwall.com> <20120814023508.GD27715@brightrain.aerifal.cx> <20120814024903.GA10188@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344913029 8326 80.91.229.3 (14 Aug 2012 02:57:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2012 02:57:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1581-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 14 04:57:09 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T17Jc-0003hf-EK for gllmg-musl@plane.gmane.org; Tue, 14 Aug 2012 04:57:08 +0200 Original-Received: (qmail 6062 invoked by uid 550); 14 Aug 2012 02:57:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 6054 invoked from network); 14 Aug 2012 02:57:07 -0000 Content-Disposition: inline In-Reply-To: <20120814024903.GA10188@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1580 Archived-At: 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