full-disclosure - Re: Most common keystroke loggers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <70f230c70512220022q688ba8a6tf37064ee0da5942f@mail.gmail.com>
Date: Thu Dec 22 08:22:52 2005
From: senatorfrog at gmail.com (Mark Senior)
Subject: Re: Most common keystroke loggers?

>  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.