Security/Kilo/Keystone

This page documents security related details for the Keystone project in the OpenStack Kilo release.

Implemented Crypto
Keystone doesn't have an home-brewed encryption implementations, everything is used from Python Standard libraries or third party libraries.

Libraries

 * oauthlib (uses hashlib)
 * OpenSSL
 * PassLib
 * PyCrypto
 * Python hashlib
 * python-ldap (ultimately uses GnuTLS, NSS, or OpenSSL depending on the platform)
 * Requests (for keystoneclient HTTPS usage - need to investigate underlying crypto usage)
 * uses stdlib - https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/connection.py

Keys/Certificates

 * PKI signing key - Protected via filesystem ownership/permissions.
 * SSL/TLS key - Protected via filesystem ownership/permissions.

Passwords

 * SSL/TLS must be enabled in Keystone to prevent clients from sending passwords over the network in clear-text.
 * Strict password checking is performed prior to hashing. If it is set to true, the operation will fail with an HTTP 403 Forbidden error; if it is set to false, passwords are automatically truncated to the predefined maximum length.
 * Configurable via CONF.strict_password_check (default=False)
 * Configurable via CONF.identity.max_password_length (default=4096)
 * SQL Identity
 * Password hashes are stored in SQL database.
 * SSL/TLS can be used to protect the connection to the database.
 * LDAP Identity
 * SSL/TLS must be used for connections to LDAP to prevent Keystone from sending passwords over the network in clear-text.

Tokens

 * Signed tokens are stored in their entirety in one of the following backends:
 * KVS
 * Memcached
 * Ephemeral storage.
 * Able to use AES encryption and sha384 signing.
 * SQL (default)
 * Persistent storage.
 * SSL/TLS can be used to protect the connection to the database.
 * Expired tokens are not automatically removed from the backend. The "keystone-manage token_flush" command should be used to periodically remove expired tokens (via cron).

Potential Improvements

 * Allow all hashing schemes to be configurable where not restricted by compatibility requirements (such as S3 and EC2)
 * The use of md5 for token hashing is the biggest concern, as it's use is discouraged (or disallowed in the case of FIPS). Changes are in progress to make this configurable in Juno.  The default should be sha256 if possible.
 * Allow support for LDAP SASL bind methods(such as DIGEST-MD5 and GSSAPI).
 * Allow other forms of external authentication to avoid using passwords (Kerberos, SAML).