Date: Wed, 8 Aug 2012 22:30:01 +0800 From: orc <orc@...server.ru> To: musl@...ts.openwall.com Subject: Re: crypt* files in crypt directory On Wed, 8 Aug 2012 09:06:23 -0400 Rich Felker <dalias@...ifal.cx> wrote: > On Wed, Aug 08, 2012 at 09:52:34AM +0200, Szabolcs Nagy wrote: > > * Solar Designer <solar@...nwall.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.