Quantcast

Add ability to choose a different secret for PasswordResetToken

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Add ability to choose a different secret for PasswordResetToken

django-developers mailing list
Hi everybody,

I have two sites in my project. One is for internal use to add members of our club to our database, one is a self-service page for our members.
On registration of a member using our internal site, I want to send a password reset link to the member for easy registration to our self-service page.
Since the two sites run on different servers and different SECRET_KEYs, I need to specify a different secret for the token generated with our internal site to work on the self-service page.
I managed to do so by overwriting the method _make_token_with_timestamp of PasswordResetToken, however, I think this is quite an ugly solution.

How would you think about the secret being an attribute of the PasswordResetToken class, which is then passed to salted_hmac? The default could be settings.SECRET_KEY for backwards compatibility.

I have so far not contributed to django, but I would like to start and I believe, this small change might be a good start. If you agree, I could open a ticket in trac.

Best Regards,
Jann

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add ability to choose a different secret for PasswordResetToken

Adam Johnson-2
Presumably you mean PasswordResetTokenGenerator when you write PasswordResetToken.

Seems like a fairly small feature, but my security sense is tingling when you say you're putting the secret key of one application in a variable for another.

Normally in a situation where multiple applications need to share login data, I would consider having a centralized application for identity management.

Also in your current structure, you don't necessarily need to replace _make_token_with_timestamp (which is prone to break if Django changes that code) - you could (somewhat hackily) wrap with override_settings(SECRET_KEY=other_key) around your call to PasswordResetTokenGenerator.make_token.

On 17 March 2017 at 20:54, jann.haber via Django developers (Contributions to Django itself) <[hidden email]> wrote:
Hi everybody,

I have two sites in my project. One is for internal use to add members of our club to our database, one is a self-service page for our members.
On registration of a member using our internal site, I want to send a password reset link to the member for easy registration to our self-service page.
Since the two sites run on different servers and different SECRET_KEYs, I need to specify a different secret for the token generated with our internal site to work on the self-service page.
I managed to do so by overwriting the method _make_token_with_timestamp of PasswordResetToken, however, I think this is quite an ugly solution.

How would you think about the secret being an attribute of the PasswordResetToken class, which is then passed to salted_hmac? The default could be settings.SECRET_KEY for backwards compatibility.

I have so far not contributed to django, but I would like to start and I believe, this small change might be a good start. If you agree, I could open a ticket in trac.

Best Regards,
Jann

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1HSZhwVzU9pNuUHv28cWeRqc6n22PzsPk9Zgo_wtedQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add ability to choose a different secret for PasswordResetToken

django-developers mailing list
Thank you for your input. Yes I meant the PasswordResetTokenGenerator, sorry for this.

It agree, it would be a fairly small addition to Django, however there doesn't seem to be an easy (non-hackish) way to get around. Since the impact on Django would be very small, I wanted to share my thoughts here.
In our scenario, the self-service site is basically a small subset of our internal site. So if somebody would gain access to our interal site, he/she would already have access to a superset of data of the other site. So there is really no point to also take over to the other site.

I'll give the override_settings a closer look, but this seems like something one wouldn't want in a production environment.

Am Samstag, 18. März 2017 10:32:06 UTC+1 schrieb Adam Johnson:
Presumably you mean PasswordResetTokenGenerator when you write PasswordResetToken.

Seems like a fairly small feature, but my security sense is tingling when you say you're putting the secret key of one application in a variable for another.

Normally in a situation where multiple applications need to share login data, I would consider having a centralized application for identity management.

Also in your current structure, you don't necessarily need to replace _make_token_with_timestamp (which is prone to break if Django changes that code) - you could (somewhat hackily) wrap with override_settings(SECRET_KEY=other_key) around your call to PasswordResetTokenGenerator.make_token.

On 17 March 2017 at 20:54, jann.haber via Django developers (Contributions to Django itself) <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="CxjP8z_QBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com> wrote:
Hi everybody,

I have two sites in my project. One is for internal use to add members of our club to our database, one is a self-service page for our members.
On registration of a member using our internal site, I want to send a password reset link to the member for easy registration to our self-service page.
Since the two sites run on different servers and different SECRET_KEYs, I need to specify a different secret for the token generated with our internal site to work on the self-service page.
I managed to do so by overwriting the method _make_token_with_timestamp of PasswordResetToken, however, I think this is quite an ugly solution.

How would you think about the secret being an attribute of the PasswordResetToken class, which is then passed to salted_hmac? The default could be settings.SECRET_KEY for backwards compatibility.

I have so far not contributed to django, but I would like to start and I believe, this small change might be a good start. If you agree, I could open a ticket in trac.

Best Regards,
Jann

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="CxjP8z_QBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="CxjP8z_QBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.



--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4e1c275f-1ea5-482d-affa-e70b95ffac24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add ability to choose a different secret for PasswordResetToken

Collin Anderson-2
"the self-service site is basically a small subset of our internal site. So if somebody would gain access to our interal site, he/she would already have access to a superset of data of the other site. So there is really no point to also take over to the other site."

Just curious: why not just use the same SECRET_KEY for both sites?

On Sat, Mar 18, 2017 at 6:11 AM, jann.haber via Django developers (Contributions to Django itself) <[hidden email]> wrote:
Thank you for your input. Yes I meant the PasswordResetTokenGenerator, sorry for this.

It agree, it would be a fairly small addition to Django, however there doesn't seem to be an easy (non-hackish) way to get around. Since the impact on Django would be very small, I wanted to share my thoughts here.
In our scenario, the self-service site is basically a small subset of our internal site. So if somebody would gain access to our interal site, he/she would already have access to a superset of data of the other site. So there is really no point to also take over to the other site.

I'll give the override_settings a closer look, but this seems like something one wouldn't want in a production environment.

Am Samstag, 18. März 2017 10:32:06 UTC+1 schrieb Adam Johnson:
Presumably you mean PasswordResetTokenGenerator when you write PasswordResetToken.

Seems like a fairly small feature, but my security sense is tingling when you say you're putting the secret key of one application in a variable for another.

Normally in a situation where multiple applications need to share login data, I would consider having a centralized application for identity management.

Also in your current structure, you don't necessarily need to replace _make_token_with_timestamp (which is prone to break if Django changes that code) - you could (somewhat hackily) wrap with override_settings(SECRET_KEY=other_key) around your call to PasswordResetTokenGenerator.make_token.

On 17 March 2017 at 20:54, jann.haber via Django developers (Contributions to Django itself) <[hidden email]> wrote:
Hi everybody,

I have two sites in my project. One is for internal use to add members of our club to our database, one is a self-service page for our members.
On registration of a member using our internal site, I want to send a password reset link to the member for easy registration to our self-service page.
Since the two sites run on different servers and different SECRET_KEYs, I need to specify a different secret for the token generated with our internal site to work on the self-service page.
I managed to do so by overwriting the method _make_token_with_timestamp of PasswordResetToken, however, I think this is quite an ugly solution.

How would you think about the secret being an attribute of the PasswordResetToken class, which is then passed to salted_hmac? The default could be settings.SECRET_KEY for backwards compatibility.

I have so far not contributed to django, but I would like to start and I believe, this small change might be a good start. If you agree, I could open a ticket in trac.

Best Regards,
Jann

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ca9e1cde-002d-491b-899a-02bfd50fbed6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4e1c275f-1ea5-482d-affa-e70b95ffac24%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFO84S48FxQXoZt8H2_Uf7xR0%2BfGgOexGJijQNjwThx7zcHdQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add ability to choose a different secret for PasswordResetToken

Florian Apolloner
In reply to this post by django-developers mailing list


On Saturday, March 18, 2017 at 11:11:38 AM UTC+1, [hidden email] wrote:
I'll give the override_settings a closer look, but this seems like something one wouldn't want in a production environment.

Yes, this is only ment for tests.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f317bb66-6565-4062-9c1b-db9b41250b0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...