What you should know about PS_TOKEN vulnerabilities and how to prevent them


If you weren’t in Amsterdam last week,  you missed out on a session at the Hack in the Box conference that is sure to be of interest to PeopleSoft customers. Presenters from ERPScan presented their latest findings in ERP vulnerability research and how PeopleSoft is affected.

Most critical to their findings is being able to brute force the PeopleSoft specific PS_TOKEN cookie to be able to recover the internal password used to sign the cookies.  This means that an attacker could be able to generate their own PS_TOKEN cookies at will for whatever user name that they choose.

Fear not though; there are ways to make sure that your PeopleSoft system is secure.

What is a PS_TOKEN cookie?

For those that aren’t familiar, the PS_TOKEN is what PeopleSoft uses to verify that someone has been authenticated by a PeopleSoft system.  It is not the same as the regular session cookie that identifies a given login session,  but is one of the mechanisms for establishing a new session.  For example,  someone might login to a PeopleSoft system for Financial data,  receive a PS_TOKEN cookie, and then when accessing a PeopleSoft system for Human Resource data, the PS_TOKEN cookie allows them access without needing to login again for the HR system.

This works by defining in the PeopleSoft configuration which nodes are considered to trust each other.  In the example above,  where someone logged in to the Financials system and was then given a PS_TOKEN cookie,  when they went to the HR system,  it would only allow that person to continue without authentication if 1) the node that created the cookie (the Financials system) is in the list of the nodes that the HR system trusts. 2) the PS_TOKEN cookie has not expired (the default expiration is 8 hours, but this is configurable) and 3) the user account that the PS_TOKEN cookie was issued for exists in the HR system.

How can you mitigate the risk?

Unfortunately,  generating a PS_TOKEN cookie when someone logs in is hard-coded into PeopleSoft.  Even if you don’t have multiple PeopleSoft systems.  In theory, you can remove all nodes from the trusted node table so that the generated PS_TOKEN can’t be used for establishing new sessions,  but this has an impact on some system level functionality as well (e.g. reporting functionality stops working),  which makes that impractical.

It turns out though that you don’t even need a PS_TOKEN cookie to work in PeopleSoft.  Who knew?!?  You can test this yourself by logging in to a PeopleSoft environment with a browser that allows deleting individual cookies,  such as Google Chrome,  and remove the PS_TOKEN cookie after you have logged in.  Everything will continue working properly.

Deleting the cookie manually is not viable either though.  This is something that you can do with the GreyHeller ERP Firewall for PeopleSoft.  You can remove the PS_TOKEN for just the public browsing sessions or for all users if you don’t rely on the PS_TOKEN cookie to transfer users between different PeopleSoft systems.

You can also create rules in the ERP Firewall that allow you to allow usage of the PS_TOKEN on your internal network,  but block it from external users.

How about external authentication such as Kerberos/Shibboleth/OAuth2?

If you already have PeopleSoft configured for external authentication, then you definitely don’t need the PS_TOKEN cookie to pass users between different PeopleSoft systems.  Once the person crosses from one system to the other,  your external authentication kicks in and automatically log them in to the other environment.

Doesn’t Two Factor Authentication fix this?

If you require two factor authentication each time someone logs in to PeopleSoft,  then this greatly reduces the exposure from an attacker being able to generate their own PS_TOKEN cookies.  They would be able to start a session,  but then would be immediately challenged for the second factor of authentication.

The ERP Firewall for PeopleSoft supports requiring a two factor challenge at authentication time,  but one issue is that usability suffers dramatically when constantly requiring a second factor at login time.   In fact, what we typically see with GreyHeller customers implementing the ERP Firewall is that it is preferred to wait until someone accesses sensitive data/actions before requiring the additional factor of authentication.  This hits a balance between locking things down and the user experience.

What about using a stronger hashing algorithm?

A stronger hashing function will help,  but less than you think.  If you look at tools like oclHashcat,  they show that breaking an SHA-256 hash runs at about 40% of the speed of breaking an SHA-1 hash. Breaking an SHA-512 hash runs at about 14% of the speed of breaking an SHA-1 hash.

So if it would have taken someone 8 hours before to break an SHA-1 hash,  now they have to wait overnight in order to break an SHA-256 hash.  Or they have to wait a few days to break an SHA-512 hash.  Not a big deal if full access to a PeopleSoft environment as any user is the prize.

The other thing to keep in mind is that you can now rent GPU instances from Amazon with over 1500 cores in them and breaking hashes is something that is, as they say, embarrassingly parallel.

For additional information on the ERP Firewall or GreyHeller visit