RE: Two-Factor Authentication on the Web

["King, Stuart (REHQ-LON)" <Stuart.King () reedelsevier com>]

I concur with Andrew - shared secrets are not 2FA. I think some OWASP
guidance on implementing 2FA for web applications, and information about
some of the available options would be very valuable. 

-----Original Message-----
From: Andrew van der Stock [mailto:vanderaj () greebo net] 
Sent: 28 June 2006 15:19
To: rsd () sdf lonestar org
Cc: Webappsec Mail List
Subject: Re: Two-Factor Authentication on the Web

The guidelines are about protecting consumers, their identities, and  
the value of the transaction, not generally access to the account  
itself or saving your firm's bottom line. So instead of worrying  
about adopting yet another stale technology which does not solve  
phishing or identity theft, seize the opportunity to move to the next  
step and reduce identity theft and fraud.

Q&A's (shared secrets) are truly appalling. They should not be used  
under any circumstances. Most of the questions are on the public  
record (DMV, voter registration records, births/deaths/marriages,  
etc). Many of the others can be found using Google (what's my pet's  
name... hint you do not have to look hard. For extra points, what's  
the color of my other cat?), and some questions like what's your  
favorite color is usually "red" about 75% of the time, "blue" the  
next 20% of the time, and then a smattering of other colors. Good  
Q&A's are open ended questions which are hard to find out, lots of  
answers, but easy to remember... like where did you take your first  
holiday. Which as a question sucks if you're a famous author like  
Gerrard Durrel (the answer is Corfu). So basically, once you  
eliminate all the well known Q&A's people CANNOT remember the answers  
to them. Strike round one.

Online loan apps are particularly hard to secure - they are prime  
phishing targets. If you know a lot about your customer already (as  
in they already have a relationship with you), do NOT ask for any  
information you already have, and do not show it. This makes it less  
likely that phishers will target you.

IMHO, for online banking, the day of the password has been over for  
about two years now. OTPs alone is rapidly approaching the same end  
zone. However, you *should* be using one time passwords (ie token  
login) with limited time outs for authenticating to your service on  
to deter batched / delayed MITM and replay attacks. However, OTP will  
not prevent phishing attacks logging onto your customer's accounts  
and pharming the details found within.

So:

a) access to information inside the account which is useful in a  
online loan application should be utterly minimized or completely  
eliminated, or at worst only available via transaction  
authentication. This diminishes the phishing information gathering  
surface area for your app and phishers will choose weaker or stupider  
targets

b) value transactions which are hard to reverse, such as pay anyone,  
should be performed via transaction authentication. Your  
institution's taste for risk will determine how often and which  
destinations attract transaction authentication. My preference is do  
'em all. But that might be a PITA. For example, paying a "bill" to a  
Western Union destination is basically asking to be phished, whereas  
paying a bill to a trusted utility which does not offer cash  
reversals once a bill is overpaid is unlikely to be phished and you  
may let that go.

c) Applications for credit should be rare enough that taking a hit  
for a OTP or transaction authentication is a really good idea.

Always think in terms of authenticating the transaction, not the  
person. The person should possess the means of authenticating the  
transaction, such as a transaction signing calculator or mobile  
phone. I am sure phishers will work out a script or scenario for  
these babies eventually, but that day is not today.

Tokens which are capable of OTP and transaction signing are not that  
much more expensive than pure OTP tokens, and they are cheaper than  
USB connected tokens, which are no better than hard certs (ie smart  
cards). Connected tokens are the devil's work, and should be avoided  
as they do not prevent the user pressing "yeah, whatever" whenever  
you ask for a transaction to be signed. That's not transaction  
signing, that's a recipe for phishing, particularly if your app asks  
for trx signing on a regular basis.

Pay Bill 1 - yeah, whatever.
Pay Bill 2 - yeah, whatever.
Pay Phisher - year, whatever.
Pay Bill 3 - yeah, whatever.

It happens in MacOS X, and it'll happen in Vista. It's human nature  
not to read the security prompts. Make the human part of the  
transaction, and not "yeah, whatever."

SMS texting works *really* well... As long as you have a solid way of  
registering the mobile phone and as long as the local carriers have  
phone cloning under control. Phishers think nothing of ringing up a  
bored $4.95/hr help desk jockey, and making several guesses as to  
your pet's name and favorite color (red! no blue!) and changing your  
cell phone number to their own stolen or throw away pre-paid phones.  
Registering or changing the number should be done in person, with a  
strong emphasis on showing lots of photo ID.

thanks,
Andrew

-------------------------------------------------------------------------
Sponsored by: Watchfire

As web applications become increasingly complex, tremendous amounts of 
sensitive data - personal, medical and financial - are exchanged, and 
stored. Consumers expect and demand security for this information. This 
whitepaper examines a few vulnerability detection methods - specifically 
comparing and contrasting manual penetration testing with automated 
scanning tools. Download "Automated Scanning or Manual Penetration 
Testing?" today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000008BOQ
--------------------------------------------------------------------------