Two-Factor Authentication on the Web
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
RE: Two-Factor Authentication on the Web
by Lyal Collins
::
Rate this Message:
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 -------------------------------------------------------------------------- |
|
|
|
|
|
RE: Two-Factor Authentication on the Web
by Lyal Collins
::
Rate this Message:
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@...] 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@...> To: "Webappsec Mail List" <webappsec@...> 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 -------------------------------------------------------------------------- |
|
|
RE: Two-Factor Authentication on the Web
by James Pujals
::
Rate this Message:
>> "How could your DNA (I would waver on this one
since I heard somewhere that twins could have the same DNA), fingerprint, retinal scan, etc, not be unique to you and only you? Nor am I buying the movie version of someone getting their finger cut off by a thief for accessing their bank account or maybe I am misunderstanding what you are trying to say." I see I didn't explain myself properly. My DNA, fingerprint, or retinal scan is perfectly useless for authentication unless there is a "known" baseline copy stored by the authenticating system to compare it to. That means that my DNA, fingerprint, or retinal scan does not prove who *I am* as an individual, but it proves that I am whomever your system associates with its stored credentials, be it a specific customer, citizen, employee, or pet. This makes the security of the registration process a highly critical point for the integrity of the system. And since part of the topic at hand is remote enrollment for online web applications, this dependence on the "infallibility" of biometrics is dangerous. -dZ. ________________________________ From: Tim [mailto:pand0ra.usa@...] Sent: Fri 06/30/2006 20:04 To: James Pujals Cc: Andrew van der Stock; Webappsec Mail List Subject: Re: Two-Factor Authentication on the Web The 3 factors of authentication are: Something you have (i.e. a token, card, etc) Something you know (i.e. a password) or Something you are (i.e. a fingerprint, DNA, etc) "But even when biometric authentication "works", it still does not prove my _identity_, it just proves that I am who *I said* I am, which is another thing entirely;" Umm... I don't follow. How could your DNA (I would waver on this one since I heard somewhere that twins could have the same DNA), fingerprint, retinal scan, etc, not be unique to you and only you? Nor am I buying the movie version of someone getting their finger cut off by a thief for accessing their bank account or maybe I am misunderstanding what you are trying to say. Currently, with ID theft you don't see bad guys walking up to people on the street, point a gun at them and demand their SSN, or credit cards do you? Based on history, the tendency is to subvert the technology, not attack people (in regards to personal information). Also, from what some vendors have told me is that the technology requires blood pressure in order to work correctly (but I have read that it can be subverted by silly putty). Remember I am not saying that the technology is perfect, I am saying the concept of biometrics is what can valdate someones identity because it is something of us. On 6/30/06, James Pujals <james.pujals@...> wrote: > Hello: > But even when biometric authentication "works", it still does not prove my _identity_, it just proves that I am who *I said* I am, which is another thing entirely; and some might say is its most obvious point of failure. What's worse, as opposed to other 2-factor authentication methods (e.g. something I have, something I know), the "something I have" with biometrics, or as you say the "something I am" is not easily or practically replaceable if by chance it gets subverted. And thus, given its inherent value and importance to its owner (I'm pretty sure we all want to keep all our fingers, eyes, etc.), the more value placed on the payload it guards (i.e. bank account, medical records, credit history, etc.), the higher the risk increases for its owner; as not only can someone clean up your savings account, but they will necessarily have to kill, maim, or otherwise molest of you in the process. > > -dZ. > > ________________________________ > > From: Tim [mailto:pand0ra.usa@...] > Sent: Fri 06/30/2006 11:45 > To: Andrew van der Stock > Cc: Webappsec Mail List > Subject: Re: Two-Factor Authentication on the Web > > > > What I was trying to say is that you can only authenticate someone > through biometrics because it is something that they are. I do not > dispute that technology can be subverted or that people can be > manipulated. What I am trying to say is that a label (name, ssn) > cannot be trusted, especially nowadays. I feel the same in that > regristration would have to be done in person but again that is > impractical. Again, I am not saying that the current biometrics > technology is an adequate solution. Just that the concept of > biometrics is the only way to validate someone's identity. > > You seem to be very familiar with biometrics, can you provide some > examples of products that you have experience with that you would > consider to be a scam and what ones (regardless of expense) are > adequate? > ------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- |
|
|
|
|
|
Re: Two-Factor Authentication on the Web
by Silky-3
::
Rate this Message:
On 7/6/06, PPowenski@... <PPowenski@...> wrote:
> http://www.theregister.co.uk/2005/04/04/fingerprint_merc_chop/ > > Carjackers swipe biometric Merc, plus owner's finger honestly, this guy should sue mercedes. this absoutely had to forsee this possibility and they did not care. something like that needs to happen so that we can finall put an end to the stupidity that is biometrics. -- mic ------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- |
|
|
Directed phishing attacks- protection methods
by Joshua Perrymon
::
Rate this Message:
Here is one phishing site for paypal http://www.yourfreespace.net/users/payal/webscr_cmd=_login-run.html >>> This is not a bad job of duplication. However, pay-pal and similar sites are used may too much for this type of attack in my opinion. The phishing email would be probably sent to every email address they could harvest setting off every alarm Websense has. Phishing attacks are most affective when duplicating something like OWA or Citrix portals.. Or even better -- Custom built company portals facing the net and only sent to a handful of addresses gathered from company X. One interesting note about the site above is that it seems to relay it's data back to the attacker using POST instead of relying on an underlying mail program/script.. ------ POST data from the phishing site above--- HTtp://www.yourfreespace.net/users/payal/Processing+Login.html?login=done0%3 F847&password=1&email=1&altaddr=1&checkguar=1&PPIPProtPlus=PASS_encIP=62.245 .23.454&enctype=blowfish&continue=ProcessingLogin&acceptlogin=pass&acceptpas sword=pass&LoginAttempt=SecureLoginPass&SecurityMeasureCode=noneb2baf0b6a57d 39abd6c44b48d6fe3559112c21e54b7e705ecc5116b3c7c38c37949e8aa81848934faf0821be 04210e8c2ded3c4159edbee3ee1439f3892a3e9&Access=1&Submit=ProcessingLogin&cmd= _login-processing&login_cmd=_login-done&login_access=11680108541 ---------------------------------------------------------------------------- -------------------------- Protecting against this type of attack??? I don't know of many existing content gateways / email filters that will stop the initial email if the attack is a one-off and sent on a small scale. It's just some verbiage with an <A> and link to the attackers IP address or site hosting the phsihing site. A lot of times the web servers have been compromised and the http server is on a non standard port unless port 80 wasn't used before. Then when the user clicks on the link the in the phishing email it opens the browser w/o triggering any alarms.. ( I haven't visited any sites that the new M$ phishing filter picked up from its whiltelists) Enters password.. game over. The attacker now logs in using the new harvested credentials .This also works with token password generators ( nothing new here ).. Given it's only a 60 second window to login after acquiring the first token code. Ideas???_----- End-User security awareness and training is the most important deterrent. Whitelisting isn't going to stop small footprint attacks directed at a single company and a handful of users. Most companies believe that blocking HTML in email handicaps emails effectiveness.. ( screw the newsletters.. put it on a website ) Users should copy links from the email into the browser but don't. Certificates will protect where tokens fail. Network Protection: I believe that it's possible to develop "widgets" to alert on this type of directed phishing attacks. First you have to have the ability to monitor all emails traffic. This shouldn't piss off legal because all users should have already signed off on this. The most effective would be to monitor all known public email addresses. Including "planted' email address placed in forums and webpages to be harvested. This would provide a greater % that traffic sent to those addresses are directed attacks.. (Like an Email Honeypot :) ( yes... need to copyright that one quick muhahah :) It should be easy to develop an analysis to pick up on standard phishing emails. You would look for Anchors / links with IP addresses that resolve outside of the "known- whiteliested" address list. This should at least alert and place the email in a second level queue for analysis. You could also do some type of grep on the email link looking for company X verbiage. M$ Phishing filter may even be USEFUL ( Almost.... ) So using the methods above you would have a system to alert on potential phishing attacks scanning all emails or preferably only public emails included "planted" ones. The widget performs analysis to determine if the email is a phishing attack. This process could be automated to perform the whois so on. So now we should have determined the IP or block for the hosted phishing site. We can use something like M$ phishing filter. Send it the new whitelisted IP address of the phishing site and the browser should block the site. If the widget monitors all emails coming into the company then it should have the ability to do some trending of who received certain emails.. sorted on subjects for instance. One you found the phishing email you would have a known list of all email addresses that received the email once the attack has been spotted. This could be used as additional analysis to monitor traffic after the attack. Just some ideas I have had. If anyone is interested in working with us on developing something like this get in touch with me: Josh.perrymon@... CEO www.packetfocus.com www.packetfocus.blogspot.com ------------------------------------------------------------------------- Sponsored by: Watchfire Cross-Site Scripting (XSS) is one of the most common application-level attacks that hackers use to sneak into web applications today. This whitepaper will discuss how traditional CSS attacks are performed, how to secure your site against these attacks and check if your site is protected. Cross-Site Scripting Explained - Download this whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmr -------------------------------------------------------------------------- |
|
|
Re: Two-Factor Authentication on the Web
by Devdas Bhagat
::
Rate this Message:
On 28/06/06 23:41 -0600, Tim wrote:
> Risk Based Authentication is a good idea as it goes back to 'why spend > more on security controls then the value of the data'. I got to check Catching up on older mail here. There is a fatal flaw in the "why spend more..." philosophy when it comes to dealing with shared data. Shared data has different values for different parties involved. For a bank, customer personal data is a one in a million statistic. For that customer, it is one in one. If my personal data is compromised, I get hit really hard. The bank does not. So how much should data be valued at? Perhaps valuing it at the entire net worth of the customer(s) involved would be realistic? Or should the bank have to bear the entire burden of loss attributable to that data compromise? > out Ira Winkler's speech the other week and he made an interesting > comment in that money for security, most of the time, comes out of the > IT budget. The problem with that is the cost of securing the data may > cost more then what the IT budget can afford. If you are responsible > for securing data that could cost tens or hundreds of billions, why > would you only use 5% of the IT budget to protect that investment? > Because the problem with valuing data is that different entities have different values for the same data. The organisation may not value the entire dataset as being worth billions, and if the risk is losing a few thousand of a billion records, then obviously that is the total value that the organisation will try to secure. Devdas Bhagat ------------------------------------------------------------------------- Sponsored by: Watchfire Cross-Site Scripting (XSS) is one of the most common application-level attacks that hackers use to sneak into web applications today. This whitepaper will discuss how traditional CSS attacks are performed, how to secure your site against these attacks and check if your site is protected. Cross-Site Scripting Explained - Download this whitepaper today! https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmr -------------------------------------------------------------------------- |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
