Assurance

[David Langenberg <>]

To get back to the root of the question though:

Detection: analyze user/ip-block combinations.  See a lot of users from the same address -- check it out & see what it might be (Kiosk, proxy, etc)

Prevention: Once you know about a shenanigan like this, leave it up and alone.  Record users coming through it (maybe ask a user what the deal is with their access yesterday at 5pm).  Once you know it's a bad app, start the education: "Dear User, you accessed system X via $PROXY at $TIME.  This is a violation of policy XYZ and therefore you have lost Assurance Z.  You now need to take corrective steps 1, 2, and 3.  Further usage of $PROXY will result in disciplinary action".  Slap enough hands and folks will get the idea.

Of course, there's a reason they're using bearbucks rather than going directly to Banner...

Dave

On Fri, Mar 7, 2014 at 12:39 PM, Steven Carmody <> wrote:

Hi,

I'll summarize the long back story.. a student recently brought us an new app that they had recently built. Its 120 lines of _javascript_, and leverages both node.js and the meteor platform. This app sits in front of our Banner student system and acts as a proxy. It presents its own login page, and immediately navigates thru Banner and retrieves how many dining hall points that user currently has. The good news is that while the student actually deployed this in the cloud (bearbucks.meteor.com), he also brought it to our attention. It didn't take much effort to develop this app. We've also determined that a slightly modified version of this app works just fine with our IDP login page.

Up until now, we had been thinking that 2-factor would provide a defense against phished and stolen passwords.

But, this is a little different. This proxy sits in front of our apps; it isn't a dead end that's just trying to trick people into entering their passwords.

Most worrisome, tho, is that we think that if we implemented some forms of two factor in the authN process of our apps that this proxy could quickly evolve to handle the extra step. If we TXTed a code to the person's mobile phone and presented a web form, the proxy could easily handle that. We also expect that the proxy could evolve to deal with CAPTCHA style approaches.

So, beyond user education, what might people suggest as a way to detect, block, or prevent this sort of potentially-password-stealing approach, that could even handle some forms of two-factor ?

--
David Langenberg

Identity & Access Management

The University of Chicago