[LINK] PayPal to combat phishing with key fobs

Craig Sanders cas at taz.net.au
Sun Jan 14 16:19:49 AEDT 2007

On Sun, Jan 14, 2007 at 03:08:01PM +1100, Rick Welykochy wrote:
> Alan L Tyree wrote:
> > What other technical methods might be used to prevent (or at least
> > curtail) phishing? Is there some sort of challenge/response approach
> > using software supplied by the Banks or other targets? I need to
> > look at some positive suggestions for this EFT Code review.
> There needs to be an additional form of authentication that has
> absolutely nothing to do with the website.
> Thus we have ideas like nonce generators which create a unique token
> that must be passed back to the server for matching.

that's pretty much what the key-fob thing is. it generates a code each
time the button is pressed which must be supplied along with the login
id & password.

it provides a second level of authentication - something you HAVE (the
key-fob), as well as something you KNOW (the password).

> But what about a phishing attempt that just asks for a username and
> password, and offers no nonce authentication. At most, the hapless
> user might notice that the server

if the banking site requires the unique code as well as the login &
password, then the phisher only ends up with part of what they need to
loot the account.

i have one for my (Bendigo Bank) account. if i want to login, i have
to have it with me. i'm reasonably happy with the level of security it
provides. i'd be happier still if (see below), i could upload a client
certificate to my bank site as well and restrict logins to browsers
holding that cert.

> One might think that a digital cert would do the trick. But with a
> phishing attack, there is no requirement for authentication, and thus
> the cert would not even be sent by the browser.

about the only thing that might work is client-side certificates.

all banking sites need to do to enable that is to have an option where
the user can upload their public certificate and click an option that
says "only allow connections from this certificate".

alternatively, a button at the bank site to generate a client
certificate and download it to the client.

of course, phishers can still attack windows users by sending out
viruses/trojans that look for and steal certificate files. fortunately,
it is possible to protect them with a pass-phrase (which doesn't get
sent to a remote web site).

a client certificate would be another instance of "something you have"
- another level of authentication...but because it's digital and is on
the client's computer, is easier to copy/steal than a separate hardware
device like a key-chain gizmo.

> Phishing is very difficult to curtail with just technology, since it is
> a problem rooted in social engineering more than anything else. The user


> is fooled into thinking that http://westpac-access-check.com/ is a bonfide
> Westpac website. And worse, the email in which the phish is sent shows
> a valid Westpac link (as text) but the hidden hyperlink is to a bogus
> site. Hapless victims have no idea that they should (a) never click on
> links in emails unless they trust them 110% and (b) always verify the
> hostname in a URL.

actually, they should never click on email links to non-trivial sites,
regardless of how much they trust the site - because they have no idea
whether the link is actually to the site that it is claiming to link to,
nor do they have enough knowledge to make an accurate assessment of the
trustworthiness of a site.

better just to say "NEVER click on links in email".

that would help a lot, especially if coupled with banks getting a clue
and NEVER sending email to their clients, and loudly informing them
on every visit to their site that they NEVER send email so any email
claiming to be from them MUST be a forgery.


craig sanders <cas at taz.net.au>           (part time cyborg)

More information about the Link mailing list