Thursday, March 08, 2007

security tokens don't protect against phishing

you never know when you're going to come across a train of thought so thoroughly wrong it deserves to be debunked... that's what i learned today (hey, i haven't gone to sleep yet, it's still officially today) when i read david maynor's blog entry where he mentions thinking that with a paypal security token he won't have to worry about where he enters his paypal credentials anymore...

gold star if you're shaking your head just thinking about that... security tokens, generally part of a 2 factor authentication system (where you prove who you are using something you know, like a password, and something you have, like a token), won't protect you against phishing - at least not completely... the simplistic phishing attempts that we're familiar with right now would be thwarted by 2 factor authentication but not only can the practice of phishing adapt to 2 factor authentication it's already started to do so...

phishing schemes using man-in-the-middle attacks have already been spotted in the wild and some specifically support 2 factor authentication...

the reason phishing is possible is the same reason man-in-the-middle attacks are possible - one end of the communication (in this case the phish site) hasn't been authenticated... you can strengthen your own authentication until you're blue in the face - even 3 factor authentication won't help you if you don't know for sure that the person you're talking to really is who they claim to be...

site authentication is a hard problem, though, a lot harder than people give it credit for... as i've said before, site authentication schemes that work by placing something on an authentic site to prove it's authentic won't work very well because we just aren't all that good at noticing when something is missing (which it theoretically would be for a fake site)... i also don't understand what's so special about things like site authentication images that prevents them from being spoofed by a man-in-the-middle attack as well - the attacker's system should be able to pull the proper image from the real site so long as it sends the same identifying information to it that the client normally would have...

sender authentication isn't quite as hard a problem, though... perhaps david should read my post about avoiding phishing emails the easy way so that he can harden up that soft spot he has for paypal phish...

6 comments:

David Maynor said...

y post was dripping of sarcasm. I also don't decide which request for my paypal creds to reply to,

Anonymous said...

" ... site authentication schemes that work by placing something on an authentic site to prove it's authentic won't work very well because we just aren't all that good at noticing when something is missing."
If you want a site authentication scheme that doesn't rely on the users paying attention, try Passfaces - www.passfaces.com.

Anonymous said...

Good Stuff, Kurt. A couple of comments:

1. If the tokens were used for validating the transactions instead of sessions, they would help stop phishing.

2. Some two-factor solutions, such as ours, include host authentication as well as session auth, so they would stop MITM attacks. However, they would require the banks to deploy software, and they are very, very reticent to do that.

Nick

kurt wismer said...

@david maynor
re: dripping with sarcasm

i'm glad to hear it... there was a sarcastic quality to my post too, unfortunately some people really do believe a security token will protect them from phishing and those types may not recognize your sarcasm for what it is...

kurt wismer said...

@anonymous
re: passfaces

i took a look at the site and in fact you're right that it does get around the problem of users not noticing when something is missing...

unfortunately, it does not protect against man-in-the-middle attacks and so doesn't really authenticate the site...

kurt wismer said...

@nick owen
1) i'm not sure transaction validation would really stop phishing... consider that there are circumstances where failure is expected with a token (for example if you entered the security code too close to the timeout for the current code)... a man-in-the-middle could send you a false failure message (pretending that a real failure condition was met) and then use your authentication data to send his own transaction...

2) i can see how client side code can help, in fact i think strong site authentication will probably need it, but it's problematic for each and every site that requires a logon to deploy custom systems... a site authentication framework needs to be developed and made into an open standard (and probably build support into the browsers) for this to really be effective against the general phishing problem...