First Direct & Card Readers

lazer

penrhyn wrote: »

Thats terrible, I did not realise that people still bought Blackberries.:D

I had a basic nokia until recently - the advantage of the blackberry was that we could use bbm voice calls to phone family abroad for free (although afaik blackberry messenger is now available on android phones too) I don't really use the apps etc - I have a computer for the internet.

PS - The blackberry server is more secure than the other.

OverRated

It makes things slightly awkward i'll agree but when your Twitter account can have two stage authentication shouldn't your online bank account?

FD seem to have taken a reasonable middle ground. I have an iPhone so will opt for the digital secure token - I am actually moving away from it once it dies to my free work blackberry so it is great FD will let you change your mind.

99% of my online banking is checking the balance and making payments to regular accounts - I wont need to use the secure token for this. For the rare time I do need the token it is a small extra step that is a small pain - especially if you opt for the physical token and put it somewhere safe so you lose it!

jamesd

OverRated, I'll probably choose the more secure option of no (in)Secure Key.

It seems that all an attacker needs to do is present someone with a login screen, ask for and get the generated key, then use that to log in to the real system in near real time and carry out whatever fraud they want to carry out. After such an attack it seems quite likely that it would be hard to persuade FD that it was not you who carried out the fraudulent transactions.

Unless of course FD has something more secure than the descriptions available so far suggest. Those seem to imply the cheapest possible hardware or free software and a not very good system compared even to things like the one at NatWest that's been around for years now.

I do hope that FD allow the method you've described: no Secure key for most logins, only using it when you need to do them. Even better if they educate customers to do it that way, so customers will know that they can reduce the fraud risk by using Secure Key only when required.

roxy28

I am new to all this secure key login.
If you login the normal way ie password etc, then use the secure key to carry out a new payment does the login screen change?.

Hominu

gwapenut wrote: »

Not at all, a unique starting number is generated, and it changes every minute or so. The number it changes to is predictable, based on the previous value of the number.

So pretty easy to emulate then by someone who wants to access your account, and so therefore more useless than asking for characters from a memorable word.

What they should support instead is the well known card reader. Upon making a new payment, or randomly for existing payments, you have to enter the account number and amount into the card reader which generates a long number. If the number doesn't match the payee or amount the transaction is declined, so attacks such as MitB are fooled, as no data can be changed, and of course it requires your physical card rather than a piece of software that can be reverse engineered.

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 (which the user can opt out of for a few times, just in case they don't have their phone with them).

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.

grumbler

jamesd wrote: »

Nice buzzword use. Now tell me how requiring the authentication every time will not condition users to supply the authentication to every man in the middle variation going, whether it's a site that relays the authentication in near real time and mimics the real site but does additional transactions or OS or browser hosted variations. Training end users to always provide credentials that are really only needed for higher risk operations is poor practice because it means that every session is vulnerable to compromise, not just the ones where the user is doing something that requires more security. That's why many banks allow logging in an minor operations without the card reader and require it only for new transfers and other important transactions.

This is something that the NatWest variation does better, only requiring extra credentials when they are actually needed, so alerting the end user if they are requested unexpectedly.

There is, hopefully, always the option for end users to not use the token-based authentication for most transactions, so they can compromise their sessions only when required.

I am no expert and I don't know about FD, but 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.

gwapenut

Hominu wrote: »

So pretty easy to emulate then by someone who wants to access your account

No, you're wrong. The next number in the sequence depends on both the previous number, and a secret 80-bit key known only to the app on your phone and the bank server.

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.

Gromitt

gwapenut wrote: »

No, you're wrong. The next number in the sequence depends on both the previous number, and a secret 80-bit key known only to the app on your phone and the bank server.

I don't have a HSBC account so maybe this has already been thought of, but...

If it's just the case of being based on a time dependant sequence, whats to stop a man in the browser from asking you for that number twice and then communicating with the bank using those numbers.

I assume they are valid for at least a few minutes each, so you login to a rogue site, it asks for your number, then says you entered it wrong and asks for it again, once you've done that it then goes away in the background and logs into your account using the first number and then sets up a new payee and makes a payment using the second number. It then displays a page saying that internet banking is currently not available, giving them long enough time to transfer the funds elsewhere.

Given that people follow instructions in emails, how hard would it be to get someone to generate two seperate codes using there secure key?

Archi_Bald

Not that I like the HSBC security-thingy for a nanosecond (I detest it, actually) - but what makes people think it isn't secure? If it was, HSBC would by now have long phased it out, as opposed to inflict that hideous device onto their FD customers, too. No extent of inconvenience and hideousness for the account holders does make the device insecure, though.

Hominu

Archi_Bald wrote: »

Not that I like the HSBC security-thingy for a nanosecond (I detest it, actually) - but what makes people think it isn't secure? If it was, HSBC would by now have long phased it out

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.

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.