<br><br>On Tuesday, November 17, 2015, Lindsay Pallickal <<a href="mailto:pallickal@gmail.com">pallickal@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>Problem (as state before I realized this was a feature):</div><div><br></div><div>When I "renew" an unscoped token using an existing unscoped token, a new token (<a href="http://access.token.id" target="_blank">access.token.id</a> 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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Reasons to reconsider the expiration policy:</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.<br></div></div></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>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.<br></div><div><br></div><div>Lindsay</div></div>
</blockquote>