Assurance

[Eric Goodman <>]

As everyone else has said, technology alone won't solve the issue. Any interface a user can access via a web browser, an automated system can interface with the same way.

 

I (and I'm sure many others) have seen some egregious proxy applications deployed, and it's frequently hard to explain to the developers of the proxies why that's not okay, let alone explaining to the end users why it's a security risk. I've had web developers argue that the IdP login page or even our IdM password change page is just a text/html-based API, as valid to authenticate against as a publicly accessible LDAP server.

 

I think a key element I haven't seen listed below is to actually have a campus/account system policy that makes it clear that proxying user authentication is not allowed (or at least when it is allowed). Yes there are always exceptions, but the exceptions should require a true process with express approval of some CISO-like entity. This won't stop true hackers, but it can make it clear to "insiders" who develop these kinds of things that it's not okay, then at least you have a(n internal) leg to stand on when trying to correct such issues.

 

If you can't get your campus to agree to such a statement, then it's almost a lost cause. (It probably is a lost cause in that case, but I've always had a sort on Don Quixote complex around this specific practice…)

 

--- Eric

 

From: [mailto:] On Behalf Of David Langenberg
Sent: Friday, March 07, 2014 5:42 PM
To:
Subject: Re: [Assurance] can two-factor be hacked ?

 

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