Each time I make a call for token, a different token is returned

Asked by Deepak Garg on 2012-03-23

For the same credentials, Each time I make a call for token, a different token is returned.
This must be an important design decision but I am not able to figure out why.
Please tell me or point me to sources where I can find the info.

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Identity (keystone) Edit question
Assignee:
No assignee Edit question
Solved by:
Deepak Garg
Solved:
2012-03-27
Last query:
2012-03-27
Last reply:
2012-03-27
Joseph Heck (heckj) said : #1

Tokens are very intentionally meant to be time limited to reduce the exposure of man in the middle attacks, it's a very common pattern when implementing HTTP header/token based authentication and authorization systems. The code had explicit expiration times enabled for tokens, which render them unusable after a certain amount of time.

Deepak Garg (deepak.garg) said : #2

Thanks Joe, but
a. when I run the cmd $ keystone token-get twice without any point of gap in between, i get two different tokens and both of them are valid. Why is this so ? How about we send the same token unless it has expired ? Here's a paste of both being valid:
http://paste.openstack.org/show/12086/

b. also unless we encrypt the traffic, we can always do a MITM. Sorry, its not very clear, how token will avoid that because the attacker sends the very same traffic which comes from the genuine machine.

Joseph Heck (heckj) said : #3

The current implementation provides a new token every time, but the original token remains valid for a set amount of time. A variant implementation we could check to see if a token already exists for the credentials passed in - and if still valid use that, but the current code simply creates a new one one request.

It's just a fast, simple mechanism today.

For the man-in-the-middle, yes - traffic would need to be encrypted, but it's still a good security practice to make all relevant tokens time limited, so that if they are accidentally exposed (and there's no guarantee of where they're stored), the risk is somewhat more limited in scope.

-joe

Deepak Garg (deepak.garg) said : #4

Thanks Joe for the time.