The New York Times recently ran an article about some new approaches that hackers are taking to get into systems. This article dovetails nicely with some work we've been doing in getting one of our customers live with our ERP Firewall prduct last week.

Real Time Snatching? What do you mean?

Well, apparently hackers can now get a real-time stream of information from your computer, including your current secure-id token when you put it in. Historically, stealing this information is relatively begnin because it's only valid for about 90 seconds, but when somebody can pull it from you and use it to authenticate while it's still valid, it becomes a big issue. The article also mentions another approach they take: spawning hidden browser windows on your machine as you're using it.

Fortunately, there are a couple of relatively simple things you can do to mitigate these risks.

Secure ID token protection

Let's start by discussing how to protect misuse of your secure id token. As most people reading this entry know, a secure ID token is a number that changes every 90 seconds that you use to authenticate yourself in a more secure manner than just a userid and password. It works on the principle that (1) The user has a token in his posession with him that provides him a PIN to authenticate himself, (2) That the PIN number changes frequently enough that even if somebody gets it, it isn't valid by the time he/she would use it, and (3) the algorithm for generating the PIN number is not breakable. Unfortunately, if somebody does get the PIN number and use it within those 90 seconds, this defeats this measure.

Or does he?

One very simple way to prevent somebody from re-using a PIN number they lifted from the user is to tie it to the IP address of the person entering it. This way, the person with the token (the authorized user) will be entering the PIN number from his current location (IP address). The bad guy lifts the PIN, but can't use it because the PIN has already been used by the authorized user with a different IP Address than the one that the bad guy is using.

The way to accomplish this in PeopleCode is to use the RemoteAddr property of the Request object.

local string &sMyIPAddr = %Request.RemoteAddr;

So, if you created a PeopleSoft page to accept a PIN number from a Secure ID token, you can take that token, validate it, and then check to see if the PIN is already in use with another IP Address. This would involve storing this information off in a small table, but again it's pretty simple to do.

We've actually put this code into our ERP Firewall (so reading the acticle was Deja Vu all over again)

Spawning of hidden browser windows

Now that we've covered the first item, let's look at the second one. The best way to limit exposure to hidden browser windows to define certain parts of your application as being more secure than others. In other words, you ONLY ask for additional identity challenges at the point in which people are accessing a more sensitive part of PeopleSoft, but allowing the basic credentials for the less sensitive parts.

This means that for the majority of time your users are using the system, they have much more limited rights (i.e. they don't yet have the priveleges to access the more sensitve parts -- this also means that if a bad guy takes over somebody's session the bad guy also has limited priveleges). When the user then tries to access the more secure area, only then do you ask for his additional credentials and limit its use to just that secure area. If you were to invalidate those credentials after a period of time, then your exposure window would be even smaller.

So, the key here is to identify when to perform the challenge and to enforce it to occur before allowing access to a given page or component (as opposed to doing it upon signing onto the system as most organizations do). This means that you will need to inject your code right as people try to access that page.

Because our ERP Firewall product already does this (and it's actually extremely simple to do without modifying the application, we've spent a bit of time walking folks through how to accomplish this). If you're not queasy about customizing PeopleSoft, you could instead inject your logic into the Component PreBuild PeopleCode event. Another option is to use an open source application firewall tool to do something similar.

Regardless of your approach,the solution will need to do the following things:

1. Check to see if the session has already used a valid token (this needs to incorporate the logic that ties the IP address to the token it there is one as well as setting a time limit for how long the token would be good for)
2. Display a page to challenge the user for his additional credentials (i.e. the secure id token)
3. The page then needs to check to make sure that the PIN is valid
4. If valid, it needs to tag the session as having entered a valid token (so that the user can continue onward)
5. It needs to redirect the user back to the original page request

Caveats

So, although these suggestions won't completely eliminate the risk to your organization, they will dramatically reduce your exposure. If you combine these suggestions with a strong logging methodology, you will also be able to more easily see where people are trying to penetrate your system.

If you've already identified your more secure areas of your application for applying additional challenges, you will also want to log all successful and unsuccessful access to those areas as well so you can see if there are more attempts to access those areas (and if you're looking for a product that can help you with that as well, I know of one I can recommend ;-).

Labels: Security