corrections. These are both 64 bits machines. the python version on
Dreamhost is the oldest. This means the bug has been fixed already but
dreamhost does not know.
Massimo
On Aug 23, 7:32 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I will email Guido.
>
> 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
-~----------~----~----~----~------~----~------~--~---
