This is about when you are not using transaction signing, but only using a time sync, or other simple OTP to authorise transactions

i.e. “type your time generated OTP to allow this visa transaction”

it allows a man-in-the-middle can use that OTP to authorise any transaction at that time or sequence, and the end user cannot be sure that the details on screen are the same as the details being transmitted to the bank, if his screen, or network connection are under someone else’ control.

The caveat is that we have no idea how the Pin Sentries are creating their hashes/transaction sigs, and the generation of their time-synced login codes are not looking like anything standard/approved, as the start of each “one time code” is very closely associated to the previous codes, and is definately not using any secure hash that I’ve ever seen.
This means that if the code is not created in a safe way, someone may be able to adjust the details. Unless the spec for the pinsentry is published for public scrutiny, we can’t be sure. (NOT FUD! It may be just fine, we just don’t know! Without public standards, we have no idea, and no approved OTP standard would ever produce a sequence of codes as similar as those created by Pin Sentry.)

From the point of view of shoulder surfing, it’s still vulnerable.

From a user convenience point of view, it’s frustrating to many users to have to carry the pin sentry, or it’s peers, around with you everywhere that you want to use e-banking.
(”after 15 years, pin sentry was the final straw, I’m leaving Barclays” link)

We’d still maintain that bank customers should be given the option to use a mobile token if they chose, so that they don’t have to remember and carry additional hardware. (It’s a greener solution too!)

p.s. If you know which hash standard Pin Sentry uses, please let us know, at least to settle the nay-sayers.

PS Actually it can, but I’m not telling

But, I could not catch the point
of the sentense in OTP Attacks section that
“The problem is that when the
user types in the code to sign,they have no idea what transaction they are really signing”

Please give the additional
explanation about this context.

It’s well known in the security community that simple biometrics like thumb-prints have been compromised for years. (Even ultra expensive 3D thermal scanners have been defeated by a photocopy and saliva)

The whole point of soft-tokens for 2FA, (and innovations for the workflow of these soft-tokens, such as GrIDsure, made to overcome the hackability of software,) is to create additional security without additional hardware.

Additional hardware is expensive, in cumbersome to the users and operators, and in the case of biometric scanners, can become a huge waste of redundant hardware once someone publishes straightforward means of defeating it using selotape.

I’m not saying that biometrics is pointless – security is a journey, not a destination, and each component, although defeatable, adds up to make it harder to circumvent.

We’d like to get the best out of cheap, rapid to rollout, non-hardware ideas first, before trying to re-equip every user, ATM or PC in the world with hardware that may only a few years later just choke another land-fill (which are probably already receiving their first big batches of expired plastic SecureID OTP keyfobs already!)

home routers hacked to redirect users to phishing sites

“Given the simplicity of the attack and the potential widespread implications, we always felt that it would simply be a matter of time before it happened,”

VOIP systems tricked into falsifying the callerID on incoming calls, and routing phny calls via internet to ask users for confidential information

DNS servers reporting false addresses for bank servers

And there are more. Clear ways for end users and banks to verify that their communications are not being subverted are definately required out on the Wild Wild Web.

Of course, there is only that much that the user can possibly be asked to enter, and the user can still be tricked into signing fraudulent transaction if the attacker modifies the web page and displays a “slightly” modified account number next to the instructions, or uses, for example, the same account number but a different sort code. Thus potentially MITM attack could still be executed although with much more difficulties.

As far as getting the cryptography right – we believe we have the best people in charge

A Point of Clarification: Authentify does provide the ability to repeat transaction details back to the user via telephone to thwart man-in-the-middle (MITM) attacks. If the user hears transaction details differing from the expected amounts, he or she can easily cancel the transaction before fraud occurs. Several current customers choose to employ this option to solve MITM.

For the demos on the Authentify web site, we feature a simplified version that best addresses our various customer sectors and their wide variety of authentication challenges.