Open Stack

On Tuesday, November 17, 2015, Lindsay Pallickal <pallickal at gmail.com>
wrote:

> I was having an issue extending the expiration on unscoped and
> tenant/project scoped tokens retrieved with an existing token. I now
> realize this is a feature, not a bug, but I've got some points to argue
> that extending token expiration when getting a new token with an existing
> one (renewal), is worth considering. Maybe as on option with a cap on
> maximum renewal time.
>
> Problem (as state before I realized this was a feature):
>
> When I "renew" an unscoped token using an existing unscoped token, a new
> token (access.token.id is different) is issued, but the expiration is
> always the same as the first unscoped token that was returned on
> authentication with a username and password. I expected the expiration to
> extend with each new token, but this only seems to happen when an unscoped
> token is retrieved by authenticating with a username and password, not when
> an existing unscoped token is used to authenticate the request for a new
> token.
>
> Tenant/project scoped tokens, similarly, always return the expiration from
> the unscoped token used to retrieve them. Since any unscoped tokens can't
> get an updated expiration, the problem extends here.
>
> I have an application where the user enters their username and password
> once, and whenever a token is used, I mark it "dirty" so it is "renewed"
> within 30 seconds. This way they don't have to re-login until they haven't
> performed any actions for the ~1 hour expiration time Keystone grants. Now
> clearly the expiration time is not moving ahead with these "renewals", so
> it doesn't work as intended, and that leads me to seek some remedy. Storing
> a username and password in browser local storage/cookies, or multiple on a
> server that relays browser requests to api endpoints, would open a can of
> worms.
>
> Reasons to reconsider the expiration policy:
>
> 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).


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


>
>
> For now, my application will force manual username and password re-auth
> hourly, rather than letting idle time determine expiration by opting to
> store username/password credentials, but it doesn't feel user friendly.
>
> Lindsay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151117/259b0430/attachment.html>