pre_save on password

[guillaume]

Hi list,

When registering a new user, or a password change, I need to register that user, or his new password, in another application through an internal API. I'm trying to catch the password from the different form they can be found in, but without success. Even the signal pre_save is happening too late (password is already encrypted). How can I see it just before it is encrypted ?

Thanks

Guillaume

[Rafael E. Ferrero]

I see this too dangerous... it is not a good idea save uncrypted password... too many hacker attack result on public user-password list.

Why not save encrypted password on the other application too?

Best Regards?

--
Rafael E. Ferrero

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/46c619d4-7499-4d77-afa5-01490cd06c0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rafael E. Ferrero]

Sorry... i meant Best Regards (without ? hahahaha... sorry)

--
Rafael E. Ferrero

[guillaume]

Hi,
thanks for your reply. Actually I don't want to store the uncrypted password, just submit it to another app registration system, which will hash it then. The two hashing systems are too different and complicated for me to use the django encrypted password in the other application database.

[Tom Evans]

How Django hashes passwords is fully configurable, see:

https://docs.djangoproject.com/en/1.6/topics/auth/passwords/

The setting PASSWORD_HASHERS contains a list of classes that hash
passwords. Simply replace this with your custom hash algorithm, or
calls to your external API that implements your hash algorithm.

Cheers

Tom

[guillaume]

Hi Tom,

Yes indeed, I know that page, but there is no way I can make it the same than the other one which relies on SHA256, some system key I don't know and a random salt. So there is no way for me to find the correct encryption for the remote database, that's why I want to use it's API registration system and feed it with the clear password.

Best regards

Guillaume

[Philip Mountifield]

If the username/whatever is available within the hasher you could create a subclass of the hasher you're using in Django and intercept the plain-text password there, call your API and then call the superclass?

Phil

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a7b49845-b8df-4897-b653-17020f339794%40googlegroups.com.

[guillaume]

Hi Phil,

Actually not at the hasher level, because I need to know the user's details as well, but it's a good hint. I should try to subclass to User Model set_password method.

Thanks !

Guillaume

[Tom Evans]

On Tue, Jul 1, 2014 at 1:27 PM, guillaume <guillau...@laposte.net> wrote:
> Hi Tom,
>
> Yes indeed, I know that page, but there is no way I can make it the same
> than the other one which relies on SHA256, some system key I don't know and
> a random salt. So there is no way for me to find the correct encryption for
> the remote database, that's why I want to use it's API registration system
> and feed it with the clear password.

You first post said you wanted to intercept the plain text password so
that you could supply it to a separate third party system that would
generate the hash.

This is what the hashing classes do. There are two functions you need
to implement:

encode(self, password, salt)

This function is given the plain text password and the salt, and
should return the encoded password for storage.
You can call your 3rd party system with those values in order to get
the encoded password.

verify(self, password, encoded)

This function is given the encoded password from the database, and the
plain text password as supplied by the user at login, and should
return whether the two are a match.
Again, this can call your 3rd party system in order to effect the verification.

Cheers

Tom

[Avraham Serour]

you should only store the user password once, if you are trying to catch it just to register in another application then you now have two problems

you should set django use the other system as authentication backend, new users should just register there and change their passwords there, on the central application responsible for the users, I made some applications django using this to rely on the company LDAP (active directory)

the users have the same login for all the applications in the company, the ERP, windows logon, my django web apps, email etc

and you don't need to worry about storing passwords etc

or you can do it the other way around, tell the other application to authenticate against your django users

good luck

Cheers

Tom

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFHbX1JBiyVYjtFxQ6HZCP4e52E8MPDvCYg4w8msq3BYMuJDhw%40mail.gmail.com.