diff options
| author | Chris McDonough <chrism@plope.com> | 2013-10-19 15:57:33 -0400 |
|---|---|---|
| committer | Chris McDonough <chrism@plope.com> | 2013-10-19 15:57:33 -0400 |
| commit | e521f14cc4d986c2ad400abff3d6cb7ff784b775 (patch) | |
| tree | d8fd39ff6f52d417ee773f9f802fb24e366149bc /docs/narr | |
| parent | 9536f9b9c470ea03de4bfa98b1f0c3583bb8f394 (diff) | |
| download | pyramid-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.rst | 28 |
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. + |
