cancel
Showing results for 
Search instead for 
Did you mean: 

OpenID Guerrillas: Day Five

OpenID Guerrillas: Day Five

OpenID Guerrillas: Day Five

Yes we did meet up last night Smiley

  • Tam continued is work on some prototypes for how we'd model the login boxes for the community site with OpenID in mind. You can take a look at his current prototype concepts.
  • Colin has resurrected his work with combining OpenID with Cryptocard's two part auth system. He's been struggling with getting the RADIUS client working.
  • Paul consulted with Nigel (one of our architects) about how to get OpenID into our portal authentication system. There's a convenient spot for it to go in, a gotcha to do with accessing a PlusNet identity provider from a PlusNet webserver and the necessity of a security review of any code added intended for live.

What did I do? I refreshed myself on the phishing stuff following last weeks Cryptocard conversation. I was mostly working through the examples talked about in Marco Slot's Beginners Guide to OpenID Phishing. He describes 3 different 'levels of phishing' which openID is susceptible to. I've made the links available to our developers internally to make sure they are aware of thinking of these things. I can't help but wonder if you can get around the 'level 2' phishing approach via the use of some sort of referrer checking. I.e. are the images being loaded on this page being called from the correct OpenID login form. If not, display phishing warnings. Is that simple to get around? Or does it add a sufficient level of difficulty for the phishermen to not warrant the effort? Feel free to debate below Cheesy

 

0 Thanks
3 Comments
374 Views
3 Comments
Tamlyn
Grafter
Referrer checking on images is easily overcome by changing the image source to point to a proxy on the phishing server which loads the correct images from the identity provider by sending a fake referer header.
Kelly
Hero
Does that add enough faff to the phish attempt to discourage it? Or is it dead simple (tm)?
Tamlyn
Grafter
Seems fairly simple. In effect the attacker is indistinguishable from a genuine user so there's no way of preventing it from loading all the relevant content (text, images, stylesheets, scripts) from the identity provider. From that point it's just a case of spitting it out again to the victim of the attack. It's a tricky one.