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