WebApp Sec mailing list archives

RE: Two-Factor Authentication on the Web


From: "Lyal Collins" <lyal.collins () key2it com au>
Date: Wed, 5 Jul 2006 22:25:22 +1000

Sure
Here's the "short" answer, imho
Server-side SSL depends on the reliability and accuracy of DNS records,
unrelated to the SSL certificate.  Secondly, SSL server certificates depend
upon humans in the issuing processes, or use 'lowest cost' methods of
automation.
Finally, studies repeatedly show people don't understand what they are
really agreeing to when they click "OK" or "Accept this certificate" alert
dialogs. 

Client side certs do help a little, as long as the human-dependent issuing
process is reliable, and the storage/processing platforms for the private
keys are up to the task.  But at best, today this means the server is
accepting the remote PC/smartcard's assertion that your password was
verified.  Without any consistent approach to user identity verification
(and control of this process in the age of malware) in browsers/smartcard
(_if_ the user has opted to enable this), how can the server make an
informed decision about the efficacy and reliability of this remote
authentication?  The server simply can't - and anyone asserting otherwise is
living in a state of profound error, imho.

In the absence of widespread solutions to the above, SSL remains a good
solution to the risk models of the early-mid 1990's.

Although I appreciate the technical security value of two-factor tools,
security only exists in the context of the vale it protects.  In a
cost-driven, risk-managed world, passwords and SSL are as good as each other
for authentication purposes in almost all jurisdictions I'm aware of.  

Even the US FFIEC regulations follow the rest of the world, and merely say
something along the lines of "do a risk assessment, and use two-factor if
the benefits justify it".  Phishing and on-line fraud are usually too small
a loss relative to the profits earned for the banks involved, thus the
benefits are almost always non-existent.  Customers just end up paying for
fraud through higher costs, and the status-quo remains entrenched.
</rant>

We can have more detailed discussion off-thread, if you like.

Lyal

-----Original Message-----
From: Popowycz, Alex [mailto:Alex.Popowycz () fmr com] 
Sent: Wednesday, 5 July 2006 9:42 PM
To: Lyal Collins; Webappsec Mail List
Subject: RE: Two-Factor Authentication on the Web


Lyal,

Would you elaborate as to why SSL is not a reasonable means for transporting
authentication credentials?  Properly implemented, SSL provides a fair
degree of security to the overall authentication transaction, especially if
invoked in a mutual  fashion (i.e. 2 way SSL).

Additionally, the option of staying with passwords isn't viable with various
laws and regulations around the world, especially in the financial services
sector.

Alex

-----Original Message-----
From: "Lyal Collins" <lyal.collins () key2it com au>
To: "Webappsec Mail List" <webappsec () securityfocus com>
Sent: 7/3/06 6:25 PM
Subject: RE: Two-Factor Authentication on the Web

There has been some excellent discussion on this topic. However, I think a
couple of important factors have been overlooked given the risk models that
are included or assumed in the discussion. 1. Most of the methods assume
that the authentications factors (password, biometric etc) are verified at
the host, requiring re-usable authentication data to be transported across a
network. 2. SSL is considered the 'obvious choice' for this transport.

This model is fundamentally flawed - SSL is simply not good enough for this
purpose when used en-masse.  SSH is hardly better, given the key
estabishment method boils down to "do you trusted these 16 hex characters".
PKI and client-side certs are merely client-side password cerification in
untrusted devices/environments.

Since the early nineties, it has been apparent that the better
authentication option is to use client side authentication (i.e data
capture, verification, etc) using a trustable, tamper-evident device, which
them communicates the auth state (i.e. "I am device abc and I have verified
this is entity xyz according to method 123") to the host in a trusted
fashion.

If we are serious about OTP, biometrics, etc we should really be pushing for
either significantly better mechanisms to transport authentication data, or
deploy cheap client-side authentication with trustable carriage of the
authentication data/state and ideally transaction data.

Otherwise, the ethical thing is to tell our employers to stick with
passwords and accept there is a modestly higher risk at a significant cost
saving, or invest in doing it better.

Microsoft's trusted computing platform is a start, but tries to be all
things to all communities of interest, leading to compromises and
difficulties for all.  For strong authentication, the MS model is basically
flawed.

Just my 2-cents worth.

Lyal





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

Securing a web application goes far beyond testing the application using 
manual processes, or by using automated systems and tools. Watchfire's 
"Web Application Security: Automated Scanning or Manual Penetration 
Testing?" whitepaper examines a few vulnerability detection methods - 
specifically comparing and contrasting manual penetration testing with 
automated scanning tools. Download it today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmm
--------------------------------------------------------------------------




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

Securing a web application goes far beyond testing the application using
manual processes, or by using automated systems and tools. Watchfire's
"Web Application Security: Automated Scanning or Manual Penetration
Testing?" whitepaper examines a few vulnerability detection methods -
specifically comparing and contrasting manual penetration testing with
automated scanning tools. Download it today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmm
--------------------------------------------------------------------------


Current thread: