summaryrefslogtreecommitdiff
path: root/docs/narr
diff options
context:
space:
mode:
authorChris McDonough <chrism@plope.com>2013-10-19 15:57:33 -0400
committerChris McDonough <chrism@plope.com>2013-10-19 15:57:33 -0400
commite521f14cc4d986c2ad400abff3d6cb7ff784b775 (patch)
treed8fd39ff6f52d417ee773f9f802fb24e366149bc /docs/narr
parent9536f9b9c470ea03de4bfa98b1f0c3583bb8f394 (diff)
downloadpyramid-e521f14cc4d986c2ad400abff3d6cb7ff784b775.tar.gz
pyramid-e521f14cc4d986c2ad400abff3d6cb7ff784b775.tar.bz2
pyramid-e521f14cc4d986c2ad400abff3d6cb7ff784b775.zip
add admonishment against secret sharing
Diffstat (limited to 'docs/narr')
-rw-r--r--docs/narr/security.rst28
1 files changed, 28 insertions, 0 deletions
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 6517fedf8..9884bb1dc 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -669,3 +669,31 @@ following interface:
After you do so, you can pass an instance of such a class into the
:class:`~pyramid.config.Configurator.set_authorization_policy` method at
configuration time to use it.
+
+.. _admonishment_against_secret_sharing:
+
+Admomishment Against Secret-Sharing
+-----------------------------------
+
+A "secret" is required by various components of Pyramid. For example, the
+:term:`authentication policy` below uses a secret value ``seekrit``::
+
+ authn_policy = AuthTktAuthenticationPolicy('seekrit', hashalg='sha512')
+
+A :term:`session factory` also requires a secret::
+
+ my_session_factory = SignedCookieSessionFactory('itsaseekreet')
+
+It is tempting to use the same secret for multiple Pyramid subsystems. For
+example, you might be tempted to use the value ``seekrit`` as the secret for
+both the authentication policy and the session factory defined above. This is
+a bad idea, because in both cases, these secrets are used to sign the payload
+of the data.
+
+If you use the same secret for two different parts of your application for
+signing purposes, it may allow an attacker to get his chosen plaintext signed,
+which would allow the attacker to control the content of the payload. Re-using
+a secret across two different subsystems might drop the security of signing to
+zero. Keys should not be re-used across different contexts where an attacker
+has the possibility of providing a chosen plaintext.
+