Assurance

[Steven Carmody <>]

On 3/11/14 12:18 PM, Cantor, Scott wrote:
> On 3/11/14, 11:36 AM, "Brian Arkills" 
> <>
>  wrote:
> > So they separate it from the MITM and relay attacks which I note that
> > Scott Cantor is including in this thread.
>
> Well, yes, but I didn't add that, it's the question that was asked. That
> *is* the attack that was under discussion.
>
> To some degree it's actually easier to carry out and more effective than
> the traditional phishing one actually can use a OTP to mitigate.

So, trying to summarize my takeaways from this thread:

1) The only way to actively defend against the MITM/proxy-based 
application/attack described in my initial note is to use credentials 
where the secret isn't shared, but rather is used to prove presence. The 
only implementation mentioned that supports this model is client certs; 
however, we all know how difficult it would be to have a large community 
use that model.

I do wonder, tho, whether Kerberos/SPNEGO might be as effective (even 
tho its also sort-of password based, but not on the wire).

2) The fallback approaches include:

a) user education. Please pardon my pessimism on that one. I understand 
ts importance, etc; I'm just not very optimistic that we could get even 
80% of our community to be educated on these issues.

b) reactive approaches. To quote David L:

> 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)

3) If the site being proxied is using two-factor, then this proxy 
approach can gain one-time access to the site as the user; however, the 
proxy approach would not allow the user's identity to be stolen and used 
to access other sites, or access the proxied site a second time.

4) I fear we've reached some sort of tipping point. The technical bar 
for developing a proxy of this sort has been significantly lowered (the 
bearbucks one cited in my original post was 120 lines of javascript; the 
available frameworks and libraries did all the work); the bar to 
deploying this kind of application has been significantly lowered (in 
the bearbucks case, they just uploaded it to meteor.com; I don't think 
there was any money transferred); the means for publicizing this sort of 
"aid"/tool/etc is the social networks available to everyone. Combined, 
we've reached some sort of milestone.

5) The campus can use policy to ban this sort of practice. Which is what 
Brown has done in this case. But, as David L noted:

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

6) The IT organization can provide infrastructure and help for students 
developing and deploying these sorts of applications. Help would include 
"carrots" to encourage them to proceed down certain paths and not 
others. For instance, back to BearBucks, there exists a javascript 
framework called PassPort which supports various authentication 
mechanisms, including, apparently SAML. So, there really isn't any need 
to implement a MITM attack. ;-)  Of course, students are going to want 
to experiment with the leading edge technologies, and the IT 
organization won't be able to move fast enough to keep them happy.

7) Proxies of this type aren't the only threat. A group of 
undergraduates here has approached the IT organization; as their CS 
Capstone project they want to implement a mobile app to access the 
Banner Student System. They could implement the same sort of 
screen-scraping approach, and our log files would never show a 
detectable pattern.

Building on #6, tho, we could deploy Shib in front of Banner, and have 
them use ECP. Their application would never see passwords.

Are there libraries for development platforms for mobile that make it 
easy to use ECP ? Does any site have experience with this approach ?

And thanks for all the thoughtful responses !