Phishing

but they're only not because there's no need to, with natwest killing their system after seeing a lot of people fooled, it's likely they're going to start doing it, there's no technical reason why they aren't.

If the cost really is 50p then I'm sure we'll see it come, I'm not so sure that is a true reflection of the cost, so with it not being foolproof defence against phishers, will it be worthwhile?

Jim.

Reply to
Jim Ley
Loading thread data ...

Scripsit "Tumbleweed"

It's more difficult to implement - for example you probably have to do the account-draining very soon after the victim has helped you authenticate himself, lest the bank's trust in you expires. That means that the draining phase will have to be automated. Crooks will probably not expend the effort to do so, as long as there is an adequate supply of guillible people that you can cheat static passwords out of and then *later* drain their accounts at your leisure.

However, if everybody switches to challenge-response systems, market forces will drive phishers in the same direction. It's not much harder to phish in that way, just takes a tiny mit more labor to set it up.

Not completely, but they only work as long as the user takes care not to give them to phishers.

Reply to
Henning Makholm

I rather read the thread as an almost literal man-in-the-middle. Nearly posted saying this can't be a problem; then thought again (always worthwhile :-) )

How about: customer (C) goes to phishing site (X). X connects to real bank site (B) and gets challenge and passes to C. C provides correct response to X. X uses this to authenticate itself to B. It can now, presumably, carry out both C's legitimate business with B, as well as its own, essentially *at the same time*.

Am I missing something?

One possible extra layer of protection be to specify permitted client IP ranges, although this would be inconvenient for some.

It doesn't have to be 'later' if the above is a feasible scenario.

Nothing's yet been built that can't be broken by someone with enough interest in doing it.

Reply to
Mike Scott

"Mike Scott" wrote

Of course, there *is* a way around this problem :-

*Each* separate transaction could have a "challenge/response" code. So, the first CR simply gets the user into the system. If (s)he wants to move money (say), then another CR code is required, which depends on the particular transaction to be authorised.

"Real" customer wants to move 50 to ABC - CR code entered & bank allows the transaction. "Phisher-in-the-middle" tries to move 10,000 to XYZ - but cannot, as (s)he doesn't know the correct response to the challenge for *that* transaction. Of course, the *real* customer doesn't want to make that transaction, so (s)he isn't going to tell the phisher the required CR code to enable it!

Reply to
Tim

Rather tedious for the user! It still wouldn't stop a single attack replacing the user's transaction (X hijacks C's response and does its own one-off thing with B), unless, I suppose, the challenge incorporated information about the proposed transaction: then all X could do would be mimic the desired transaction, which wouldn't matter too much.

Given what I read on the upc.ebay group, your closing comment may be overly optimistic :-)

Reply to
Mike Scott

"Mike Scott" wrote

Agreed, but what price greater security?

"Mike Scott" wrote

It'll stop it because the response won't be valid for any other transaction (different amount or destination).

"Mike Scott" wrote

As I said in my previous post - "another CR code is required, which depends on the particular transaction to be authorised".

"Mike Scott" wrote

Exactly! [Altho' the system would be set up so that a second transaction, *exactly* the same as the first, would need different CR codes anyway - then the phisher couldn't even put through multiple versions of the same transaction.]

"Mike Scott" wrote

Eh?! [Perhaps a synopsis of what you read may be interesting?]

If the phisher (pretending to be the bank), asked the "real" customer what the response code was for a transfer of "10,000 to 'Mr. Phisher' " - and the customer stupidly gave the correct response to the "bank" (ie the phisher) without wondering why (s)he was being asked, the perhaps the customer shouldn't be using the Internet at all?!! :-(

Reply to
Tim

Tim wrote: ...

'read' - (continuous) present tense, as opposed to past tense. Just a general tendency for apparent idiocy among the (ebay-using) population. Like not understanding the instructions on screen right in front of them. I'm very much afraid that if a site unexpectedly says "enter your next password" or some such, there will be those who do just as they're told.

Reply to
Mike Scott

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.