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 www.greyheller.com.