Re: Question about password salt and encryption
On Jun 15, 2013, at 5:24 PM, Luke Plant wrote: > On 15/06/13 14:17, Jon Dufresne wrote: > >> I guess I need to decide which way to go. Either a custom password >> hasher that uses a static salt, or use Django's existing password hasher >> and not think about it. > > There are two questions here: > > 1) What should you do for your system? > > 2) Should Django's security be improved by an additional salt that isn't > stored in the database? > > Regarding number 2, this is not likely to happen quickly, due to > backwards compatibility issues, and the need to introduce a new setting > etc. (That may help you to decide question 1). > > It's definitely worth considering, of course. We would have to consider > whether it is worth the work. For many installations, if an attacker has > the database they are very likely to have the source code too. Of > course, we should try to layer security so that it isn't all or nothing. > But given the difficulties of changing things, we'd have to consider > whether the increase in security, in a typical setup, would justify the > change. > > Regards, > > Luke > > -- > "Pessimism: Every dark cloud has a silver lining, but lightning > kills hundreds of people each year trying to find it." (despair.com) > > Luke Plant || http://lukeplant.me.uk/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > Backwards compatibility is easy. Just add a new hasher. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Question about password salt and encryption
On 15/06/13 14:17, Jon Dufresne wrote: > I guess I need to decide which way to go. Either a custom password > hasher that uses a static salt, or use Django's existing password hasher > and not think about it. There are two questions here: 1) What should you do for your system? 2) Should Django's security be improved by an additional salt that isn't stored in the database? Regarding number 2, this is not likely to happen quickly, due to backwards compatibility issues, and the need to introduce a new setting etc. (That may help you to decide question 1). It's definitely worth considering, of course. We would have to consider whether it is worth the work. For many installations, if an attacker has the database they are very likely to have the source code too. Of course, we should try to layer security so that it isn't all or nothing. But given the difficulties of changing things, we'd have to consider whether the increase in security, in a typical setup, would justify the change. Regards, Luke -- "Pessimism: Every dark cloud has a silver lining, but lightning kills hundreds of people each year trying to find it." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
Hi Amir, On Jun 15, 2013, at 9:11 AM, Amir Rachum wrote: > I'm not sure if this feature was discussed before (I've seen some mentions of > it when searching this group, but nothing definitive). > I have written a blog post regarding the reasons (and the suggested syntax) > to use this relationship, and would love some feedback > > http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django The strongest reason not to do this is that it breaks the correspondence between model fields and database columns. If you added a new OneToMany field on Band pointing to Musician, suddenly the (unmodified) Musician model's db table would require a schema migration, while the Band table would remain unchanged. (Yes, ManyToManyField already sort of breaks this correspondence, but only in that it causes a new table to be created in the same app where you added the field. It never requires a schema migration for an untouched model class, possibly in a different app, which is much worse.) I think this downside alone is enough to kill the proposal for Django core, especially considering the rationale in favor isn't that strong; it's just a new way to spell the exact equivalent of a ForeignKey. That said, I'm pretty sure you could code this up outside of core, if you'd like to experiment with it. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
Hello Amir, you've mentioned only definiton of model. Yes, it looks interesting and definitely more readable. But definition of model is just the begining. At database level, these models would be represented in the same way. (No difference) Working with models would be similar or even the same as it's now: ``member.group = band`` or ``band.members.add(member)`` Again, I don't see any difference. There would be probably some constraint when you try delete member of band which doesn't have any other members. Now, that could be implemented using pre_delete/post_delete signals. It looks for me that the only difference is in readability of models.py. What am I missing? Cheers, Tomas Ehrlich Dne Sat, 15 Jun 2013 08:11:53 -0700 (PDT) Amir Rachum napsal(a): > Hi there, > > I'm not sure if this feature was discussed before (I've seen some mentions > of it when searching this group, but nothing definitive). > I have written a blog post regarding the reasons (and the suggested syntax) > to use this relationship, and would love some feedback > > http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django > > Thanks, > Amir Rachum > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adding a OneToMany Relationship to Django
It seems to me that "there should be one--and preferably only one--way to do it." This would entail having two ways. Sometimes that makes sense if they're distinct enough things conceptually, but personally I don't see that case. Best Regards, Luke Sneeringer Sent from my iPhone. Forgive us our typos as we forgive those who typo against us. > On Jun 15, 2013, at 9:11 AM, Amir Rachum wrote: > > Hi there, > > I'm not sure if this feature was discussed before (I've seen some mentions of > it when searching this group, but nothing definitive). > I have written a blog post regarding the reasons (and the suggested syntax) > to use this relationship, and would love some feedback > > http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django > > Thanks, > Amir Rachum > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Adding a OneToMany Relationship to Django
Hi there, I'm not sure if this feature was discussed before (I've seen some mentions of it when searching this group, but nothing definitive). I have written a blog post regarding the reasons (and the suggested syntax) to use this relationship, and would love some feedback http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django Thanks, Amir Rachum -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Localization and Forms with Currencyfields / Value
Hi Christian, Could you clarify why DecimalField doesn't work for your use case? I suspect you're encountering problems related to localization, but I'm not sure. Thanks, -- Aymeric. On 15 juin 2013, at 11:35, Christian Schmitt wrote: > In Django it is nearly impossible to deal with currency values, intcomma > would make values to currency and it will work on Django 1.6a1 with Decimals, > but still when I have a ModelForm or Form I can't validate a > intcomma(Decimal()) Value. It will always be incorrect. > Maybe its time now to let Django have a CurrencyField in core or even better > functions for dealing with currency values. > > I mean I would maybe contribute something to django, but maybe i'm too scared > that my code isn't correct or even not that good to get contributed. > It would just be another improvement for django when the handling of > Currencies would be less worse than it is now. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Question about password salt and encryption
On 15 juin 2013, at 15:17, Jon Dufresne wrote: > I guess I need to decide which way to go. Either a custom password hasher > that uses a static salt, or use Django's existing password hasher and not > think about it. The first option is a very thin addition on top of Django's authentication framework. Many parts of Django are pluggable precisely to allow such customizations. I view it as standing on the shoulders of giants rather than NIH. To make the migration easier, you'll probably put your current salt value in a setting distinct from SECRET_KEY. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Question about password salt and encryption
Thank you Luke. On Sat, Jun 15, 2013 at 12:55 AM, Luke Plant wrote: > The reason that SECRET_KEY is not used is that SECRET_KEY is used for > other applications which might require key cycling - typically for short > lived data where key cycling isn't going to cause too much of a problem. > > So if it was used as a salt for passwords, you would lose the ability to > check passwords when you cycled the key. > > That consideration doesn't stop you from using another value as a salt, > of course. > > If you are trying to get authentication to match an existing system, it > seems like a better approach would be to write a custom Django > authentication backend, rather than the other way around, especially if > you don't want to lose the security features of what you have already: > > > https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#writing-an-authentication-backend > > >From reading the Django documentation, it appears I would need to create a custom password hasher that is identical to the default hasher, but passes (salt + settings.SECRET_KEY) to the pbkdf2() function instead of simply salt. This seems easy enough in principle. However, part of the appeal and motivation for porting the existing application to Django is moving away from the NIH of the existing application. Django gets so much of the foundation right. The existing application is currently implementing all this foundation itself; sometimes it does a good job, other times a poor job. I don't claim to be an expert on password encryption, so I would prefer to leave that sort of thing to the people that are smarter than me. This seems like I'd be losing a small portion of that value. I'd have to once again be implementing a piece of the password hasher. I guess I need to decide which way to go. Either a custom password hasher that uses a static salt, or use Django's existing password hasher and not think about it. Thanks for the help. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Localization and Forms with Currencyfields / Value
In Django it is nearly impossible to deal with currency values, intcomma would make values to currency and it will work on Django 1.6a1 with Decimals, but still when I have a ModelForm or Form I can't validate a intcomma(Decimal()) Value. It will always be incorrect. Maybe its time now to let Django have a CurrencyField in core or even better functions for dealing with currency values. I mean I would maybe contribute something to django, but maybe i'm too scared that my code isn't correct or even not that good to get contributed. It would just be another improvement for django when the handling of Currencies would be less worse than it is now. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Question about password salt and encryption
Hi Jon, > I am in the process of porting an existing application to use Django. I > am modifying the authentication portion of the existing application to > be compatible with Django's authentication system. One thing that struck > me, Django appears to use a single per user salt, stored in the > database. However, the existing application uses two salts, one static > salt stored outside the database, and a per user salt stored in the > database. From all the advice I've received about secure authentication > it seems the two salt method is standard behavior and considered a best > practice. Is there a reason Django does not use the SECRET_KEY (or some > other static salt) when encrypting passwords? Is this still considered a > secure encryption mechanism? This feels like a step backwards for the > authentication of this application. The reason that SECRET_KEY is not used is that SECRET_KEY is used for other applications which might require key cycling - typically for short lived data where key cycling isn't going to cause too much of a problem. So if it was used as a salt for passwords, you would lose the ability to check passwords when you cycled the key. That consideration doesn't stop you from using another value as a salt, of course. If you are trying to get authentication to match an existing system, it seems like a better approach would be to write a custom Django authentication backend, rather than the other way around, especially if you don't want to lose the security features of what you have already: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#writing-an-authentication-backend Regards, Luke -- "Pessimism: Every dark cloud has a silver lining, but lightning kills hundreds of people each year trying to find it." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
