On Saturday, 29 September 2012 18:39:27 UTC-5, Matt wrote:
>
> Hi there,
>
> The CRYPT function seems to behaving wildly different between 1.99.7 and
> 2.0.x.
>
yes. But it is backward compatible. Or at least it should be.
> Any new users I've added since moving to 2.0.x are recorded with longer
> encrypted passwords and existing users consequently can't login either.
>
This should not be the case. We ran extensive testing to make sure this is
not the case. The new CRYPT uses a more secure mechanism for new password
but it still understands existing passwords.
> If I run the following (both of these are using the same hmac_key btw) I
> get two different outcomes.
>
> On 1.99.7 calling:
>
> value, error = db.auth_user.password.validate('password')
> print value
>
> Returns:
>
> --> 87f0d47ce5b9a8faa298d5e28febf693
>
> Whereas on 2.0.x calling:
>
> value, error = db.auth_user.password.validate('password')
> print value
>
> Returns:
>
> -->
> pbkdf2(1000,20,sha512)$a5408c54281fd146$e6024fe1e813c310e54e29f12113ebdc3eed289b
>
> Any feedback on this would be great.
>
True, but the "value" is not a string in 2.x. value is an object that when
serialized into a string generates something like
"pbkdf2(1000,20,sha512)$a5408c54281fd146$e6024fe1e813c310e54e29f12113ebdc3eed289b"
or other depending on the CRYPT parameters. Yet when you compare value with
an old password as in "87f0d47ce5b9a8faa298d5e28febf693" == value this may
still be true if the old password corresponds to the same input password.
The internal logic is a little complicated and designed to make sure old
encrypted password still work after the upgrade. The logic is not fully
explained here but you can see the CRYPT validator has many doctests that
explain the various cases.
Yet, I understand that you are having a problem with the upgrade. I would
like to try reproduce your problem. Any chance you can post an example of
your db.py so that I generate an account with 1.99.7 and try login with 2.x
and see what may be causing the problem?
Massimo
--
