Hi folks,
this is my report for this week on my summer of code. In short, I did
nothing... :) I've some stuff to be done before focusing on it, but
let me comment some things anyway.
As well as maintaining the branch on Django subversion, I'll be using
github [1] for working on my summer of code
On Sun, May 3, 2009 at 5:49 AM, Elliott wrote:
> The real problem is that the method used, as well as the salt, are
> stored on a per-user basis. Both of these would need to be known by
> the js in order to properly hash the password, but they cannot be
> known without first knowing which user wa
On May 3, 2009, at 15:34, Paul Johnston wrote:
> the security benefits of per-user salts are minor.
No.
- Ludvig
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
On Sun, May 3, 2009 at 9:46 PM, redbaron wrote:
>
> Please take a look at http://code.djangoproject.com/ticket/10987
> Personally I found it quite useful to have customizable 404 pages per
> view. I've attached small patch, please review it and put in SVN if
> its ok. I
http://docs.djangoproject
Please take a look at http://code.djangoproject.com/ticket/10987
Personally I found it quite useful to have customizable 404 pages per
view. I've attached small patch, please review it and put in SVN if
its ok. I
--~--~-~--~~~---~--~~
You received this message beca
Hi,
So Django hashes passwords server-side with a per-user salt? In that
case you do need an Ajax request at login to do the hashing. It's easy
enough to create a random (but consistent) response for non-existing
users. Or you could make it a configuration option whether Django uses
per-user or p
Exactly!! Besides the one way hashing algorithms, salt based
algorithms are also not be feasible to go with this strategy.
Thanx for clarifying this side aa well.
Regards,
M N Islam Shihan
On May 3, 2009, at 3:49 PM, Elliott wrote:
>
> On May 3, 2:51 am, "M. N. Islam Shihan" wrote:
>> It s
On May 3, 2:51 am, "M. N. Islam Shihan" wrote:
> It should be possible to provide a fallback to go with unencrypted
> authentication @ server side depending on whether a flag set at client
> side by javascript (using cookie or hidden field).
>
> Anyway, the only limitation of this technique i
It should be possible to provide a fallback to go with unencrypted
authentication @ server side depending on whether a flag set at client
side by javascript (using cookie or hidden field).
Anyway, the only limitation of this technique i see is it can't be
used in cases where the oneway hash
