Re: crypt* files in crypt directory

[orc <orc@sibserver.ru>]

On Wed, 8 Aug 2012 09:06:23 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Wed, Aug 08, 2012 at 09:52:34AM +0200, Szabolcs Nagy wrote:
> > * Solar Designer <solar@openwall.com> [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