Difference between revisions of "Security/Icehouse/Keystone"
(→Sensitive Data) |
|||
Line 1: | Line 1: | ||
+ | This page documents security related details for the Keystone project in the OpenStack Icehouse release. | ||
=== Implemented Crypto === | === Implemented Crypto === | ||
None. | None. |
Revision as of 02:34, 6 April 2014
This page documents security related details for the Keystone project in the OpenStack Icehouse release.
Contents
Implemented Crypto
None.
Used Crypto
Encryption Algorithms
Algorithm | Purpose | Configurable | Implementation | Details | Source |
---|---|---|---|---|---|
AES | Memcache backend encryption | No | PyCrypto |
|
|
RSA | PKI token signing | Yes | OpenSSL |
|
|
Hashing Algorithms
Algorithm | Purpose | Configurable | Implementation | Details | Source |
---|---|---|---|---|---|
md5 | Token hashing | No | hashlib |
|
|
sha1 | S3 credentials | No | hashlib |
|
|
sha1 | LDAP password hashing | No | PassLib |
|
|
sha1 | OAuth1 | No | oauthlib |
|
|
sha256 | EC2 tokens | No | hashlib |
|
|
sha384 | Memcache signing | No | hashlib |
|
|
sha512 | Password hashing | No | PassLib |
|
|
Sensitive Data
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.
- Passwords are truncated to a maximum length prior to hashing
- 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
- Eliminate LDAP user password hashing. This code should be unnecessary, as passwords supplied by clients should only be used to perform LDAP bind operations and never stored locally in any form.
- 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).