WebApp Sec mailing list archives
RE: Proposal to anti-phishing
From: "Lyal Collins" <lyal.collins () key2it com au>
Date: Mon, 17 Jan 2005 09:12:59 +1100
You're right - there are 2 token models - the simple OTP approach I discussed, and the integrated transaction processing tokens. The second model assumes that the user's machine is not infected with spyware/backdoor trojans. In the event the user's machine is infected, it is a trivial process to link the serial No of the device to the user, by a) querying the device, and b) sniffing the user's authentication and c) sent to a central hacker's database. Need a) was docuemnted by Microsofts Smartcard demo programs in 1998, keyboard sniffers have been around longer (biometric sniffers are a coding exercise for the student) and graphical password sniffers were demo'ed in 1997 to my knowledge. This tuple can then be queried any time the token is plugged into an infected machine, and used to authenticate multiple trasactions - the one the user intended, and those the hacker intends. The result: the bank still doesn't know which transactions are real, but remains liable for guessing wrong. Preventing these issues has conventionally meant putting a keypad and display screen into the token, and electonic links between token and the user's machine (manual reentry of transaction details is too messy for customers). Overall, in my experience this pushes up the cost per token to ~$200 best case, and $1000+ in the worst case, once shipping, device power, customer support and software compatibility are managed for a good customer experience. Since fraud is nowhere these levels, the costs significantly outweigh the advantages. Lyal -----Original Message----- From: Frank Knobbe [mailto:frank () knobbe us] Sent: Monday, 17 January 2005 7:25 AM To: Lyal Collins Cc: webappsec () securityfocus com Subject: RE: Proposal to anti-phishing On Sun, 2005-01-16 at 17:38 +1100, Lyal Collins wrote:
To eapnd on this, there is nothing the stop the phisher capturing the
entire
session (i.e MITM tunneling), even using a valid OTP token to logon, and even a second OTP token to 'authenticate' a transaciton. With tunneling the entire session, the attacker can easily present the
user
with screens saying "transfer $200 to mum" while telling the banking site
to
'transfer $1000 to joe () hacking site.somewhere"
Not quite correct. Obviously you haven't used these token schemes. Most transactions that are authenticated/confirmed by tokens do include the values themselves. For example: Src Acct: 123-456 Dst Acct: 333-222 Amount: $1,000,000 AuthCode: (to be entered by user from token) The user receives/enters the values above, enters these into his token which will present a unique value (auth code) tied to his token, but also to the values. That means if a MITM hacker changes an account number or other value, the authentication code would different. Since the attacker does not have access to the users token, he can not generate a correct authentication code, and thus the transaction is invalid. Vasco's tokens are widely used amongst the financial industry (perhaps more so in Europe then the US). Back in the mid-late nineties when I worked with these tokens, they had a nice demo on their website that would explain/test the process. It could be used with their physical demo tokens, or the virtual token online. If you like further info on this process and a demo, see their web page. Maybe the demo is still online. In summary: Tokens don't just authenticate the user or the session, they are also used to authenticate *transactions*, which is exactly how MITM attacks are defeated. An attacker intercepting the transaction can not change values without invalidating the authentication code. Regards, Frank
Current thread:
- Proposal to anti-phishing Rafael San Miguel (Jan 14)
- RE: Proposal to anti-phishing Don Tuer (Jan 14)
- Re: Proposal to anti-phishing Rishi Pande (Jan 15)
- RE: Proposal to anti-phishing RSnake (Jan 15)
- RE: Proposal to anti-phishing Lyal Collins (Jan 16)
- RE: Proposal to anti-phishing Frank Knobbe (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 19)
- RE: Proposal to anti-phishing Sam Koh (Jan 23)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 19)
- RE: Proposal to anti-phishing Don Tuer (Jan 14)
- RE: Proposal to anti-phishing WebAppSecurity [Technicalinfo.net] (Jan 15)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 15)
- RE: Proposal to anti-phishing Lyal Collins (Jan 16)
- Re: Proposal to anti-phishing Moksha Faced (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 19)
- Re: Proposal to anti-phishing Rogan Dawes (Jan 19)
- RE: Proposal to anti-phishing Lyal Collins (Jan 19)