* Solar Designer <solar@private> [2006-07-03 09:07:50 +0400]:
> > > As it relates to the segfault you're seeing, I think it'd be most
> > > straightforward to debug it rather than proceed to theorize as to its
> > > possible cause.
>
> On Sun, Jul 02, 2006 at 09:52:14PM -0600, Vincent Danen wrote:
> > I agree. And I'm starting to suspect ...
>
> If you've agreed that it's most straightforward to just go ahead and
> debug the segfault, then why are you proceeding to "suspect" something?
I'd been debugging for most of the night, but still came up with nothing
concrete. I wish I had, but I didn't, so I'm still suspecting things
until I can actually find the culprit.
> > At any rate, I've been fiddling with the options of pam_tcb and tried to
> > make it use regular md5 passwords by first changing "prefix=$2a$" to
> > "prefix=$1$", which didn't work. I then tried removing the prefix
> > option and using "md5" in there, but now I'm seeing this in syslog:
> >
> > authpriv.crit: passwd[2046]: pam_tcb(passwd:chauthtok):
> > crypt_gensalt_ra: Invalid argument
>
> Most likely, you did not also remove the explicit "count=..." setting.
> The FreeBSD-style MD5-based hashing method does not accept variable
> iteration counts, so it is wrong to try to specify a count with it.
>
> The pam_tcb(8) man page documents this as follows:
>
> count= The number of iterations of an underlying crypto-
> graphic primitive to use when hashing passwords.
> The default is 0, which lets the selected hashing
> algorithm pick its default iteration count.
>
> It is highly recommended that you override this
> setting. Please refer to crypt(3) for information
> on supported hashing methods, their prefix strings,
> and their count settings.
>
> crypt(3) says:
>
> ERRORS
> EINVAL
> [...]
> crypt_gensalt, crypt_gensalt_rn, crypt_gensalt_ra:
> prefix is invalid or not supported by this imple-
> mentation; count is invalid for the requested pre-
> fix; ...
> [...]
> FreeBSD-style MD5-based
> [...]
> Iteration count
> 1000
Interesting. I must have missed that when I was reading the manpage,
thanks. I didn't think that the count would have been the problem... is
"count" only useful for bcrypt then (in a real-world scenario)? Ie if
someone wants to use md5 passwords, crypt should just be removed,
correct?
I need to know this for the migration tool and documentation so that if
a user wants to go back to md5 passwords, I can easily document what
needs to change, etc.
> > [vdanen@build SOURCES]$ ./hasher foo '$2a$salt'
> > *0
> > [vdanen@build SOURCES]$ ./hasher foo '$2a$'
> > *0
>
> That's the correct output for invalid salt strings like those you've
> been providing.
Well, I haven't been able to find anything idiot-friendly to tell me
what to use.
> > Well, I did find this:
> >
> > http://www.openwall.com/lists/john-users/2005/07/02/1
> >
> > and then tried hasher with '$2a$05' to try to simulate what I saw there
> > and still no dice
>
> Using the example bcrypt salt from that john-users posting, we get:
>
> $ perl -e 'print crypt("foo", "\$2a\$05\$abcdefghijklmnopqrstuu"), "\n"'
> $2a$05$abcdefghijklmnopqrstuuz29TNT43FrbrkSgusq0SUVtGQkhH2mm
>
> You can repeat this "Perl test" on your system just to make sure that
> crypt_blowfish in your glibc works, but I am fairly certain that it does
> and that it has nothing to do with the segfault.
That example works perfectly and actually shows me something useful.
Well, it doesn't work perfectly, but I think I can stop suspecting
crypt_blowfish in glibc and start debugging that particular problem
because:
[vdanen@build SOURCES]$ perl -e 'print crypt("foo", "\$2a\$05\$abcdefghijklmnopqrstuu"), "\n"'
Segmentation fault
Thanks, Solar. At least that little perl one-liner has a) shown me a
correct salt type to use and b) showed me where my problem is.
Oh, and using that same salt with hasher:
[vdanen@build SOURCES]$ ./hasher foo '$2a$05$abcdefghijklmnopqrstuu'
Segmentation fault
--
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)
:: Annvix - Secure Linux Server: http://annvix.org/ ::
This archive was generated by hypermail 2.1.3 : Mon Jul 03 2006 - 08:29:22 PDT