First Direct & Card Readers

Archi_Bald

Hominu wrote: »

Your missing something out. Something big.

Banks don't care about their customers. They only care about making money and milking the maximum amount out of each and every customer.

I am not missing anything - I absolutely agree with you, banks don't care about their customers, and I have never said otherwise.

Hominu wrote: »

They are introducing this key for their own benefit, not ours. They are disguising it in the fact of making "us" safer, whereby really all they are doing really is providing another fence to hide behind should fraud happen. They don't care how secure it is. They are only looking for deniability.

You are, effectively, just confirming the point I was trying to make. I never once said that this hideous HSBC security-thingy was of any benefit to the customer. What I said is that if it was not secure, HSBC would by now have phased it out, and not inflict it onto their FD customers, too.

jamesd

grumbler wrote: »

in other banks card readers generate the confirmation code for important transactions based on the amount and the destination account - thus making impossible for the malicious software to substitute both/either. AFAIK, this is the main purpose of card readers.

Yes. That's the sort of system NatWest uses.

FD seems to have chosen the cheapest possible hardware solution, which seems to be a simple sequence of numbers generator with nothing to link the sequence to a particular transaction amount or destination account. A number generator that doesn't read cards could be used similarly, generating a value that depends on a value entered as a prompt but I don't think from the description that the FD one does this.

gwapenut wrote: »

A man in the middle would never know what the next number was, even if he had sight of the prevoius number, because it would be different for each and every customer.

That's hardly a tough problem to solve. Just ask the customer for the number and use that to log in as part of a standard fake site setup. That can be foiled by linking the number to a particular transaction value and/or destination but this system seems not to do that.

jamesd

Hominu wrote: »

Or even better, if the customer has a mobile phone, either phone it or send a text when a new payment is setup and randomly for existing payments.

Notification and a deliberate delay before the first payment can be made would be one inexpensive way to increase security. That would be true even when a token is used, since the FD system seems not to prevent man in the middle attacks.

Hominu wrote: »

None of the above should be required to just login to your account. That should be quick and easy, requiring just a username and password and perhaps a few characters from another password, as it is now. I'd hate having to get out my card reader or "SecureKey" just to view a balance.

HSBC's system arrived after some fuss in Hong Kong about privacy breaches on the accounts of prominent people. So HSBC there went with a system that required a token even to log in.

roxy28

Reading this thread makes me nervous in thinking my money is about to become less safe with transactions etc.
I will have to keep an eye on this thread before making up my mind.

JohalaReewi

I had a mailer from FD about this in the post. Arrived yesterday.

gwapenut

roxy28 wrote: »

Reading this thread makes me nervous in thinking my money is about to become less safe with transactions etc.
I will have to keep an eye on this thread before making up my mind.

Are you serious? It's far less secure at the moment.

jamesd

roxy28 wrote: »

Reading this thread makes me nervous in thinking my money is about to become less safe with transactions etc.

It won't become less safe solely due to fraudulent transactions.

However, just as happened with card and PIN, your risk if a transaction is fraudulent will probably increase. This is because FD seems likely to claim that because Secure Key was used, it must have been you who carried out the transaction. This even though it seems clear that Secure Key due to its fundamental design does not prevent others from carrying out transactions as you after you have provided Secure Key details to log in.

These days the FOS recognises that use of card and PIN does not mean that it has to have been the cardholder, because many of the risks are well known, from cameras or shoulder surfing to get the PIN then steal the card through family members ending up both knowing the PIN through observation and having access to the card and on to compromised terminals that display one value but submit a transaction of different value.

This does not mean that Secure Key is entirely bad. For less serious attacks it appears useful and I think that it will reduce FD's risk from less severe threats. But it's the tougher cases that such systems can be designed to prevent and FD's technology choice seems not to address those, which to me seems very disappointing so late in the game.

Provided you can choose whether to use Secure Key or not after being provided with it, there is a potential benefit for FD because you can choose never to use Secure Key unless you plan to carry out an operation that will need it. This way even if subject to a man in the middle attack, most of your sessions won't be at risk from things like a new account being set up so that money can be fraudulently transferred to it. Only the ones where you use Secure Key.

But since you can carry out those transactions over the phone it seems unnecessary to use Secure Key and take that risk at all.

How FD addresses that login question will be significant. Will they advise customers to always use Secure Key, the approach that maximises the number of sessions at risk, or to use it only when required, the one that minimises that risk?

What I will probably do as an initial filter is to see whether FD recognises the limitations of the technology in Q&A with customers or not. If they are not willing to recognise and admit the risk then that makes it significantly more risky for customers and I'll probably choose not to use Secure Key at all, because that would make it a tool to protect FD in part by increasing my own risk. We should be able together to reduce FD's fraud risk with Secure Key but that does require FD not making excessive claims about the capability of the technology which could transfer fraud risk to customers.

roxy28

jamesd wrote: »

It won't become less safe solely due to fraudulent transactions.

However, just as happened with card and PIN, your risk if a transaction is fraudulent will probably increase. This is because FD seems likely to claim that because Secure Key was used, it must have been you who carried out the transaction. This even though it seems clear that Secure Key due to its fundamental design does not prevent others from carrying out transactions as you after you have provided Secure Key details to log in.

These days the FOS recognises that use of card and PIN does not mean that it has to have been the cardholder, because many of the risks are well known, from cameras or shoulder surfing to get the PIN then steal the card through family members ending up both knowing the PIN through observation and having access to the card and on to compromised terminals that display one value but submit a transaction of different value.

This does not mean that Secure Key is entirely bad. For less serious attacks it appears useful and I think that it will reduce FD's risk from less severe threats. But it's the tougher cases that such systems can be designed to prevent and FD's technology choice seems not to address those, which to me seems very disappointing so late in the game.

Provided you can choose whether to use Secure Key or not after being provided with it, there is a potential benefit for FD because you can choose never to use Secure Key unless you plan to carry out an operation that will need it. This way even if subject to a man in the middle attack, most of your sessions won't be at risk from things like a new account being set up so that money can be fraudulently transferred to it. Only the ones where you use Secure Key.

But since you can carry out those transactions over the phone it seems unnecessary to use Secure Key and take that risk at all.

How FD addresses that login question will be significant. Will they advise customers to always use Secure Key, the approach that maximises the number of sessions at risk, or to use it only when required, the one that minimises that risk?

What I will probably do as an initial filter is to see whether FD recognises the limitations of the technology in Q&A with customers or not. If they are not willing to recognise and admit the risk then that makes it significantly more risky for customers and I'll probably choose not to use Secure Key at all, because that would make it a tool to protect FD in part by increasing my own risk. We should be able together to reduce FD's fraud risk with Secure Key but that does require FD not making excessive claims about the capability of the technology which could transfer fraud risk to customers.

Is there any chance the secure key could be a upgrade on other types of secure key?
Is the Q&A with customers on the FD website?

Hominu

roxy28 wrote: »

Is there any chance the secure key could be a upgrade on other types of secure key?
Is the Q&A with customers on the FD website?

Did you really have to quote 8 paragraphs to add 2 lines of text?

jamesd

The FD key can't really be an upgrade on any type of secure key. It seems to be one of the cheapest and least capable options around, less capable than other systems.

Q&A means customers asking them and them giving correct answers that are not misleading or concealing of the limitations of their technology and choices about how to recommend use of the technology (all sessions or only those doing the higher risk activities, say). So ask and see if you get answers that are consistent with the discussion of the limitations here. If you do, that's a relatively good sign. If they try to conceal the limitations or do silly things like claiming that using Secure Key at every login is more secure than only when required when the converse is true, that'd be a bad one.

All security systems have limitations. One of the keys to getting maximum benefit from even the more limited ones like Secure Key is telling people how to use them in ways that get the risks as low as possible given those limitations.