Re: Question about password salt and encryption
On Sat, Jun 15, 2013 at 2:24 PM, Luke Plant wrote: > 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. > Are you suggesting this should be a change to Django itself? A new password hasher that uses a per user salt as well as a static salt stored outside the database? Should I file this as a ticket or is this just hypothetical? -- 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 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: 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.
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.
Question about password salt and encryption
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. -- 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.
