I see, I really had not give much though to the points that you make. I guess the secret salt really does create some possible inconvenience and should be feature left up to developers to implement as you say. Thanks for the input.
On Dec 7, 6:37 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Tue, Dec 7, 2010 at 2:27 PM, andy <flowar...@gmail.com> wrote: > > However I'm a bit curious about the significance of adding a second > > salt to the password before it is hashed and then using the regular > > per-user salt. Currently my opinion is that their is added benefit > > since it make dictionary attacks more challenging and possibly almost > > impossibly if the attacker does not know the hidden salt. Django has a > > secretKey in the setting file I wondering why this could not have been > > used as second salt in the authentication system. > > The problem with this is that if you ever have to change your secret > key (e.g., your settings.py file is compromised), then all passwords > will be invalidated. And not in a friendly way, either. With > per-user salts, if you need to invalidate a user's password, you can > allow them to log in with the old password and then require them to > change their password. With a secret key in the salt, if you change > the secret key, then the old passwords will no longer work at all. > > Some users may not mind this, but it would be undesirable for core. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
