What's in a Login Token?

Sitting here in the DC airport, waiting for a flight which seems to be indefinitely delayed, it struck me that I should be doing something constructive. In the past I've done quite a bit of mucking around with portal security, and one of the things I always wondered about were portal login tokens. So, just in case you happen to get stuck playing an ALUI version of Trivial Pursuit, here's what I know...

What is a login token?

Login tokens are basically session keys that are used to instantiate user sessions in the portal. Put another, less complicated, way: they enable logins to the portal without a password.

Where are login tokens used?

The server API contains methods for instantiating a user session from a login token. These tokens are passed to the API for validation and are used anywhere an automated method is necessary for authenticating a user across application boundaries.

That sounded complicated again... how about I just list their uses:

• The automation server uses a login token to run jobs as different users.
• The administrative server uses them to authenticate users who click the Administration link in the portal (this only happens if you have a separate administrative server).
• The Default Profiles administrative utility and some custom impersonation spaces PCS has written use them to impersonate other users on the fly.
• Remember my Password sets a cookie in your browser with a login token.
• Login tokens are sometimes passed to portlets using the IDK, then used by the PRC to validate user sessions (see one of my previous posts)

How are login tokens built?

1. Current UTC time in seconds is retrieved from the server.
2. Token expiration is calculated based on the number of seconds from UTC time and token lifetime.
3. A string is created that looks like: User ID + token delimiter + expiration (step 2) + token delimiter.
4. A hash of (3) is taken, with the key being the Login Token Key generated when you push the 'Update' button in Administration | Portal Settings (read the directions before you push this).
5. A token delimiter and a Base 64 encoded (4) are appended to (3) to create the token.

Here is an example login token (token delimiter is the | character):

1|1175181932|b7QDEolhC7kNUDjlAlZJ7xnKqSA=

Some notes on login tokens...

If you ever start digging through the documentation, or call up support with an automation or admin server login failure, the first thing you'll be asked is, "Are the times on the front and back end servers the same?" If the times are off by too much, the calculated expiration time of a login token will be wrong on the portal server and the login token will be invalid (expirations for login tokens are usually short in duration).

As far as whether or not the tokens can be reverse engineered by brute force, the answer is probably not (never say never, right?). The root key for token creation is 18 digits long, and the token itself is comprised using a well known hashing algorithm (if you're curious, you'll have to sniff it out yourself, since I'm not sure I'm allowed to give that kind of info out). Since I don't know of any practical weaknesses in the algorithm, brute force seems an unlikely avenue for success. And since the key to the hash is stored in the database, if a malicious user can actually retrieve this key, you probably have bigger problems to worry about than your login tokens being spoofed.