From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9747 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] crypt_blowfish: allow short salt strings Date: Sun, 27 Mar 2016 09:26:35 -0400 Message-ID: <20160327132634.GY21636@brightrain.aerifal.cx> References: <1458907955-8698-1-git-send-email-timo.teras@iki.fi> <20160327021121.GA28942@openwall.com> <20160327033007.GA29317@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: ger.gmane.org 1459085213 14097 80.91.229.3 (27 Mar 2016 13:26:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 13:26:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9760-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 27 15:26:52 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1akAiS-0007Ao-Bh for gllmg-musl@m.gmane.org; Sun, 27 Mar 2016 15:26:52 +0200 Original-Received: (qmail 2033 invoked by uid 550); 27 Mar 2016 13:26:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 2015 invoked from network); 27 Mar 2016 13:26:47 -0000 Content-Disposition: inline In-Reply-To: <20160327033007.GA29317@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9747 Archived-At: On Sun, Mar 27, 2016 at 06:30:07AM +0300, Solar Designer wrote: > On Sun, Mar 27, 2016 at 05:11:21AM +0300, Solar Designer wrote: > > There is one maybe-bug seen in your test results: the "*" return on > > error. Normally, it would be "*0" or "*1" for crypt_blowfish, and it > > would never match the salt input. Rich, did musl retain this behavior? > > Where does the bare "*" come from? The concern here is that a "*" might > > also be returned when crypt() is called with "*" for the salt input. > > Then its output would match what may be a stored hash placeholder, where > > "*" means locked account or an error having occurred when the password > > was set. We must deny access in such cases, but returning "*" on all > > errors would grant access. This could be a musl or PHP security bug, if > > it's indeed as bad as it appears from that test. > > I just discussed this with Rich. > > Yes, musl's modified crypt_blowfish returns "*" on error. No, this > isn't a security bug in musl as a whole, because that code path is not > reached when the setting argument is "*" as well. So no match. > > However, there's risk for code reuse from musl by other projects, and > for potential cut-down revisions of musl (with only bcrypt left, invoked > unconditionally). So I think a change is needed, either reintroducing > the "*0" / "*1" behavior (my preference) or returning NULL (Rich's > preference) on error like glibc does (and unfortunately crashing older > programs that don't expect this). The reason I prefer returning null is that applications get a specified diagnostic that the provided setting string failed to produce a matchable hash; this allows correct applications to avoid storing an unmatchable hash that would render password authentication impossible (always-failing) and instead retry with different settings. This also seems to be the only reasonable way to runtime-probe for which hashes are supported. Solar has pointed out to me that you can use strlen(result)<13 as a failure condition, and that robust programs may already be doing this, but it seems hackish and it's not documented/specified anywhere. Rich