On Mon, Jan 4, 2010 at 8:47 PM, Simon Willison wrote:
> I'm pursing expert feedback on the crypto used in Django signing /
> signed cookies. Here's the e-mail I'm sending out to various mailing
> lists. I'll also link to this post from a number of places and see if
> I can get some smart eyes on i
In this code:
def signature(self, value, salt=''):
# Derive a new key from the SECRET_KEY, using the optional salt
key = sha_constructor('signer' + self.key + salt).hexdigest()
return base64_hmac(value, key)
may I suggest putting the salt before the constant string "signer",
like this
On Mon, Jan 4, 2010 at 5:00 PM, Alex Gaynor wrote:
> So, thinking out loud here, I know the DSF has a policy of hands of in
> the development of Django, but I was thinking (out loud) that perhaps
> it would be sensible for the DSF to hire someone to do a security
> audit of some of this stuff. I
On Mon, Jan 4, 2010 at 6:00 PM, Alex Gaynor wrote:
> So, thinking out loud here, I know the DSF has a policy of hands of in
> the development of Django, but I was thinking (out loud) that perhaps
> it would be sensible for the DSF to hire someone to do a security
> audit of some of this stuff. I
> > I much prefer the @render_to() syntax. This way, I can think of my
> > view functions as "context variable creators", instead of "response
> > returners". I think of view functions as a sort of context processor
> > thats only meant for one specific template.
>
> I'm in complete agreement with
On Tuesday 05 January 2010 00:40:42 Jannis Leidel wrote:
> Maby just an odd idea but what happens if someone monkey patched
> them as lists (e.g. because the input formats weren't configurable
> until now)? Would lazy() handle this automatically given list and
> tuples are both iterables or sho
Hi Luke,
> pinging Jannis - did you see this? Can you have a look at my
> suggestion?
Mea culpa, this is indeed an issue and I like your solution of using lazy(),
since the *_INPUT_FORMATS tuples are only used for iteration.
Maby just an odd idea but what happens if someone monkey patched the
pinging Jannis - did you see this? Can you have a look at my
suggestion?
Cheers,
Luke
--
"Love is like an hourglass, with the heart filling up as the brain
empties."
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django
On Tue, Jan 5, 2010 at 1:57 AM, buttman wrote:
> On Jan 2, 5:52 pm, Simon Willison wrote:
>> On Dec 30 2009, 10:28 pm, Wim Feijen wrote:
>>
>> > In the discussions on CSRF there have been several proposals to
>> > include RequestContext by default in render_to_response or in a
>> > similar funct
On Mon, Jan 4, 2010 at 11:46 PM, Gustavo Narea
wrote:
> Hi,
>
> One more update about the WSGI related improvements for Django:
>
> I have created a Mercurial branch to keep track of these changes and
> keep them synchronized with trunk:
> http://bitbucket.org/Gustavo/django-wsgi/
>
> Even though
On Mon, Jan 4, 2010 at 4:53 PM, Luke Plant wrote:
> On Monday 04 January 2010 21:45:41 jcampbell1 wrote:
>
>> I am not that familiar with your framework, but I think a signed
>> cookie should use http only cookies by default. There is no valid
>> reason for a script to read a cookie that it can't
On Monday 04 January 2010 21:45:41 jcampbell1 wrote:
> I am not that familiar with your framework, but I think a signed
> cookie should use http only cookies by default. There is no valid
> reason for a script to read a cookie that it can't verify. http
> only cookies significantly decrease the
On Jan 4, 7:47 am, Simon Willison wrote:
> And set_signed_cookie() is here:
>
> http://github.com/simonw/django/blob/signed/django/http/__init__.py#L388
>
I am not that familiar with your framework, but I think a signed
cookie should use http only cookies by default. There is no valid
reason f
On Mon, Jan 4, 2010 at 12:34 PM, Simon Willison wrote:
> We do however need to consider the places in Django that are already
> using hmac / md5 / sha1 (contrib.formtools and middleware.csrf for
> example). Even if we don't add the signed cookies feature to 1.2,
> fixing any problems with our exis
On Jan 4, 6:18 pm, James Bennett wrote:
> Simon, the amount of pushback this is getting, and the changes which
> need to be made to start bringing it up to snuff, make me feel far too
> nervous about this being ready in time to make 1.2 at all. I know
> you've put in the effort to shepherd this al
On Jan 2, 5:52 pm, Simon Willison wrote:
> On Dec 30 2009, 10:28 pm, Wim Feijen wrote:
>
> > In the discussions on CSRF there have been several proposals to
> > include RequestContext by default in render_to_response or in a
> > similar function. As a side note to my previous post, I'd like to
>
Simon, the amount of pushback this is getting, and the changes which
need to be made to start bringing it up to snuff, make me feel far too
nervous about this being ready in time to make 1.2 at all. I know
you've put in the effort to shepherd this along, but I'm starting to
think it's time to push
I think this is a great addition to Django. I wanted to comment on
some of the issues being discussed and hopefully provide a little
insight into the _why_ of it all.
SHA-1 is perfectly fine for HMAC (as verified by Bruce Schneier, NIST,
and several others). Here's why:
SHA-1
==
plaintext
If we do end up using SHA-256 (which I don't think is necessary) we
could always truncate the result. If the original hash is
cryptographically secure then a truncated version is too. It just
increases the likelihood of a collision.
Mike
On Jan 4, 2010, at 6:49 AM, Simon Willison
wrote:
Malcolm had some good comments when all of this was discussed
previously:
http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad
He also seemed to have further ideas and code, perhaps he can be
pinged for sharing them.
Best,
MS
--
You received t
Hi,
One more update about the WSGI related improvements for Django:
I have created a Mercurial branch to keep track of these changes and
keep them synchronized with trunk:
http://bitbucket.org/Gustavo/django-wsgi/
Even though I know it's late for 1.2 at this point, please keep in mind
that part
Yes, multiple database support was merged into trunk on December 22:
http://www.djangoproject.com/multidb-changeset/
Alex
On Mon, Jan 4, 2010 at 9:40 AM, Joe wrote:
> Has this code been merged to a 1.2 alpha build somewhere or is the
> multi-db branch still the current release? Only asking beca
Has this code been merged to a 1.2 alpha build somewhere or is the
multi-db branch still the current release? Only asking because the
first message in the thread indicated a schedule which meant the code
would be merged in before EOY and I just want to make sure I'm on the
right codebase moving fo
On Jan 4, 2:45 pm, Jordan Christensen wrote:
> Is there a good way to make it forward upgradeable? Allow the
> developer to decide on the shorter SHA-1 hash or the (theoretically)
> more secure SHA-256?
There is - we can expand the BACKEND setting which is already in place
for signed cookies (but
The timestamp is necessary to limit replay attacks, and so it should
probably be more than optional - always issued, and checked by
default. The danger is that users might think "signing" is a
bulletproof guarantee that the cookie as received is exactly the
latest cookie issued to that unique user
NIST seems to agree that SHA-1 is ok for HMAC as well:
http://csrc.nist.gov/groups/ST/hash/statement.html
"There are many applications of hash functions, and many do not
require strong collision resistance; for example, keyed hash
applications, such as the Hash-based Message Authentication Code
(
Had some good feedback on news.ycombinator and programming.reddit -
you can follow the threads here:
http://news.ycombinator.com/item?id=1030290
http://www.reddit.com/r/programming/comments/ald1m/calling_crypto_security_experts_help_review_the/
tptacek on news.ycombinator pointed out a timing att
>From Jordan Christensen on Twitter:
>http://twitter.com/thebigjc/status/7366243197
"@simonw why sha-1 instead of sha-256? NIST has recommended not using
SHA-1 in new systems: http://bit.ly/6bIf5h";
I chose sha-1 over sha-256 for reasons of signature length. A base64
encoded signature generated
Is there any more documentation that I should write before the feature
freeze tomorrow?
Thanks,
Ben
On 22 Dec 2009, at 00:39, Ben Firshman wrote:
>
> On 21 Dec 2009, at 20:06, Luke Plant wrote:
>>> I've documented it in some detail in the release notes. Is this
>>> painstaking enough?
>>
>> U
I'm pursing expert feedback on the crypto used in Django signing /
signed cookies. Here's the e-mail I'm sending out to various mailing
lists. I'll also link to this post from a number of places and see if
I can get some smart eyes on it that way.
Hello,
We'v
Hi all,
If you have been using the new email backend feature in trunk, you
should be aware that SVN revision 12084 introduces a small, but
backwards-incompatible change.
If you are using Django 1.1 (i.e., Django stable), or you haven't
manually specified EMAIL_BACKEND in your settings file, you w
31 matches
Mail list logo
