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.
