From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9746 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] crypt_blowfish: allow short salt strings Date: Sun, 27 Mar 2016 06:30:07 +0300 Message-ID: <20160327033007.GA29317@openwall.com> References: <1458907955-8698-1-git-send-email-timo.teras@iki.fi> <20160327021121.GA28942@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 1459049431 19685 80.91.229.3 (27 Mar 2016 03:30:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 03:30:31 +0000 (UTC) Cc: Timo Teras To: musl@lists.openwall.com Original-X-From: musl-return-9759-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 27 05:30:30 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 1ak1PJ-0005op-GE for gllmg-musl@m.gmane.org; Sun, 27 Mar 2016 05:30:29 +0200 Original-Received: (qmail 26103 invoked by uid 550); 27 Mar 2016 03:30:26 -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 26081 invoked from network); 27 Mar 2016 03:30:26 -0000 Content-Disposition: inline In-Reply-To: <20160327021121.GA28942@openwall.com> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:9746 Archived-At: 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). Alexander