I was getting interested in how Pyramid's authentication works and looked through the commonly used AuthTktAuthenticationPolicy code. I found out it uses MD5 and the only thing keeping the cookie from being forged is the secret.
I see two different issues here: First, MD5 is already known to have weaknesses<http://en.wikipedia.org/wiki/Md5#Security>and it would be a good idea to have different algorithms available so they can be set. This shouldn't be very hard to implement (I can write a patch if you desire) and it can improve the security of any site. Second, since everything depends on the single secret, I think it should be documented better (communicated on at least the docstring and the documentation<http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/securit...>) that the secret has to be strong (long, random, maybe state a minimum length).
This sums up my concerns but I will go into detail to give some explanation to my concerns.
I want to start off with saying that I searched the issue tracker, looked at current feature branches, searched this list and searched through google but couldn't find anything that addresses this issue.
Now on to the details: The basic problem I see is that if you hand over a cookie to a user, he can try to bruteforce (or attack intelligently with MD5 collision attacks and such, see above) and find the secret. This allows him to log in as any user on the system and the complete security of the system can depend on the security of this mechanism. Now if your secret and algorithm are strong enough then you could use this mechanism as a simple but secure approach for authentication. But with a short / unsecure secret your whole system breaks. This is why I recommend better documentation to make sure a deveolper insures a strong secret (that is different for each installation that is deployed) is used in his application. Additionally you could provide help on how to generate such a secret (but that's extra candy). I have looked through various parts of the documentation and it is always set to something like 'seekrit' and similar, but it is never mentioned how to make sure that this is secure.
I get that MD5 is widely spread and easy to deploy, but how about offering an interface to add additional algorithms and document that (of course)? You could just add an additional parameter that, if set, will use the digest algorithm passed to it (e.g. SHA1, SHA256 or maybe even an HMAC where the secret is your key). To furthermore increase the security you could use multiple hashings and key derivation (see bcrypt<http://en.wikipedia.org/wiki/Bcrypt>). Nothing will help if the secret is weak but brute-forcing is made harder if such a mechanism is used.
Of course, the authentication policy should be simple and is not considered the most secure (because for this you would need persisent data storage on the server's side and that should not be a requirement to deploy authentication). But I feel if every possible angle is used, you could at least give developers more power and awareness on their site's security.
Thank you for your attention, I would love to hear some feedback on this. Maybe I am wrong and in this case please say so.
On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote:
> I was getting interested in how Pyramid's authentication works and
> looked through the commonly used AuthTktAuthenticationPolicy code. I
> found out it uses MD5 and the only thing keeping the cookie from being
> forged is the secret.
> I see two different issues here:
> First, MD5 is already known to have weaknesses and it would be a good
> idea to have different algorithms available so they can be set. This
> shouldn't be very hard to implement (I can write a patch if you
> desire) and it can improve the security of any site.
> Second, since everything depends on the single secret, I think it
> should be documented better (communicated on at least the docstring
> and the documentation) that the secret has to be strong (long, random,
> maybe state a minimum length).
It would be fine by me if we made it possible to change the hashing
algorithm. But it probably needs to continue to support md5, because
it's purpose is to be compatible with Apache mod_auth_tkt cookies. I
would be happy to accept a patch that allowed folks to plug in a
different hashing algorithm, and explain to them that if they do, it
will no longer be compatible with those cookies.
There are also existing options that can help make it stronger
regardless of the hash, such as including the IP in the token, IIRC.
On Sun, Sep 9, 2012 at 4:56 PM, Chris McDonough <chr...@plope.com> wrote:
> On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote:
> > I was getting interested in how Pyramid's authentication works and
> > looked through the commonly used AuthTktAuthenticationPolicy code. I
> > found out it uses MD5 and the only thing keeping the cookie from being
> > forged is the secret.
> > I see two different issues here:
> > First, MD5 is already known to have weaknesses and it would be a good
> > idea to have different algorithms available so they can be set. This
> > shouldn't be very hard to implement (I can write a patch if you
> > desire) and it can improve the security of any site.
> > Second, since everything depends on the single secret, I think it
> > should be documented better (communicated on at least the docstring
> > and the documentation) that the secret has to be strong (long, random,
> > maybe state a minimum length).
> It would be fine by me if we made it possible to change the hashing
> algorithm. But it probably needs to continue to support md5, because
> it's purpose is to be compatible with Apache mod_auth_tkt cookies. I
> would be happy to accept a patch that allowed folks to plug in a
> different hashing algorithm, and explain to them that if they do, it
> will no longer be compatible with those cookies.
> There are also existing options that can help make it stronger
> regardless of the hash, such as including the IP in the token, IIRC.
> - C
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> On Sun, Sep 9, 2012 at 4:56 PM, Chris McDonough <chr...@plope.com>
> wrote:
> On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote:
> > I was getting interested in how Pyramid's authentication
> works and
> > looked through the commonly used AuthTktAuthenticationPolicy
> code. I
> > found out it uses MD5 and the only thing keeping the cookie
> from being
> > forged is the secret.
> > I see two different issues here:
> > First, MD5 is already known to have weaknesses and it would
> be a good
> > idea to have different algorithms available so they can be
> set. This
> > shouldn't be very hard to implement (I can write a patch if
> you
> > desire) and it can improve the security of any site.
> > Second, since everything depends on the single secret, I
> think it
> > should be documented better (communicated on at least the
> docstring
> > and the documentation) that the secret has to be strong
> (long, random,
> > maybe state a minimum length).
> It would be fine by me if we made it possible to change the
> hashing
> algorithm. But it probably needs to continue to support md5,
> because
> it's purpose is to be compatible with Apache mod_auth_tkt
> cookies. I
> would be happy to accept a patch that allowed folks to plug in
> a
> different hashing algorithm, and explain to them that if they
> do, it
> will no longer be compatible with those cookies.
> There are also existing options that can help make it stronger
> regardless of the hash, such as including the IP in the token,
> IIRC.
> - C
> --
> You received this message because you are subscribed to the
> Google Groups "pylons-devel" group.
> To post to this group, send email to
> pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to pylons-devel
> +unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> -- > You received this message because you are subscribed to the Google
> Groups "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to pylons-devel
> +unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> > On Sun, Sep 9, 2012 at 4:56 PM, Chris McDonough <chr...@plope.com>
> > wrote:
> > On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote:
> > > I was getting interested in how Pyramid's authentication
> > works and
> > > looked through the commonly used AuthTktAuthenticationPolicy
> > code. I
> > > found out it uses MD5 and the only thing keeping the cookie
> > from being
> > > forged is the secret.
> > > I see two different issues here:
> > > First, MD5 is already known to have weaknesses and it would
> > be a good
> > > idea to have different algorithms available so they can be
> > set. This
> > > shouldn't be very hard to implement (I can write a patch if
> > you
> > > desire) and it can improve the security of any site.
> > > Second, since everything depends on the single secret, I
> > think it
> > > should be documented better (communicated on at least the
> > docstring
> > > and the documentation) that the secret has to be strong
> > (long, random,
> > > maybe state a minimum length).
> > It would be fine by me if we made it possible to change the
> > hashing
> > algorithm. But it probably needs to continue to support md5,
> > because
> > it's purpose is to be compatible with Apache mod_auth_tkt
> > cookies. I
> > would be happy to accept a patch that allowed folks to plug in
> > a
> > different hashing algorithm, and explain to them that if they
> > do, it
> > will no longer be compatible with those cookies.
> > There are also existing options that can help make it stronger
> > regardless of the hash, such as including the IP in the token,
> > IIRC.
> > - C
> > --
> > You received this message because you are subscribed to the
> > Google Groups "pylons-devel" group.
> > To post to this group, send email to
> > pylons-devel@googlegroups.com.
> > To unsubscribe from this group, send email to pylons-devel
> > +unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/pylons-devel?hl=en.
> > --
> > You received this message because you are subscribed to the Google
> > Groups "pylons-devel" group.
> > To post to this group, send email to pylons-devel@googlegroups.com.
> > To unsubscribe from this group, send email to pylons-devel
> > +unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/pylons-devel?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
I dislike md5 as much as the next guy, but auth_tkt uses a double hashing
scheme that is almost hmac. Hmac overcomes most of the problems of an
otherwise weak hash function. It isn't as bad as you might think.
The sha2 functions are a great replacement. Sha2 auth_tkt is what I would
use. Sha1 is discouraged these days. You don't need bcrypt because the
secret you are protecting is very long. Password hashing functions are not
MACs.
On Sunday, September 9, 2012 8:23:45 PM UTC+2, Domen Kožar wrote:
> Florian: do you plan to provide a patch?
I am willing to provide a patch but I am new to pyramid and would definitely need someone to double check which places need changing. For example we need a dynamic split depending on the algorithm used as otherwise we cannot determine where the hash ends and the timestamp begins. Furthermore, I don't know which other parts might use the digest parts (so they would need change, too). And last, I haven't looked into tests yet. If they cover this, they should at least be extended to also test a different algorithm.
If someone is willing to help me, then yes, I would like to develop this. It might take some time though, so if someone is eager to get this quickly (like by the end of this week, i.e. on Sunday, 16th), then I am probably not the right guy right know. I could probably do it by the end of next week)
>> > On Sun, Sep 9, 2012 at 4:56 PM, Chris McDonough <chr...@plope.com<javascript:>
>> > wrote:
>> > On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote:
>> > > I was getting interested in how Pyramid's authentication
>> > works and
>> > > looked through the commonly used AuthTktAuthenticationPolicy
>> > code. I
>> > > found out it uses MD5 and the only thing keeping the cookie
>> > from being
>> > > forged is the secret.
>> > > I see two different issues here:
>> > > First, MD5 is already known to have weaknesses and it would
>> > be a good
>> > > idea to have different algorithms available so they can be
>> > set. This
>> > > shouldn't be very hard to implement (I can write a patch if
>> > you
>> > > desire) and it can improve the security of any site.
>> > > Second, since everything depends on the single secret, I
>> > think it
>> > > should be documented better (communicated on at least the
>> > docstring
>> > > and the documentation) that the secret has to be strong
>> > (long, random,
>> > > maybe state a minimum length).
>> > It would be fine by me if we made it possible to change the
>> > hashing
>> > algorithm. But it probably needs to continue to support md5,
>> > because
>> > it's purpose is to be compatible with Apache mod_auth_tkt
>> > cookies. I
>> > would be happy to accept a patch that allowed folks to plug in
>> > a
>> > different hashing algorithm, and explain to them that if they
>> > do, it
>> > will no longer be compatible with those cookies.
>> > There are also existing options that can help make it stronger
>> > regardless of the hash, such as including the IP in the token,
>> > IIRC.
>> > - C
>> > --
>> > You received this message because you are subscribed to the
>> > Google Groups "pylons-devel" group.
>> > To post to this group, send email to
>> > pylons...@googlegroups.com <javascript:>.
>> > To unsubscribe from this group, send email to pylons-devel
>> > +unsub...@googlegroups.com <javascript:>.
>> > For more options, visit this group at
>> > http://groups.google.com/group/pylons-devel?hl=en.
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "pylons-devel" group.
>> > To post to this group, send email to pylons...@googlegroups.com<javascript:>
>> .
>> > To unsubscribe from this group, send email to pylons-devel
>> > +unsub...@googlegroups.com <javascript:>.
>> > For more options, visit this group at
>> > http://groups.google.com/group/pylons-devel?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups >> "pylons-devel" group.
>> To post to this group, send email to pylons...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to >> pylons-devel...@googlegroups.com <javascript:>.
>> For more options, visit this group at >> http://groups.google.com/group/pylons-devel?hl=en.
On Sun, 2012-09-09 at 12:25 -0700, Florian Rüchel wrote:
> On Sunday, September 9, 2012 8:23:45 PM UTC+2, Domen Kožar wrote:
> Florian: do you plan to provide a patch?
> I am willing to provide a patch but I am new to pyramid and would
> definitely need someone to double check which places need changing.
> For example we need a dynamic split depending on the algorithm used as
> otherwise we cannot determine where the hash ends and the timestamp
> begins. Furthermore, I don't know which other parts might use the
> digest parts (so they would need change, too). And last, I haven't
> looked into tests yet. If they cover this, they should at least be
> extended to also test a different algorithm.
> If someone is willing to help me, then yes, I would like to develop
> this. It might take some time though, so if someone is eager to get
> this quickly (like by the end of this week, i.e. on Sunday, 16th),
> then I am probably not the right guy right know. I could probably do
> it by the end of next week)
Four tests in "pyramid.tests.test_authentication.TestAuthTktCookieHelper" worry me: They do something like values = self._parseHeaders(result) val = self._cookieValue(values[0]) Which fails with return eval(cookie.value) {'secure': False, 'remote_addr': '0.0.0.0', 'cookie_name': 'auth_tkt', 'userid': 'dXNlcmlk', 'user_data': 'userid_type:b64str', 'hashalg': <built-in function openssl_md5>, 'tokens': (), 'secret': 'secret'} SyntaxError: invalid syntax
Unfortunately, I don't understand the purpose of those tests. Thus, I can't fix them without risking breaking the test. What do tests like "test_remember_binary_userid" do? Could I just remove the "hashalg" key from the dict or should I fix this another way.
Note on progress: I took myself some time and started implementing it. When I was done, I ran the tests. Where they failed, I looked into the code and set the hashalg to md5 where appropriate. Thus, I think if all tests pass, I should have insured the old system is not broken in any way. Next step then: I will create tests for the new mechanism (for which I need help then). On functionality: I decided to add a new parameter called 'hashalg'. It accepts either a new from the hashlib suite (like 'sha256' in all notations like 'SHA-256', 'SHA256' or 'sha-256'), a dotted python name (like 'hashlib.sha256') or the function itself (e.g. hashalg=hashlib.sha256). Requirement for anything passed is that the resulting object can be used like this: hashalg("string").hexdigest() and it must be able to operate on an empty string (to determine the length) and of course it must return a fixed length. HMAC is not supported (it would require more complex methods to pass a key and a string instead of just a string).
Current progress can be found on github<https://github.com/Javex/pyramid/tree/feature.auth_multiple_hashalgs>, but I am not done yet and there may be errors. If you already see some flaws in the concept please point them out. But you may as well just wait until I report that I am done ;)
It's probably enough to support "MD5", "SHA256" and "SHA512". Maybe just
do case insensitive comparison and default to "MD5". I wouldn't complicate
too much, as long as we can get the benefit of being compatible with specs
and modern crypto.
my 2 cents, cheers Domen
On Mon, Sep 10, 2012 at 12:10 AM, Florian Rüchel
<florian.ruec...@gmail.com>wrote:
> Four tests in "pyramid.tests.test_authentication.TestAuthTktCookieHelper"
> worry me: They do something like
> values = self._parseHeaders(result)
> val = self._cookieValue(values[0])
> Which fails with
> return eval(cookie.value)
> {'secure': False, 'remote_addr': '0.0.0.0', 'cookie_name': 'auth_tkt',
> 'userid': 'dXNlcmlk', 'user_data': 'userid_type:b64str', 'hashalg':
> <built-in function openssl_md5>, 'tokens': (), 'secret': 'secret'}
> SyntaxError: invalid syntax
> Unfortunately, I don't understand the purpose of those tests. Thus, I
> can't fix them without risking breaking the test. What do tests like
> "test_remember_binary_userid" do? Could I just remove the "hashalg" key
> from the dict or should I fix this another way.
> Note on progress: I took myself some time and started implementing it.
> When I was done, I ran the tests. Where they failed, I looked into the code
> and set the hashalg to md5 where appropriate. Thus, I think if all tests
> pass, I should have insured the old system is not broken in any way. Next
> step then: I will create tests for the new mechanism (for which I need help
> then).
> On functionality: I decided to add a new parameter called 'hashalg'. It
> accepts either a new from the hashlib suite (like 'sha256' in all notations
> like 'SHA-256', 'SHA256' or 'sha-256'), a dotted python name (like
> 'hashlib.sha256') or the function itself (e.g. hashalg=hashlib.sha256).
> Requirement for anything passed is that the resulting object can be used
> like this: hashalg("string").hexdigest() and it must be able to operate on
> an empty string (to determine the length) and of course it must return a
> fixed length. HMAC is not supported (it would require more complex methods
> to pass a key and a string instead of just a string).
> Current progress can be found on github<https://github.com/Javex/pyramid/tree/feature.auth_multiple_hashalgs>,
> but I am not done yet and there may be errors. If you already see some
> flaws in the concept please point them out. But you may as well just wait
> until I report that I am done ;)
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
I would agree with you if it would really complicate things much, but I can't see why it would. All those cases are really simple to implement and I don't see any security risks either as the configuration of the hash algorithm is under full control of the application developer using it. However, if Chris disagrees, I can remove all those features and really restrict it to basic algorithms (in this case I would prefer to offer all those currently supported by hashlib.
Now on to the work: I have finished the code and also implemented some new tests to assure it works. But here is where I will now need help from more experienced developers: How can I make sure I have full coverage of all situations? This seems to be the most tricky part. In fact, I think I should have covered all parts but this is because I assume that there is no interaction between the hashalg and the parameters I put in (e.g. should I test with and without tokens explicitly? I chose not to).
Before I submit a patch for pyramid on github, I would kindly ask for some code review by experienced developers. Under https://github.com/Javex/pyramid/tree/feature.auth_multiple_hashalgs you will find my cloned repository's feature branch. Please have a look at it, maybe clone it and tell me what I possibly missed. If feedback is positive, I will submit a pull request to pyramid.
Please note: *I consider this finished, so I now await feedback.
> I would agree with you if it would really complicate things much, but I
> can't see why it would. All those cases are really simple to implement
> and I don't see any security risks either as the configuration of the
> hash algorithm is under full control of the application developer using
> it. However, if Chris disagrees, I can remove all those features and
> really restrict it to basic algorithms (in this case I would prefer to
> offer all those currently supported by hashlib.
> Now on to the work: I have finished the code and also implemented some
> new tests to assure it works. But here is where I will now need help
> from more experienced developers: How can I make sure I have full
> coverage of all situations? This seems to be the most tricky part. In
> fact, I think I should have covered all parts but this is because I
> assume that there is no interaction between the hashalg and the
> parameters I put in (e.g. should I test with and without tokens
> explicitly? I chose not to).
> Before I submit a patch for pyramid on github, I would kindly ask for
> some code review by experienced developers. Under
> https://github.com/Javex/pyramid/tree/feature.auth_multiple_hashalgs you
> will find my cloned repository's feature branch. Please have a look at
> it, maybe clone it and tell me what I possibly missed. If feedback is
> positive, I will submit a pull request to pyramid.
> Please note: *I consider this finished, so I now await feedback.
This is a lot more code that I thought it would be. A few things:
- You dont need to implement your own dotted name resolver. We have
one of those in pyramid (named DottedNameResolver or something).
- You probably dont even need to resolve dotted names. I'd just
make people pass the callable that returns a new hash or something,
don't bother with trying to figure out what they mean, just make
them pass a single kind of thing.
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pylons-devel/-/QJfM_vSmF-cJ.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
On Friday, September 14, 2012 6:06:15 PM UTC-4, Chris McDonough wrote:
> On 09/14/2012 03:37 PM, Florian R�chel wrote: > > Hi Domen,
> > I would agree with you if it would really complicate things much, but I > > can't see why it would. All those cases are really simple to implement > > and I don't see any security risks either as the configuration of the > > hash algorithm is under full control of the application developer using > > it. However, if Chris disagrees, I can remove all those features and > > really restrict it to basic algorithms (in this case I would prefer to > > offer all those currently supported by hashlib.
> > Now on to the work: I have finished the code and also implemented some > > new tests to assure it works. But here is where I will now need help > > from more experienced developers: How can I make sure I have full > > coverage of all situations? This seems to be the most tricky part. In > > fact, I think I should have covered all parts but this is because I > > assume that there is no interaction between the hashalg and the > > parameters I put in (e.g. should I test with and without tokens > > explicitly? I chose not to).
> > Before I submit a patch for pyramid on github, I would kindly ask for > > some code review by experienced developers. Under > > https://github.com/Javex/pyramid/tree/feature.auth_multiple_hashalgsyou > > will find my cloned repository's feature branch. Please have a look at > > it, maybe clone it and tell me what I possibly missed. If feedback is > > positive, I will submit a pull request to pyramid.
> > Please note: *I consider this finished, so I now await feedback.
> This is a lot more code that I thought it would be. A few things:
> - You dont need to implement your own dotted name resolver. We have > one of those in pyramid (named DottedNameResolver or something).
> - You probably dont even need to resolve dotted names. I'd just > make people pass the callable that returns a new hash or something, > don't bother with trying to figure out what they mean, just make > them pass a single kind of thing.
> - C
"valid argument to hashlib.new()" is good enough. Then you just make the default
I have reworked my code with your comments. I now only support callables, I changed the documentation and removed the now invalid tests. Everything seems to run just fine, so I merged all commits into one which you can now easily review. I hope this suits your needs more.
In an effort to maintain compliance with the auth_tkt standard versus
flexibility I would've rather seen this just accept the strings "md5",
"sha256", etc rather than an arbitrary callable that may or may not be
compliant.
<florian.ruec...@gmail.com> wrote:
> I have reworked my code with your comments. I now only support callables, I
> changed the documentation and removed the now invalid tests. Everything
> seems to run just fine, so I merged all commits into one which you can now
> easily review. I hope this suits your needs more.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> In an effort to maintain compliance with the auth_tkt standard versus
> flexibility I would've rather seen this just accept the strings "md5",
> "sha256", etc rather than an arbitrary callable that may or may not be
> compliant.
> My 2 cents.
> On Mon, Sep 17, 2012 at 11:43 AM, Florian Rüchel
> <florian.ruec...@gmail.com> wrote:
> > I have reworked my code with your comments. I now only support
> callables, I
> > changed the documentation and removed the now invalid tests. Everything
> > seems to run just fine, so I merged all commits into one which you can
> now
> > easily review. I hope this suits your needs more.
> > To post to this group, send email to pylons-devel@googlegroups.com.
> > To unsubscribe from this group, send email to
> > pylons-devel+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/pylons-devel?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> In an effort to maintain compliance with the auth_tkt standard versus
> flexibility I would've rather seen this just accept the strings "md5",
> "sha256", etc rather than an arbitrary callable that may or may not be
> compliant.
> My 2 cents.
> On Mon, Sep 17, 2012 at 11:43 AM, Florian R chel
> <florian.ruec...@gmail.com <mailto:florian.ruec...@gmail.com>> wrote:
> > I have reworked my code with your comments. I now only support
> callables, I
> > changed the documentation and removed the now invalid tests.
> Everything
> > seems to run just fine, so I merged all commits into one which
> you can now
> > easily review. I hope this suits your needs more.
> > To post to this group, send email to
> pylons-devel@googlegroups.com <mailto:pylons-devel@googlegroups.com>.
> > To unsubscribe from this group, send email to
> > pylons-devel+unsubscribe@googlegroups.com
> <mailto:pylons-devel%2Bunsubscribe@googlegroups.com>.
> > For more options, visit this group at
> > http://groups.google.com/group/pylons-devel?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com
> <mailto:pylons-devel@googlegroups.com>.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com
> <mailto:pylons-devel%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> Additionally you could provide help on how to generate such a secret (but > that's extra candy). I have looked through various parts of the > documentation and it is always set to something like 'seekrit' and similar, > but it is never mentioned how to make sure that this is secure.
fwiw, wordpress has had this feature for a while: the docs instruct you to visit the following url , which generates valid secret strings. http://api.wordpress.org/secret-key/1.1/
i think most of the application scaffolds will generate a secret - but it might be useful feature to just have a secret-key generator on the pylonsproject.org site and referenced in the docs.
I've also generally disliked the mod_authtkt for a few years. i've opted for an approach where the secret rotates based on the timestamp and/or ip/other data. it's a bit harder to set up in a clustered environment, but the tickets are HMAC with SHA512 with rotating keys. it doesn't make it unbreakable, but just a bit more of pain to break and with some sort of timed window before you need to break it again.
> Additionally you could provide help on how to generate such a secret (but
>> that's extra candy). I have looked through various parts of the
>> documentation and it is always set to something like 'seekrit' and similar,
>> but it is never mentioned how to make sure that this is secure.
> fwiw, wordpress has had this feature for a while: the docs instruct you to
> visit the following url , which generates valid secret strings.
> http://api.wordpress.org/secret-key/1.1/
> i think most of the application scaffolds will generate a secret - but it
> might be useful feature to just have a secret-key generator on the
> pylonsproject.org site and referenced in the docs.
> I've also generally disliked the mod_authtkt for a few years. i've opted
> for an approach where the secret rotates based on the timestamp and/or
> ip/other data. it's a bit harder to set up in a clustered environment, but
> the tickets are HMAC with SHA512 with rotating keys. it doesn't make it
> unbreakable, but just a bit more of pain to break and with some sort of
> timed window before you need to break it again.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
On Fri, Sep 21, 2012 at 1:54 PM, Domen Kožar <do...@dev.si> wrote:
> For generating secrets it's important to discourage usage of random module,
> but use something like:
> secret = ''.join('%02x' % ord(x) for x in os.urandom(128))
Great wordpress site! Secrets transmitted in the clear without mandatory SSL.
128 bytes (1024 bits) is massive overkill. 16 or 32 bytes (128/256
bits) is enough of a secret. 256-bit hashes are enough.
HMAC-SHA256 or HMAC-SHA512 are absolutely unbreakable given that you
maintain the secrecy of the key. 2**128 operations to brute force
minimum. The other attack vector is of course firesheep (capturing the
cookie). If you do plan on losing the secret, by all means rotate it.
I don't think even auth_tkt with md5 is insecure, due to the double
hashing, but it is a good idea to switch to sha256.
On Fri, Sep 21, 2012 at 8:26 PM, Daniel Holth <dho...@gmail.com> wrote:
> On Fri, Sep 21, 2012 at 1:54 PM, Domen Kožar <do...@dev.si> wrote:
> > For generating secrets it's important to discourage usage of random
> module,
> > but use something like:
> > secret = ''.join('%02x' % ord(x) for x in os.urandom(128))
> Great wordpress site! Secrets transmitted in the clear without mandatory
> SSL.
> My apps use a generic key/value settings table and a function to
> generate a named secret if it is missing. It is easy.
> 128 bytes (1024 bits) is massive overkill. 16 or 32 bytes (128/256
> bits) is enough of a secret. 256-bit hashes are enough.
> HMAC-SHA256 or HMAC-SHA512 are absolutely unbreakable given that you
> maintain the secrecy of the key. 2**128 operations to brute force
> minimum. The other attack vector is of course firesheep (capturing the
> cookie). If you do plan on losing the secret, by all means rotate it.
> I don't think even auth_tkt with md5 is insecure, due to the double
> hashing, but it is a good idea to switch to sha256.
> There's a mod_auth_hmac if you can read Japanese.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
> i think most of the application scaffolds will generate a secret - but > it might be useful feature to just have a secret-key generator on > the pylonsproject.org site and referenced in the docs.
How about a script that's part of the framework itself? We have pserve, pcreate... how about
pkeygen [-w <filename>]
or
pyramid-keygen [-w <filename>]
I prefer those secrets to exist outside of the code anyway, in separate file loaded by the app on start. I don't want them visible by teh GitHub staff. :)
--
.oO V Oo.
Work Hard,
Increase Production,
Prevent Accidents,
and Be Happy! ;)
> How about a script that's part of the framework itself? We have pserve, > pcreate... how about
> pkeygen [-w <filename>]
> or
pyramid-keygen [-w <filename>]
I like this idea very much. I would like to either get this usage approved or I would just build a simple function inside pyramid. However, such a function belongs more into an installation than into application code. Can you tell me how to build such a script that runs on both Windows and Linux? I would like to see it implemented in this way if Chris approves.
On a seperate note: I have started on improving the documentation. As a first step, I have edited the `narr/authentication.rst` to include a note and have documented the API for `pyramid.authentication.AuthTktAuthenticationPolicy` (better documentation for secret, add documentation for hashalg). My question is now how would you handle this in regards to the documentation. I thought about adding this (or a similar) note everywhere this policy is used. This should raise the awareness everywhere the docs are read (e.g. tutorials). Furthermore, since we would clearly recommend to use something like SHA256 if MD5 is not explicitly needed, should we change the code examples to include a better hashalg (instead of just documenting it)? I would vote for a yes, since I don't see any disadvantage: If you build a new application, you should always use another algorithm and as shown above mod_auth_tkt can also easily handle other algorithms if configured correctly.
I have also created a small `gensecret` function based on the ideas of Daniel and Domen (but with added Python3 compatibility): https://github.com/Javex/pyramid/commit/d4f2943fa50e34f682f8097dccee2... This function is not what I expect in the final version but it shows where I would like to go with this: Provide a function that makes it easier for a user to obtain a strong secret. Either we use it this way or the above mentioned seperate script, that really doesn't matter.
> I prefer those secrets to exist outside of the code anyway, in separate > file loaded by the app on start. I don't want them visible by teh GitHub > staff. :)
> --
> .oO V Oo.
> Work Hard, > Increase Production, > Prevent Accidents, > and Be Happy! ;)
On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote:
> How about a script that's part of the framework itself? We
> have pserve, > pcreate... how about
> pkeygen [-w <filename>]
> or
> pyramid-keygen [-w <filename>]
> I like this idea very much. I would like to either get this usage
> approved or I would just build a simple function inside pyramid.
> However, such a function belongs more into an installation than into
> application code. Can you tell me how to build such a script that runs
> on both Windows and Linux? I would like to see it implemented in this
> way if Chris approves.
Who will use it and when would they use it?
> On a seperate note: I have started on improving the documentation. As
> a first step, I have edited the `narr/authentication.rst` to include a
> note and have documented the API for
> `pyramid.authentication.AuthTktAuthenticationPolicy` (better
> documentation for secret, add documentation for hashalg). My question
> is now how would you handle this in regards to the documentation. I
> thought about adding this (or a similar) note everywhere this policy
> is used. This should raise the awareness everywhere the docs are read
> (e.g. tutorials). Furthermore, since we would clearly recommend to use
> something like SHA256 if MD5 is not explicitly needed, should we
> change the code examples to include a better hashalg (instead of just
> documenting it)? I would vote for a yes, since I don't see any
> disadvantage: If you build a new application, you should always use
> another algorithm and as shown above mod_auth_tkt can also easily
> handle other algorithms if configured correctly.
I didn't know we already had a mergeable patch for the hashalg stuff.
The last patch I saw seemed maybe a little overwrought. Until we figure
that out, I'd hold off on changing docs.
> I have also created a small `gensecret` function based on the ideas of
> Daniel and Domen (but with added Python3 compatibility):
> https://github.com/Javex/pyramid/commit/d4f2943fa50e34f682f8097dccee2... > This function is not what I expect in the final version but it shows
> where I would like to go with this: Provide a function that makes it
> easier for a user to obtain a strong secret. Either we use it this way
> or the above mentioned seperate script, that really doesn't matter.
> How about a script that's part of the framework itself? We have pserve,
>> pcreate... how about
>> pkeygen [-w <filename>]
>> or
> pyramid-keygen [-w <filename>]
> I like this idea very much. I would like to either get this usage approved
> or I would just build a simple function inside pyramid. However, such a
> function belongs more into an installation than into application code. Can
> you tell me how to build such a script that runs on both Windows and Linux?
> I would like to see it implemented in this way if Chris approves.
> On a seperate note: I have started on improving the documentation. As a
> first step, I have edited the `narr/authentication.rst` to include a note
> and have documented the API for
> `pyramid.authentication.AuthTktAuthenticationPolicy` (better documentation
> for secret, add documentation for hashalg). My question is now how would
> you handle this in regards to the documentation. I thought about adding
> this (or a similar) note everywhere this policy is used. This should raise
> the awareness everywhere the docs are read (e.g. tutorials). Furthermore,
> since we would clearly recommend to use something like SHA256 if MD5 is not
> explicitly needed, should we change the code examples to include a better
> hashalg (instead of just documenting it)? I would vote for a yes, since I
> don't see any disadvantage: If you build a new application, you should
> always use another algorithm and as shown above mod_auth_tkt can also
> easily handle other algorithms if configured correctly.
> I have also created a small `gensecret` function based on the ideas of
> Daniel and Domen (but with added Python3 compatibility):
> https://github.com/Javex/pyramid/commit/d4f2943fa50e34f682f8097dccee2... > This function is not what I expect in the final version but it shows where
> I would like to go with this: Provide a function that makes it easier for a
> user to obtain a strong secret. Either we use it this way or the above
> mentioned seperate script, that really doesn't matter.
> Please tell me your thoughts on both topics.
> Regards,
> Florian
>> I prefer those secrets to exist outside of the code anyway, in separate
>> file loaded by the app on start. I don't want them visible by teh GitHub
>> staff. :)
>> --
>> .oO V Oo.
>> Work Hard,
>> Increase Production,
>> Prevent Accidents,
>> and Be Happy! ;)
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
