As most of you rightly said , Yes we need user education, educating
the users what they should do rather than educating them on latest
phishing techniques.

Thinking aloud - Is it possible for URL filtering
vendors/anti-phishing toolbars to have whitelist categories instead of
blacklist categories ? Anyways both seems to be equally big !

On 7/27/06, Omar A. Herrera <omar.herrera (at) oissg (dot) org [email concealed]> wrote:
> I agree completely, 2 factor authentication doesn't necessarily mean 2 way
> authentication, and tokens are a good example of that. This is not new, it
> is well known limitation resulting from the design of these solutions (i.e,
> they don't fail, they do well what they were intended to do, but they can't
> provide what is actually needed for the expected level of security in this
> context).
>
> I would just suggest that in addition to 2 way authentication we also need
> to extend the trusted authentication channel closer to the user (and
> probably closer to the transaction servers on the side of the banks as
> well). What I mean is that we usually put in place security measures to
> ensure secure authentication and information transfer through the network
> but forget about the user's terminal.
>
> Installing a trojan horse in the victim's computer to read the token PIN
> would work similarly against an N factor, 2 way authentication because the
> attacker might just need to piggyback into the already established secure
> channel that ends at the computer and not at the user's hands). It is not
> enough for access controls to be physically independent from the terminal
> (as with tokens). They also need to implement way for secure authentication
> assuming that the terminal is not secure.
>
> A good example of 2 factor, 2-way authentication that can do this: smart
> cards with authentication taking place on-chip using preloaded certificate
> from the bank and a reader with independent keyboard (the computer would
> become part of the untrusted communication channel like the Internet). The
> same concept can also be extended to authorizing transactions (that should
> prevent piggybacking into the trusted channel in the case of compromised
> computers as well). This would effectively stop many phishing and malware
> attacks and this is as good as it gets in respect to online transactions and
> authentication. Question is why the banks believed (we assume that all of
> them did a proper risk analysis) that this level of security wasn't worth
> the cost (and the inconveniences for the clients). Sometimes it is cheaper
> to patch/pay that to try to prevent all possible frauds, and that's a common
> business decision (understandable, but let us hope it was justified
> correctly).
>
> Like other people pointed out already, there is no perfect security. An
> attacker within the bank that is able to access data outside the secure
> channel and an attacker threatening (e.g. with a gun) or tricking users into
> making a fraudulent transactions can still be successful. Why try to break
> robust encryption algorithms without the resources of the NSA when bribing a
> call center guy within the bank or tricking the victim into giving away
> enough information to do fraudulent on-line purchases is easier for
> criminals?
>
> As long as we keep seeing the security of financial transactions as an
> isolated set of patches there is no way to offer an acceptable level of
> security. It is not about implementing best practices (i.e. "if most of the
> banks use recommend/tokens then it should be a security good solution") it
> is about understanding clearly what the situation is (not only seeing it as
> isolated problems), knowing what the existing solutions can (and can't) do
> and then selecting and implementing some of them, being aware of the
> limitations and the risks we are accepting. That's my opinion.
>
> Cheers,
>
> Omar Herrera
>
> > -----Original Message-----
> > From: Domenico Rotondi [mailto:D.Rotondi (at) Computer (dot) Org [email concealed]]
> >
> > On 27 Jul 2006 at 12:04, shakti velu wrote:
> > My 2 cents contribution:
> > all authentication technologies that assume the user must authenticate
> > itself to the
> > service (bank, on-line books shop, ...) can be defeated.
> > We must reverse the approach: its the service that must prove its identity
> > to the user
> > before this one proceeds.
> > I described a concrete solution using this approach (see:
> > http://www.w3.org/2005/Security/usability-ws/papers/06-rotondi-
> > authentication/).
> > Regards
> > Dom
> > > Are we concluding there are no technology solutions possible to
> > > prevent phishing?
> > >
> > > If not preventive , do we have reliable detective and incident
> > > response measures possible ?
> > >
> > > On 7/27/06, Tim <pand0ra.usa (at) gmail (dot) com [email concealed]> wrote:
> > > > Let them know that from now on in order to log in they will be
> > > > required to submit a hair and blood sample to a biometric device
> > > > attached to the computer. Additionally their passwords are to be
> > > > replaced with passphrases that are a minimum of 32 characters and
> > > are
> > > > required to use Alt character sets in addition to upper and
> > > lowercase,
> > > > numbers and special characters. Finally, they are required to have
> > > an
> > > > RSA token surgically embedded into the underside of their
> > > forearm.
> > > >
> > > > Technology is not a panacea. Phishing is a form of social
> > > engineering
> > > > so you need to figure out what staff is doing to compromise the
> > > system
> > > > and show then what they are doing wrong (don't just tell them). I
> > > have
> > > > done quite a few social engineering attacks against people and
> > > they
> > > > had no idea what was going on. Once you show them (not tell them)
> > > they
> > > > should have a better idea on what to do. You know what phishing is
> > > and
> > > > what the impact is but since there are some users that 'don't get
> > > it'
> > > > the challenge is to figure out how to make them care (make it
> > > personal
> > > > to them).
> > > >
> > > > That's my 2 bits.
> > > >
> > > > On 7/26/06, shakti velu <shaktivelu88 (at) gmail (dot) com [email concealed]> wrote:
> > > > > We spent lot of time educating users - please use two-factor,
> > > it will
> > > > > solve your phishing problems.
> > > > >
> > > > > Now we tell them Sorry, Two factor is of little use ! what next
> > > ?
> > > > > three factor , biometric !
> > > > >
>
>
>

[ reply ]