Previously, Swift3 used client-facing HTTP headers to pass the S3 access
key, signature, and normalized request through the WSGI pipeline.
However, swauth did not validate that Swift3 actually set the headers;
as a result, an attacker who has captured a single valid request through
the S3 API may impersonate the user that issued the request indefinitely
through the Swift API.
Now, the S3 authentication information will be taken from a separate,
client-inaccessible namespace in the WSGI environment as defined in the
related change.
UpgradeImpact
This addresses a breaking API change in Swift3. No currently deployed
version of Swift3 will work with this. When upgrading swauth, operators
will need to upgrade Swift3 as well.
Change-Id: Ie5481a316397f46734e9dd0e77a8a87197ceec16
Related-Change: Ia3fbb4938f0daa8845cba4137a01cc43bc1a713c
Swauth uses token value as object name. Object names are logged in proxy
and object servers. Anybody with access to proxy/object server logs can
see token values. Attacker can use this token to access user's data in
Swift store. Instead of token, hashed token (with HASH_PATH_PREFIX and
HASH_PATH_SUFFIX) is used as object name now.
WARNING: In deployments without memcached this patch logs out all users
because tokens became invalid.
CVE-2017-16613
SecurityImpact
Closes-Bug: #1655781
Change-Id: I0d01e8e95400c82ef25f98e2d269532e83233c2c
Amazon S3 compatibility:
Due to security concerns raised, this change makes S3 support tunable
using a config option and is turned off by default.
Change-Id: I077f78946983f5d6b3b725dd6aa3ed178dc5604e
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Currently, the input to HMAC function is the entire stored credential
in the format '<salt>$<hash>` but it should rather be only the hashed
key/password.
With this change, validate_creds() method is invoked and only the hash
of the password is used in HMAC computation.
Change-Id: I1a9bbcac6f49c23f3256572f148e55249a59f7ed
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Older versions of swauth supported manually setting up a salt string in
conf file. This change re-introduces it and makes it a tunable option.
The current behavior of randomly generating salt for every password is
NOT affected with this change.
Change-Id: Ifdf6f806b954e4d41c083eeffa981cd7d0dd50b9
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Problem:
If an existing swauth deployment changes `auth_type` in conf file to a
different one (for example: sha1 to sha512), all attempts to authorize
existing/old users will fail because of change in encoder type.
Fix:
With this change, the credentials match is done using an encoder with
which the password was initially encoded. This allows swauth deployments
to change auth_type and old users will still be able to authorize.
Closes-Bug: 1516980
Change-Id: I8a5c397d0796062f4109c59b6dc61b14d4a97e4b
Signed-off-by: Prashanth Pai <ppai@redhat.com>
This issue can be hit when swift3 middleware is in the pipeline.
Change-Id: If87a6663efcf31febe4a207b3d7f331b5f79b834
Signed-off-by: Prashanth Pai <ppai@redhat.com>
E127 continuation line over-indented for visual indent
E131 continuation line unaligned for hanging indent
Change-Id: I19ceb58d8545fb1b585e04b40418271f6ff56a5e
Currently, in cases where swauth returns a JSON document as its body,
it does not specify a content type, and swob defaults it to text/html.
This change uses a standard content type of 'application/json' in each
of these instances, and adjusts the tests accordingly.
Closes-Bug: #1545430
APIImpact
Change-Id: I96d343a87f462811bcefb7d402887f8a570fe6bd
Ondřej Nový