On Jan 4, 4:47 am, Simon Willison wrote:
> As you can see, the separator between the signature and the value
> defaults to being a ':'. I plan to move it from being an argument on
> the sign and unsign methods to being an argument to the Signer class
> constructor.
Here's my $.02 based on a curso
On Wednesday 06 January 2010 17:12:29 Elias Torres wrote:
> > So that would be my defence of why it's better to put the
> > "purpose" namespace into the key, rather than the value, in the
> > context of HMAC. I'm not an expert though.
>
> Can a separator solve that issue?
In that instance, yes.
On Jan 6, 10:37 am, Luke Plant wrote:
> On Wednesday 06 January 2010 04:24:15 Elias Torres wrote:
> > Thanks Luke for your explanation. I think I have learned something
> > here in terms of my own application security independent of
> > Django's multi-app environment. Basically, you're remindin
On Wednesday 06 January 2010 04:24:15 Elias Torres wrote:
> Thanks Luke for your explanation. I think I have learned something
> here in terms of my own application security independent of
> Django's multi-app environment. Basically, you're reminding me
> that as an application, I must be carefu
On Jan 5, 2:33 pm, Luke Plant wrote:
> On Tuesday 05 January 2010 16:53:17 Elias Torres wrote:
>
> > Simon,
>
> > I'm not a security expert by any means, but I really the fact that
> > you're making use of HMACs in your design. I will ask a good friend
> > (Ben Adida) who's really an expert on the
oops.. I mean really *like*. Thanks.
On Jan 5, 12:09 pm, Karen Tracey wrote:
> On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres wrote:
>
> > I'm not a security expert by any means, but I really the fact that
> > you're making use of HMACs in your design.
>
> There seems to be a key word missing her
On Tuesday 05 January 2010 16:53:17 Elias Torres wrote:
> Simon,
>
> I'm not a security expert by any means, but I really the fact that
> you're making use of HMACs in your design. I will ask a good friend
> (Ben Adida) who's really an expert on the subject to see if your
> paranoia on adding a sa
On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres wrote:
>
> I'm not a security expert by any means, but I really the fact that
> you're making use of HMACs in your design.
>
There seems to be a key word missing here: really the fact...
(One might guess based on the rest of the message, but still
Simon,
I'm not a security expert by any means, but I really the fact that
you're making use of HMACs in your design. I will ask a good friend
(Ben Adida) who's really an expert on the subject to see if your
paranoia on adding a salt and hashing the key helps you in any way. My
intuition says if th
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
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
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:
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
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
27 matches
Mail list logo