Open Stack

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.


>
>>
>> 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.


>
>
>>
>> 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151117/aa58dfc4/attachment.html>