Open Stack

On Tue, Nov 17, 2015 at 2:56 PM, Lindsay Pallickal <pallickal at gmail.com>
wrote:

>
>
> On Tue, Nov 17, 2015 at 5:31 AM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:
>
>>
>>
>> On Tuesday, November 17, 2015, Lindsay Pallickal <pallickal at gmail.com>
>> wrote:
>>
>>>
>>> It looks like expiration is done this way to limit the damage from
>>> stolen tokens, but if a token were stolen, it could be stolen from the same
>>> location a username and password will now have to sit, to get around having
>>> to re-supply them manually once an hour. Yes, forcing re-auth hourly with a
>>> username and password, at the Keystone level, can limit damage if any of
>>> the core Openstack services are compromised for the mass theft of tokens.
>>> But limited damage will depend just as much on how quickly the compromise
>>> is detected. The more time an attacker has in the system, the less his
>>> actions will be hampered by a lack of token renewals. VMs can be
>>> compromised, and data exported or destroyed given just a small window.
>>>
>>
>> This first part of this is only a "maybe", not a completely true
>> assertion. There are *many* more opportunities for individual tokens to be
>> exposed than for the credentials used to create them. In the case if a mass
>> token compromise, which I consider to be a completely different scenario,
>> token expiration probably isn't going it be any help because there's
>> probably always a fresher token available to the attacker, anyway, until
>> the exploit is closed. Instead, keystone has several means of quickly
>> revoking tokens in bulk (revocation events, truncating the UUID token
>> table, restarting the memcache token backend, or rotating all your Fernet
>> keys away... all depending on your deployment).
>>
>
> The token does get sent a lot more often than the username/password
> credentials, but as long as both are sent via SSL/TLS, shouldn't the
> opportunity for exposure be similar? Although, I could see it being easier
> to accidentally send a token in the clear, or in a way vulnerable to a mitm
> (ignoring ssl cert issues), as there are frequently more bits of code in
> the client that deal using a token, versus a just few bits to secure when
> deal with logging in. Tokens get passed around to far more services with
> potential vulnerabilities as well, but I see that as a separate issue. I
> agree with your comment that token expiration will not really help in a
> mass compromise scenario.
>

Similar, yes, but with a couple significant differences. Off the top of my
head:

In keystone's v2 API, bearer tokens are a part of the URL in token
validation calls and token revocation calls. Of course, access logs are
everywhere and many deployments do these operations over HTTP! The v3 API
relegates them to headers, at least. I wonder if it would be possible to
have keystoneauth / keystoneclient log a client-side warning when it's
asked to send a bearer token over HTTP?

And certainly, the number of possible attack vectors on a bearer token
being passed around to a bunch of services is increased by an order of
magnitude.


>
>
>>
>>>
>>> On the other hand, if a user facing application, or a long running
>>> service supporting one, needs the API and is to remain convenient, they
>>> have to store usernames and passwords. Sometimes that long running service
>>> is connected to the outside world and faces security threats, such as when
>>> relaying Openstack API requests to their respective internal network
>>> endpoints - similar to what Horizon does. I wonder if I use Horizon
>>> continuously, whether it will force me to manually re-authenticate hourly,
>>> and if not, how it is getting around this problem, with or without storing
>>> the username and password.
>>>
>>
>> Bearer tokens are simply not the right solution to this use case. Unless
>> horizon were to store your credentials client-side, you will be logged out
>> after your keystone.conf [token] expiration passes.
>>
>
> I just checked and Horizon re-requests login after an hour, despite
> activity. So yeah, Horizon is not storing credentials, which is good.
>

Good to hear the confirmation that's still true - it's been a long while
since I've looked at that code, and I almost guarantee we don't test that
behavior anywhere.


>
>
>>
>>
>>>
>>> I suspect it is more probable to button up security closer to the core
>>> of Openstack, rather than relying on many third party API consuming
>>> apps/services to secure even more compromising credentials. Perhaps effort
>>> could be put into auditing for atypical mass token renewal events, like a
>>> sudden increase, or accumulating rate of renewal requests in proportion
>>> with the number of tokens streamed into compromised state.
>>>
>>> Allowing a maximum of 3 hours, in 1 hour renewal increments via
>>> Keystone, and making that configurable, would be a good compromise for
>>> user/outside facing apps/apis. Reducing temptation to adopt the security
>>> burden of storing usernames and passwords, especially on a server exposed
>>> to the outside or in storage that is outside (cookies & local storage),
>>> could itself be a security boon.
>>>
>>
>> Have you tried setting keystone.conf [token] expiration to 10800 (3
>> hours, in seconds)? If so, why doesn't this satisfy your use case? And why
>> expect ordinary users to do busy work to hit the same token lifespan that
>> an attacker will trivially achieve anyway?
>>
>>
>
> I wish I had seen that expiration setting earlier. Just what I needed,
> thank you.
>

Awesome!


>
> In retrospect, it does not make sense to force users to do the busy work
> of renewal when an attacker could just do the same. Even if the token has
> expired a earlier due to non-renewal, causing an intruder misses the
> window, it will only be a matter of time before a fresh token is available
> through the same vector. I think a 3 hour expiration window will not add a
> lot of risk, and the option is already built in, so all is well. Thanks
> again.
>
> Lindsay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151118/ee3a4971/attachment.html>