On Monday 26 November 2007 12:17:51 Ned Batchelder wrote:
> In any case, if the signedcookies code makes you feel better about
> the security of your site, you should certainly use it. There's no
> point in being "disgusted" at Django as a whole.
Agreed - to put it mildly! Django uses a 128 bit
On 11/26/07, James Bennett <[EMAIL PROTECTED]> wrote:
> [1] Actually, a "secure" web application is possible. It just starts
> with not ever connecting the application to the Web. Ideally, the
> server on which the application code and database is kept will also be
> stored inside a nuclear-harden
On 11/26/07, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote:
> environment, and am rather disgusted at the current state because the
> ticket was opened 11 months ago.
>
> http://code.djangoproject.com/ticket/3285
>
> My recommendation is to incorporate code in the default session module
> which i
A couple of points:
1) the hotmail_hack story you point to is about cross-site scripting,
which has nothing to do with the security of cookies.
2) the signedcookies code you point to for inclusion in Django
explicitly discusses the idea that sessions are not vulnerable and
therefore their cook
On 11/25/07, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote:
> I'm requesting someone please fix the code to the sessions module to
> make Django secure.
I'm going to play devil's advocate here, not out of any personal
malice, but simply because it's important to have *someone* do it in a
case li
Hello,
I'm requesting someone please fix the code to the sessions module to
make Django secure. Currently Django is vulnerable to session
hijacking. Even though the length of the keys are long, a brute force
attack would not be difficult to gain access to a site until they get
a valid item in the