Re: [mp2.0] wrong crypt behavior
On Thu, 10 Oct 2002, Ask Bjoern Hansen wrote: On Fri, 6 Sep 2002, [iso-8859-2] Tomá¹ Procházka wrote: Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line Did anyone figure this out? Rick Bradley did, but only posted it on the dev@ list where I didn't catch it. It's a bug in glibc 2.2.5 on linux: http:[EMAIL PROTECTED]/msg85673.html - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [mp2.0] wrong crypt behavior
On Fri, 6 Sep 2002, [iso-8859-2] Tomá¹ Procházka wrote: Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line Did anyone figure this out? The following content handler gives a different output everytime I restart my threaded mod_perl 2.0. Dm8yjkphWW352 is the correct answer; I get that after about a third of the restarts. - ask package Develooper::MT::Test; use strict; use warnings; use Apache::RequestRec (); use Apache::RequestIO (); use Apache::Const -compile = 'OK'; my $clear = foo; my $salt = Dm; sub handler { my $r = shift; $r-content_type('text/plain'); my $crypted = crypt $clear, $salt; $r-print(crypt $clear, $salt = $crypted); return Apache::OK; } 1; -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [mp2.0] wrong crypt behavior
On Thu, 10 Oct 2002, Ask Bjoern Hansen wrote: Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line Did anyone figure this out? The following content handler gives a different output everytime I restart my threaded mod_perl 2.0. Dm8yjkphWW352 is the correct answer; I get that after about a third of the restarts. FWIW, the following test program (also with 5.8.0 with threads (duh)) doesn't seem to have a problem with crypt. use threads; for (1..50) { threads-create(test); } map { $_-join } grep { $_-tid != threads-tid } threads-list; sub test { my $salt= Dm; my $clear = foo; for (1..1) { my $crypted = crypt($clear,$salt); print $crypted\n if $crypted ne Dm8yjkphWW352; } } - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [mp2.0] wrong crypt behavior
I missed part of this thread, but I have my doubts about perl's internal crypt working correctly in a threaded environment. Using 5.8.0 threaded for the x86 platform / mod_perl 1.27 that on an uniprocessor machine it would produce correct results most of the time, but on a multiprocessor machine it would consistantly produce bad results. After battling with it for awhile and not having time to get correct data to produce a bug report - I switched to the pure perl version Crypt::UnixCrypt which works quite well across the board. *sigh* On Thu, 10 Oct 2002, Ask Bjoern Hansen wrote: On Fri, 6 Sep 2002, [iso-8859-2] Tomá¹ Procházka wrote: Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line Did anyone figure this out? The following content handler gives a different output everytime I restart my threaded mod_perl 2.0. Dm8yjkphWW352 is the correct answer; I get that after about a third of the restarts. - ask package Develooper::MT::Test; use strict; use warnings; use Apache::RequestRec (); use Apache::RequestIO (); use Apache::Const -compile = 'OK'; my $clear = foo; my $salt = Dm; sub handler { my $r = shift; $r-content_type('text/plain'); my $crypted = crypt $clear, $salt; $r-print(crypt $clear, $salt = $crypted); return Apache::OK; } 1; -- //\\ || D. Hageman[EMAIL PROTECTED] || \\//
Re: [mp2.0] wrong crypt behavior
On Fri, 6 Sep 2002 08:23:33 +0200 Toma'? Procha'zka [EMAIL PROTECTED] wrote: For comparsion of password user entered and password stored in database is crypt function used. Here is the code: my $real_pass = $d-[0][0]; # crypted password from database my $salt = substr $real_pass,0,2; # salt my $test_pass = crypt $sent_pw,$salt; # in $sent_pw is the password user entered if ($real_pass eq $test_pass) { $r-subprocess_env(REMOTE_USER = $user); return OK; } else { $r-note_basic_auth_failure; return AUTH_REQUIRED; } Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line $r-log_reason(User $user tested (.$real_pass./.$test_pass.)...,); just before 'if' statement behavior is most of time correct. I have also seen this problem. I am using RT [0] and have intermittent login problems where suddenly crypt() called from mod_perl will start generating the wrong return values [ i.e., $pass ne crypt($user, $pass) ]. After some period of time the crypt() call will start generating the correct values again. Executing the exact same crypt() calls via a command-line perl -e 'print crypt([string], [string])' generates the expected (correct) results. If (in the code run by mod_perl) I replace: if ($pass eq crypt($user, $pass)) { with: $crypt = `perl -e 'print crypt(\$user\, \$pass\)'`; chomp($crypt); if ($pass eq $crypt) { Then everything works perfectly, though less quickly and blatantly insecurely. I have checked the failing $user, $pass and crypt() values thoroughly for wierdness and compared them to their successful counterparts. I am 100% convinced that crypt() is returning the wrong values. Note that the wrong values are consistent (i.e., they are not random, not changing, just not correct). My original RT problem report (including voluminous configuration information, but prior to the isolation of the crypt() issue) can be found at: http://lists.fsck.com/pipermail/rt-users/2002-September/010117.html Question: is crypt() thread-safe? I haven't had a chance to look at the source but I plan on doing so soon. A tiny bit more info: $ strace perl -e 'print crypt(foo, bar)' 21 | grep crypt execve(/usr/bin/perl, [perl, -e, print crypt(\foo\, \bar\)], [/* 22 vars */]) = 0 open(/lib/libcrypt.so.1, O_RDONLY)= 3 $ ls -al /lib/libcrypt.so.1 /lib/libcrypt-2.2.5.so lrwxrwxrwx1 root root 17 Sep 23 18:13 /lib/libcrypt.so.1 - libcrypt-2.2.5.so -rw-r--r--1 root root19136 Sep 17 21:50 /lib/libcrypt-2.2.5.so [0] http://www.bestpractical.com/rt/index.html Rick -- http://www.rickbradley.comMUPRN: 812(???F/???F) | me a line. It's the random email haiku | only commercial unix | I've ever liked. Wow.
Re: [mp2.0] wrong crypt behavior
On Fri, 6 Sep 2002 08:23:33 +0200 Tomá¹ Procházka [EMAIL PROTECTED] wrote: Hello, I use own PerlAuthenHandler module to verify users' login and password from database. For comparsion of password user entered and password stored in database is crypt function used. Here is the code: my $real_pass = $d-[0][0]; # crypted password from database my $salt = substr $real_pass,0,2; # salt my $test_pass = crypt $sent_pw,$salt; # in $sent_pw is the password user entered if ($real_pass eq $test_pass) { $r-subprocess_env(REMOTE_USER = $user); return OK; } else { $r-note_basic_auth_failure; return AUTH_REQUIRED; } Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line $r-log_reason(User $user tested (.$real_pass./.$test_pass.)...,); just before 'if' statement behavior is most of time correct. Can anybody help me? Thanks. Kacer Hi, It seems to be not a mod_perl related problem. However, try with: $test_pass = crypt $sent_pw,$real_pass; Bye, - Enrico
Re: [mp2.0] wrong crypt behavior
Fri, Sep 06, 2002 ve 09:57:01AM +0200 Enrico Sorcinelli napsal(a): On Fri, 6 Sep 2002 08:23:33 +0200 Tom? Prochzka [EMAIL PROTECTED] wrote: Hello, I use own PerlAuthenHandler module to verify users' login and password from database. For comparsion of password user entered and password stored in database is crypt function used. Here is the code: my $real_pass = $d-[0][0]; # crypted password from database my $salt = substr $real_pass,0,2; # salt my $test_pass = crypt $sent_pw,$salt; # in $sent_pw is the password user entered if ($real_pass eq $test_pass) { $r-subprocess_env(REMOTE_USER = $user); return OK; } else { $r-note_basic_auth_failure; return AUTH_REQUIRED; } Problem: Sometimes, although user entered correct password, is authentication rejected. I tried logging values of $real_pass and $test_pass and they differed. When I add line $r-log_reason(User $user tested (.$real_pass./.$test_pass.)...,); just before 'if' statement behavior is most of time correct. Can anybody help me? Thanks. Kacer Hi, It seems to be not a mod_perl related problem. However, try with: $test_pass = crypt $sent_pw,$real_pass; This is what I tried first (it's common in examples). Results were terrible. Kacer