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:
- RE: Two-Factor Authentication on the Web Gaydosh, Adam (Jul 02)
- <Possible follow-ups>
- RE: Two-Factor Authentication on the Web Glenn.Everhart (Jul 03)
- Re: Two-Factor Authentication on the Web Andrew van der Stock (Jul 03)
- RE: Two-Factor Authentication on the Web Lyal Collins (Jul 03)
- Re: Two-Factor Authentication on the Web Andrew van der Stock (Jul 03)
- RE: Two-Factor Authentication on the Web Popowycz, Alex (Jul 03)
- RE: Two-Factor Authentication on the Web Popowycz, Alex (Jul 05)
- RE: Two-Factor Authentication on the Web Lyal Collins (Jul 05)
- RE: Two-Factor Authentication on the Web James Pujals (Jul 05)
- RE: Two-Factor Authentication on the Web PPowenski (Jul 06)
- Re: Two-Factor Authentication on the Web mikeiscool (Jul 07)
- Re: Two-Factor Authentication on the Web Devdas Bhagat (Jul 17)