Re: [SBEAMS-devel] Re: Test script
Brought to you by:
edeutsch
Menu
▾
▴
Re: [SBEAMS-devel] Re: Test script
|
From: Dave C. <dca...@sy...> - 2006-03-23 21:48:16
|
Eric; I updated the Crypt::CBC on my machine to version 2.17, and modified the test script (enclosed) to use one cipher object for encryption and another for decryption. I still get the same value before and after encryption, although I now get the prefix 'Salted__' on the encrypted string. dcampbel@digdug:~>/local/programs/bin/perl -MCrypt::CBC -le 'print $Crypt::CBC::VERSION' 2.17 dcampbel@digdug:~>./test_crypt.pl asdf Original name is: asdf Encrypted name is: Salted__%D3w%FB%7C%FET%C5%14E%FD%9A%BE%0CsWX Decrypted name is: asdf This doesn't explain what is happening, but it does demonstrate that 2.17 can work as currently invoked. -Dave >Hi Sandra, I did the following on atlas (ISB) and on "the 27": > >perl -d -e 1 >use Crypt::CBC >print $Crypt::CBC::VERSION >2.08 > > >fgcz-s-027:/srv/www/sbeams.fgcz-net.unizh.ch> perl -d -e 1 >use Crypt::CBC >print $Crypt::CBC::VERSION >2.12 > > >fgcz-s-027:/srv/www/sbeams.fgcz-net.unizh.ch> ll `locate CBC` >-rw-r--r-- 1 root root 5461 2006-03-12 18:12 /usr/share/man/man3/Crypt::CBC.3pm.gz >-rw-r--r-- 1 root root 21276 2006-03-12 18:12 /usr/share/perl5/Crypt/CBC.pm > >It appears that Crypt::CBC is newer on your machine *and* it appears that it was last updated 11 days ago. I vaguely recall you said that problems started occurring 10 days ago? > >Maybe an upgrade of this CPAN module caused the problem? Do you know anything about this upgrade? Was this done in response to the problem or perhaps the cause of the problem? > >Thanks, >Eric > > > > > >>-----Original Message----- >>From: sbe...@li... [mailto:sbeams-devel- >>ad...@li...] On Behalf Of Sandra Loevenich >>Sent: Thursday, March 23, 2006 1:16 PM >>To: sbe...@li... >>Subject: Re: [SBEAMS-devel] Re: Test script >> >>Hi Dave, >>Just a short note: I edited your script so that it would use a new >>cipher object (using exactly the same constructor call)-- >>The returned string is not the same. >> >>I will get back to you when having tried your suggestions below.. >> >>Best >> Sandra >> >> >>Dave Campbell schrieb: >> >> >> >>>Sandra; >>> >>>The debug info is interesting, and as you say it is little wonder that >>>the SQL query is failing. The general cookie process is: >>> >>>1) take known username from initial authentication, and encrypt using >>>Crypt::CBC with the encryption 'salt' from the SBEAMS.conf file >>>2) put that into a hash keyed by time and let CGI.pm turn that into a >>>cookie. This causes the string (encrypted name) to get url escaped, >>>which is why my script used the $q->escape method to turn the >>>non-printing characters into %xx. >>>3) When the cookie gets returned, use CGI.pm cookie fetching to get a >>>key => value pair; the value is the name before decryption. >>>4) decrypt using the Crypt::CBC and the same salt as before. In this >>>case it will obviously be a new cipher object; as you pointed out the >>>example script used the same one for both encryption and decryption, >>>just because it was convenient. >>> >>>Yesterday you mentioned seeing the text 'sloevenich' in a debug stmt >>>you had put in, so I thought perhaps step one wasn't working and the >>>encrypt was simply returning the original string. From your debug info >>>today that is not the case, and the script makes it seem that the >>>encryption/decryption in general are working OK. So it seems the >>>problem may be in storing/retrieving the value from the cookie, here >>>are a few things you might try: >>> >>>a) print out the encrypted username right after you encrypt, then >>>compare to the value you get out of the cookie on the next visit. >>>b) print out the 'CRYPT_KEY' on encryption and decryption, verify they >>>are the same. I would put some bounding characters in to make sure >>>there are the same number of spaces ( like ">$key<" ); >>>c) decrypt the encrypted name right after encryption, and print out to >>>show that the process is reversible at that point. >>> >>>You could also modify the script so that decryption used a second >>>cipher object (using the same salt), this would show that different >>>cipher objects can do complementary encryption/decryption. I would >>>also think about anything that happened right around the time you >>>started noticing this, since the onset of the problem seemed pretty >>>sudden. Sorry I can't be of more help. >>> >>>-Dave >>> >>> >>> >>> >>>>Debug [2006-03-23 09:09:10] (Authenticator.pm line 407): Name is >>>>���;�d BEFORE decryption >>>>Debug [2006-03-23 09:09:10] (Authenticator.pm line 412): Name is >>>>}'a4hch AFTER decryption >>>>Debug [2006-03-23 09:09:10] (Authenticator.pm line 414): sql_name is >>>>}''a4hch AFTER convertSignletoTwoQuotes >>>> >>>> >>>> >>>> >>>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by xPML, a groundbreaking scripting >>>language >>>that extends applications into web and mobile media. Attend the live >>>webcast >>>and join the prime developer group breaking into this new coding >>>territory! >>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >>>_______________________________________________ >>>SBEAMS-devel mailing list >>>SBE...@li... >>>https://lists.sourceforge.net/lists/listinfo/sbeams-devel >>> >>> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by xPML, a groundbreaking scripting >>language >>that extends applications into web and mobile media. Attend the live >>webcast >>and join the prime developer group breaking into this new coding >>territory! >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >>_______________________________________________ >>SBEAMS-devel mailing list >>SBE...@li... >>https://lists.sourceforge.net/lists/listinfo/sbeams-devel >> >> > >N�HS^�隊X���'���u��<�ڂ�.���y�"� �*m�x%jx.j���^�קvƩ�X�jب�ȧ�� m�ݚ���v&��קv�^�+����j�Z���{az���^��h���n���)�{h���� �ا��+h�(m�����Z�� jY�w��ǥrg�y$���Oxḝn�m j��^�� D > |