On Aug 23, 2009, at 5:32 PM, mdipierro wrote: > > I will email Guido.
Looks like this was fixed in 2.5.2: http://bugs.python.org/issue1385 > > Massimo > > On Aug 23, 7:24 pm, "mr.freeze" <nat...@freezable.com> wrote: >> Development: >> Windows 7 RTM 64bit >> Intel Core 2 Quad processor >> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit >> (Intel)] on win32 >> Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit >> (Intel)] on win32 >> output: >> 46fb33cd6220b470d7fecb3dfb547fb2501517ca9695f8527895d1a4a1e515c0a05c8c1f15bd6f0439848717af00bdde902b50be454dd81878a9fce362b2e501 >> >> Production: >> Dreamhost server >> 2.6.29-xeon-aufs2.29-ipv6-qos-grsec kernel >> Python 2.5 (release25-maint, Jul 23 2008, 18:15:29) >> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 >> output: >> 485c79d8330897e613847f64333a0ccebd705b1902c4c4872cb1b7cc9ad856eb00e70dd11474b39282699a453dead6d86d6f482992778bb9166d9c920f9fa694 >> >> I tried it on two more systems and they both produce the same hash as >> my development machine. Definitely a Dreamhost issue. I think >> that's >> the third time they've hosed me today. >> >> On Aug 23, 7:08 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: >> >>> They are supposed to be the same. This is a hash algorithm and >>> cannot >>> depend on the machine. There is a bug somewhere (like the compiled a >>> 32 bits code on a 64 bits machine and the bit shifting operator >>> works >>> differently). >> >>> Can you give us details about the two python versions and machine >>> architectures? This is a major bug with hashlib or hmac. >> >>> Massimo >> >>> On Aug 23, 6:59 pm, "mr.freeze" <nat...@freezable.com> wrote: >> >>>> Yes, varchar(128). Here's the output of that command on both >>>> servers >>>> from the terminal: >> >>>> Production:>>> import hmac >>>>>>> import hashlib >>>>>>> d= hmac.new('mykey','mypass',hashlib.sha512) >>>>>>> d.hexdigest() >> >>>> '485c79d8330897e613847f64333a0ccebd705b1902c4c4872cb1b7cc9ad856eb00e70dd11474b39282699a453dead6d86d6f482992778bb9166d9c920f9fa694 >>>> >>>> ' >> >>>> Development:>>> import hmac >>>>>>> import hashlib >>>>>>> d = hmac.new('mykey','mypass',hashlib.sha512) >>>>>>> d.hexdigest() >> >>>> '46fb33cd6220b470d7fecb3dfb547fb2501517ca9695f8527895d1a4a1e515c0a05c8c1f15bd6f0439848717af00bdde902b50be454dd81878a9fce362b2e501 >>>> >>>> ' >> >>>> They're supposed to be the same, right? Or am I misunderstanding >>>> how >>>> this works. >> >>>> On Aug 23, 6:34 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: >> >>>>> I cannot reproduce any machine dependence. I tried: >> >>>>> hmac.new('mykey','something',hashlib.sha512).hexdigest() >> >>>>> How long is your password field. Is it 128 bytes? >> >>>>> Massimo >> >>>>> On Aug 23, 5:57 pm, "mr.freeze" <nat...@freezable.com> wrote: >> >>>>>> I have a strange situation and I know virtually nothing about >>>>>> cryptography. I am passing a key to my auth password requires >>>>>> statement after the recent discussion on security strength like >>>>>> so: >> >>>>>> if "login" in request.args: >>>>>> t.password.requires = [CRYPT(key='mykey')] >>>>>> else: >>>>>> t.password.requires = >>>>>> [IS_STRONG(upper=1,number=1,special=1),CRYPT >>>>>> (key='mykey')] >> >>>>>> Here's the weird part: I have a dev server and a production >>>>>> server >>>>>> that are both running web2py and pointed to the same MySQL >>>>>> database. >>>>>> If I reset a user password from the dev server >>>>>> (retrieve_password), I >>>>>> can only log in from the dev server after that. The same is >>>>>> true for >>>>>> the production machine. Resetting from the production server >>>>>> reverses >>>>>> the situation. >> >>>>>> I have stepped through the code and verified that at line 779 in >>>>>> tools.py user[passfield] is indeed different than form.vars.get >>>>>> (passfield, '') (both look like valid password hashes) so user >>>>>> = None, >>>>>> and thus login fails. >> >>>>>> All I can figure is that the encryption is bound to the machine >>>>>> that >>>>>> generated the password hash. I'm using the same version of >>>>>> Python and >>>>>> web2py. Can someone verify or explain? >> >>>>>> As always, thanks for your help. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
