> It would seem to me that two-factor authentication > (implemented correctly) would be perfect for this matter. > > I saw that someone wrote earlier that the one time token from the two-factor > could just be logged and entered in again real quickly. I don't know this > to be the case. For example, I have never been in an environment that used > RSA SecurID that would allow for a second use the the token. If I logged > into a website or box and then 5 seconds later tried to logon another (or > the same) machine, it would deny the authentication. IMO OTPs or two-factor > (pin + OTP) would be a great fit for this problem. >
That's true, as long as the first time you entered the OTP, it actually went to the right server. If the client computer is compromised, the user could have sent that OTP anywhere. A now common scheme is to set up a phishing website that returns the error message for an invalid OTP. The same server can then use a CGI script to set up an OTP validated session, and keep the cookie from timing out until a human comes along to siphon off some money. If you're really slick, you could fully automate moving the money too. Suggesting SSL is no guarantee, as the attacker can add all the trusted CA certificates he wants to the client's browser, and show a valid cert from his phishing site. It's been pointed out a couple of times now in this thread, and mostly ignored every time, that a sytem has to authenticate the transaction that is of value. In most cases, the value is not in the initial user authentication - in the example of banking, the transactions that are of value are money transfers. Someone (can't recall who) pointed out a rather elegant way to handle this: The user sets up a transaction with mouse & keyboard, submits this, then a signed description of the transaction is sent back. This description goes directly to the trusted device (USB token or the like), which verifies the bank's signature, and displays the transaction description on its own screen. The user uses a button on the trusted device to generate a signed confirmation or refusal of the transaction, which is sent back to the bank - only this signed confirmation will lead to a complete transaction. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
