What specifically do you want to configure? You can already change the hash algorithm used by HMAC.
On Aug 23, 8:10 pm, "mr.freeze" <nat...@freezable.com> wrote: > Massimo, would you be opposed to making CRYPTs hash algorithm > configurable when hmac is used (line 1713 or validators.py)? > > On Aug 23, 7:53 pm, "mr.freeze" <nat...@freezable.com> wrote: > > > Yes, and only affects sha512 apparently. sha256 produces the same > > value on Dreamhost and my dev machine. > > > On Aug 23, 7:51 pm, Jonathan Lundell <jlund...@pobox.com> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
