From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1466 Path: news.gmane.org!not-for-mail From: orc Newsgroups: gmane.linux.lib.musl.general Subject: Re: crypt* files in crypt directory Date: Wed, 8 Aug 2012 22:30:01 +0800 Message-ID: <20120808223001.4141ca2b@sibserver.ru> References: <20120808022421.GE27715@brightrain.aerifal.cx> <20120808044235.GA22470@openwall.com> <20120808075233.GJ30810@port70.net> <20120808130622.GJ27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1344436328 4037 80.91.229.3 (8 Aug 2012 14:32:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2012 14:32:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1467-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 08 16:32:08 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 1Sz7Iq-0005n6-DG for gllmg-musl@plane.gmane.org; Wed, 08 Aug 2012 16:32:04 +0200 Original-Received: (qmail 9337 invoked by uid 550); 8 Aug 2012 14:32:02 -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 9292 invoked from network); 8 Aug 2012 14:31:58 -0000 In-Reply-To: <20120808130622.GJ27715@brightrain.aerifal.cx> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:1466 Archived-At: On Wed, 8 Aug 2012 09:06:23 -0400 Rich Felker wrote: > On Wed, Aug 08, 2012 at 09:52:34AM +0200, Szabolcs Nagy wrote: > > * Solar Designer [2012-08-08 08:42:35 +0400]: > > > I see that you did this - and I think you took it too far. The > > > code became twice slower on Pentium 3 when compiling with gcc > > > 3.4.5 (approx. 140 c/s down to 77 c/s). Adding -finline-functions > > > -fold-unroll-all-loops regains only a fraction of the speed (112 > > > c/s); less aggressive loop unrolling results in lower speeds. > > > > > > > i thought slowness is a feature in this case.. > > > > at least that was the general agreement about the > > size vs speed tradeoff of the des code > > Solar's argument is that if you want more slowness, you should just > use a higher iteration count that also affects people trying to crack > your passwords. And being slower at the same count discourages > increasing the count. > > Actually this brings up a HUGE DoS vuln in blowfish crypt: with tcb > passwords, a malicious user can put a password with count=31 (it's > logarithmic, so this means 2^31) in their tcb shadow file. This will > cause a root-owned process to eat 100% cpu for hours if not days. > Perform a few simultaneous login attempts and the whole server becomes > unusable. That's why glibc does not implements tcb scheme internally? (Not just because Drepper can say "this is useless") They have 'rounds=' argument in their crypt() sha256/512 implementation. > > I don't know how to solve it, but in musl I think we'll have to put a > low limit on count if we're going to support blowfish. Unfortunately I > don't see a good way to make it runtime configurable without > hard-coding additional non-standard config paths, but letting the DoS > bug slip in is not acceptable. While I experimented with musl-enabled system I implemented another password hashing algorithm in musl (because musl had only des encryption with max. 8 password chars) based on skein hash. I also separately written small code for parsing standalone config file to take additional parameters like second salt (just for testing, then I leaved it so any host can have different hashes) and number of rounds. This file can be accessed by root (obviously) and programs that require user auth (I set sgid bit on them and 'tcb' group, same group on file with settings). Should we support such way to set number of rounds (count) and revert to hardcoded one if file cannot be read? > > Rich