Where magic lives

Thursday, August 10, 2006

Analysis of HSBC Vulnerability

It is all over the news this morning about a "security flaw" in HSBC online banking.

Being an HSBC account holder myself (not that I actually use the bank; they offer pathetic interest rates) I was encouraged to investigate this further. I was put at ease the moment I saw that each article was hinting at the researchers having made an assumption that every target has been infected with a keylogger. A bit of an unreasonable assumption if you ask me, and I think at this point it stops being "news" however the vulnerability is quite interesting...

When you logon to HSBC banking you are asked for your date of birth and for three digits from your security number. The three digits you are asked for are randomly selected by HSBC but the digits requested only seem to change after a successful login. Also the instructions that tell you which digits to enter are sent over HTTPS and we will assume are invisible to the attacker. Now for the important part: the digits are always requested in the order they appear in the security number. For example you might be asked for digits 1, 2 and 3 in that order, but you would never be asked for digits 3, 2 and 1 in that order. This leads to the vulnerability...

Let us use a random example, assume that an HSBC customer uses the security number 4921576876, we have a keylogger running on his machine and have now watched him login to HSBC 22 times seeing the following partial security codes: 416, 458, 496, 286, 925, 976, 487, 476, 157, 987, 476, 576, 217, 915, 178, 976, 491, 476, 428, 915, 917 and 176.

From the data above we can estimate how often we expect each digit to appear in the users security code. We would expect to see each digit in the security code a total of (|dataset| x |partialcode|) / |availabledigits| = (22 x 3) / 10 = 6.6 times. For example we saw the number 6 ten times in total, so would expect it to appear in the security code 10 / 6.6 = 2 (0 d.p.) times. Using this strategy we can deduce the following frequencies for each digit in the security code: 0 x 0, 1 x 1, 1 x 2, 0 x 3, 1 x 4, 1 x 5, 2 x 6, 2 x 7, 1 x 8, 1 x 9. This statistical analysis has introduced some uncertainty and we may need to come back to these distributions if the procedure below leads to errors.

Now we can start to piece together the original code. Let's start with the digits that only appear once, the code contains a single 1: 1. It contains a single 2 and the partial 217 tells us that the 2 comes before the 1: 21. Similarly there is a single 4 and we know from 416 that it is before the 1 and from 428 that it is before the 2: 421. There is a single 5 and the same method tells us that it comes after the 1: 4215. Similarly we can deduce the positions of the single 8 and 9: 492158. Now we need to deal with the sixes and sevens, some uncertainty is introduced here but the state space stays manageably small. There is definitely a 7 after the last 8 (because of 487): 4921587. The other 7 comes either immediately before or immediately after the 5 but we cannot tell which. The first 6 could appear anywhere after the 9 (from 496), and the second six could appear anywhere after the 1 (from 416) but if you chart all the possible locations they can be seen to be statistically more likely to appear after the 57/75 so let us assume this.

Based on the above (which assumes our frequency distribution to be correct) we claim that the code begins with 4921 is then followed by 57 or 75 and is then followed by 6876, 8766, 8676, 6687, 8667 or 6867 (all of the possible arrangements of the sixes at the end of the code). This gives us only 12 possible codes and indeed does contain the correct code: 4921576876.

I have chose to publish a worked example rather than general code because it is easier and wont get me accused of publishing working exploit code but it can be seen how the above procedure can be generalised. It is at this point where you could debate the subject as well as not being newsworthy, not being academic research but just simple maths. We'll see where their research gets published "later in the year"!



  • I'd guessed this was the vulnerability. It also affects First Direct (part of HSBC). Now I don't know how HSBC works, but FD only ever asks for the letters from the first seven letters of your password and the last letter, so for a 10 letter password, letters 8 and 9 will never be asked for. Why don't they ask for them in a random order? Simple solution.

    By Anonymous Anonymous, At 1:54 pm  

  • The first thing to remember is that this is a replacement for a canned responce. Previously it asked, what is your number and the reply was X. A keylogger would pick up on that immediately. Now it takes them multiple log in attempts to get the data point necessary to get ready to attack. This is a step ahead already.

    As far as I am concerned, this isn't a vulnerability at all, rather an implementation of the partial ordered list being actualized. I find it alarming that it is being publicized more than the fact that there are systems out there that don't deploy any such scheme to prevent keylogging.

    #security irc.freenode.net

    By Anonymous Anonymous, At 4:52 pm  

  • I'm no hacker but i do believe that keyloggers intercept the keyboard interrupt at each keystroke. My hsbc login uses a virtual keyboard requiring mouse clicks, I can't figure out how keystrokes from a virtual keyboard can be intercepted by a keylogger.

    -Nigerian guy.

    By Anonymous Anonymous, At 4:55 pm  

  • Another simple solution would be to have the user select their numbers from drop-downs, like how LloydsTSB do it. I agree, the presence of a keylogger makes one wonder why this is front-page Guardian news. I bank with Halifax and they don't ask for any random digits, it's just a rotation of five secret questions. So really they are more vulnerable to attack than HSBC (if I had a keylogger installed).

    By Anonymous Anonymous, At 5:00 pm  

  • I can't figure out how keystrokes from a virtual keyboard can be intercepted by a keylogger

    There are keyloggers which can track mice. You can figure out exactly where the person clicked by the relative positions of all the characters with no regard to monitor resolution.

    By Blogger ReallyEvilCanine, At 5:09 pm  

  • to 'Nigerian Guy' - on screen virtual keyboards are still vulnerable to a logger which grabs a bitmap of the region around the mouse cursor every time you click - I'm sure I read somewhere that this technique is already in active use.

    By Anonymous Anonymous, At 5:13 pm  

  • I am receiving 5% on my HSBC online savings account in the US ($1 minimum deposit).
    Do you qualify for a similar account ?

    By Anonymous Anonymous, At 5:19 pm  

  • I also use HSBC online, and I enter a username and password to log on. I don't use my DOB or SSN. What service are you logging into? From where? I use Personal Internet Banking, from the United States, just for comparison's sake.

    Also, have you looked into the Online Savings account? 5.1% isn't half bad, especially when you look at the .25% I was getting from my other savings account there.

    By Anonymous Anonymous, At 5:20 pm  

  • I can't get anywhere near 5% on an instant access account with HSBC in the UK, I can with smile.co.uk though (their login procedure is less keylogger-proof than HSBC btw). HSBC do give me an interest free, no fees overdraft of almost £2000 to invest wherever I want and a free railcard though so I shouldn't complain too much :)

    By Blogger David Nicholson, At 5:21 pm  

  • I'm not convinced that this can be the whole story. The articles are reporting a definite compromise with at most nine attempts -- though whether this is nine logged inputs, or nine login attempts for the fraudster isn't clear.

    By Anonymous Anonymous, At 5:32 pm  

  • In regards to your first statement about the horrible interest rate that HSBC provides you should look at their online savings account http://www.HSBCDirect.com. It pays 5.15% with no minimums and it's easy to transfer to your normal checking account.


    By Anonymous Anonymous, At 5:33 pm  

  • If an attacker can install a keylogger and is specifically looking for HSBC logins, I'd think it's overwhelmingly likely that they'd sniff the requested number positions too.

    Therefore as interesting as the statistical analysis is, it's rather unnecessary.

    And of course knowing the requested number positions reduces the number of attempts required to one, assuming the user has at some stage entered every digit in their number.

    By Anonymous Anonymous, At 5:38 pm  

  • to everyone posting about interest rates -ie, Jeremy et al - you should know the HSBC UK and HSBC in the US pretty much function as independent institutions. you can't expect them to be any more similar than HSBC and Barclays or HSBC and BoA. they're not the same bank in any practical sense, just a vague business sense. HSBC Direct's online account that Jeremy linked to is only for US residents, so David's stuck with crummy HSBC interest rates. Sorry David.

    By Anonymous Anonymous, At 6:00 pm  

  • What about cases where you use a password wallet to log in to a canned response site? Isn't it safer to have a canned response in this case, provided that the browser protects the memory location of the unencypted response? To a keylogger, it would just look like a click on the prompt and a ctrl-enter. Of course, any capable trojan horse could potentially allow the attacker access to the same wallet. When you assume the client has an intruder with OS-privileged access, can there be any really reliable protection?

    By Anonymous Anonymous, At 6:11 pm  

  • It's far easier than any of you think. You can do it in 3 tries without a keylogger.

    1) Ring the punter up via Skype, say "It's HSBC. We have an issue with your account. Can we first take you through security please?"
    2) "What is the 3rd digit in your pass code please? The 4th? The 7th?"
    3) "Thankyou. You have cleared security"
    4) Inane question/advice.
    5) "We will get back to you with an update on progressing our investigation into this issue".

    6) Do 1-5 twice more, asking for different digits, after suitable delays.

    7) You now have all digits. Ring up HSBC ask for balance, transfer funds.

    Ah, but, you say, no bank would be so silly as to train their customers to respond to requests such as this!

    That's where you'd be wrong. Banks do indeed call their customers using this process to authenticate them - the ignorant fools!

    By Blogger Crosbie Fitch, At 6:14 pm  

  • If you already have a keylogger installed on the system, just wait for the user to type in his password and record it! Why do you have to go through all that mathematical mumbo jumbo - the keylogger should be enough!

    By Anonymous Anonymous, At 6:45 pm  

  • Sorry, I'm wrong, you can do it in a single man-in-middle try.

    Two con men A & B acoustically isolated from each other, but able to communicate via other/visual means etc.

    1) 'A' Rings up punter
    2) 'A' performs introduction asking to take punter 'through security'.
    3) 'B' Simultaneously rings up HSBC
    4) HSBC asks 'B' for 2nd digit.
    5) 'A' asks punter for 2nd digit.
    6) HSBC asks 'B' for 5th digit
    7) 'A' asks punter for 5th digit.
    8) HSBC asks 'B' for 7th digit.
    9) 'A' asks punter for 7th digit.
    10) HSBC says "How can I help you today?"
    11) 'A' placates punter and ends call.
    12) 'B' drains punter's account of funds.

    Must have done this one in the movies already eh?

    By Blogger Crosbie Fitch, At 7:03 pm  

  • What am I saying?
    It's easier still!

    One con man at web terminal with Skype headset.

    1) Rings up punter
    2) Performs introduction asking to take punter 'through security'.
    3) Simultaneously logs in to punters HSBC online banking account.
    4) HSBC web site asks for 2nd digit.
    5) Conman asks punter for 2nd digit.
    6) Web site asks for 5th digit
    7) Conman asks punter for 5th digit.
    8) Web site asks for 7th digit.
    9) Conman asks punter for 7th digit.
    10) Web site logged in!
    11) Conman congratulates punter on passing through security, winds punter down, and ends call.
    12) Conman drains punter's account of funds.

    Fortunately, I suspect HSBC do not permit draining of funds via their online banking facility. Do they???

    By Blogger Crosbie Fitch, At 7:12 pm  

  • Sorry Crosbie, been there. MBNA phoned me up and said they had to have my date of birth before they could talk to me. I pointed out that I had no way to know they were indeed MBNA. We went round in circles for quite some time before I eventually agreed to trade half my date of birth for them telling me the other half. Idiots.

    Meanwhile, so far as HSBC are concerned, there isn't anything stopping you entering the requested digits in random order: so long as the key logger isn't catching the mouse clicks, you just have to jump the cursor round between digits.

    By Anonymous Anonymous, At 7:16 pm  

  • Duncan, the approach I use is to ask the caller for the number I should ring them back on.

    I then check the number is correct, and then call.

    The banks should NEVER cold-call their customers and ask for any personal info, let alone PIN digits.

    As I keep trying to tell people, authentication is a two way street. It's not enough for the service to authenticate the client, the client must also authenticate the service.

    A lesson for all services wishing to reduce phishing exploits: STOP TEACHING YOUR CUSTOMERS THAT IT'S OK TO TALK TO STRANGERS!

    By Blogger Crosbie Fitch, At 7:32 pm  

  • Being a specialist in the banking and online security industry, I've got to say this is more evidence of the press pushing drama then actual threat. The flaw is not HSBC, its in the anti-virus and security software. If you have a key logger on your computer, most likely the person(s) receiving the output can get into your accounts. There are a few solutions capable of stopping such threats, and one of them is what I do for a living.

    If you really want to take a good look at a serious threat to the online banking industries, take a look at this. The "man-in-the-middle" attack against Citibank and one time passwords is putting a serious chill down the spines of all online bank administrators and security engineers.

    By Blogger Casey S. Potenzone, At 8:43 pm  

  • I agree with a few here, and I don't understand how this is considered a flaw.

    Most other banks, financial institutions, government departments etc. use a standard userid (and/or simple easily obtainable details, such as postcode, dob, mom's maiden name) and password combination .. The password is as has been pointed out, a canned response, the same every time .. this takes 1 attempt using a keylogger. OK, so Cardiff university has arrived at the decision that HSBC's current scheme is slightly flawed as it is "tappable", where as it wa previously viewed as not being so, but it is still at minimum, a factor of 9 stronger than comparable authentication schemes. While HSBC now requires only to randomize the ordering of the requested values to now make this infinitely less "tappable", where does that leave all the others ... ??

    The press has now made everybody (well, those that won't look deeper than the story) wary about a security system that was, and still is, stronger than most of the others ..

    By Blogger Dave, At 9:14 pm  

  • I work in security testing and do not think this is an issue. If an attacker has the ability to install a keylogger, then they can do what they want and its game over regardless.

    By Anonymous Anonymous, At 9:20 pm  

  • Crosbie, she did suggest she could give me her supervisor's number where I could call them back afterwards, but I still wouldn't give them my date of birth before calling that number. And all this was because they wanted to sell me payment protection insurance.

    I fully agree with you that both sides need authentication.

    By Anonymous Anonymous, At 9:36 pm  

  • Mark Woan: "If an attacker has the ability to install a keylogger, then they can do what they want and its game over regardless."

    I'm not sure I agree. I'd definitely choose to use a bank with a good anti-keylogging password scheme. A strong scheme makes it much more difficult for an attacker to operate my account, and, even if they're persistent, gives me a lot longer to realise my system is compromised.

    Also, when NTL lets me down and takes a week to come and fix the fault they've caused to my broadband, or I'm away from home, I want to be able to check my account without having to worry about how "clean" the internet cafe I'm in is.

    By Blogger SteelyGlint, At 10:50 pm  

  • Quote: "If you already have a keylogger installed on the system, just wait for the user to type in his password and record it! Why do you have to go through all that mathematical mumbo jumbo - the keylogger should be enough!"

    Do you know how to read? HSBC never asks the user for the ENTIRE password all at once. It asks for randomly selected digits every time you log in.

    By Anonymous Anonymous, At 10:52 pm  

  • Many years ago I used to pretend to be someone silly when tinging people up.

    I rand up a friend and his girlfriend answered so I pretended to be from the bank we all used on our university campus. To my surprise she did proceed to give me the long number from accross the middle of her credit card before I told her who it was and that I was winding her up. (I also informed her why this was a bad idea)

    By Anonymous Anonymous, At 11:07 pm  

  • As I work for HSBC in the UK, I would be worried if we started asking your security code digits to identify you when we ring you. We don't even know what your security number is. We have numerous other questions that we can ask to establish identity sufficiently and also have a fail safe system should customers prefer to call us back.
    p.s HSBC UK customers can benefit from a similar product to HSBC USA customers via the Online Saver Account which pays 4.75% (sorry to add the sales pitch but I wouldn't benefit if anybody did take uo on this)

    By Anonymous Anonymous, At 11:17 pm  

  • David, Interesting analysis, but I suspect you made the numbers up rather than generated them randomly, as there are some low probability aspects of the 22 codes you have generated.

    First, the chance of 7 (the 6th character in your example) never appearing in the first position over 22 attempts is less than 15%. Not strictly statistically significant I grant you. Second, though, the chance of 6 (the 7th character in your example) never appearing in the middle position is less than 3%, which is a bit more significant.

    I mention this because there's a bit more you can do with the data. For example, you might try the 5 before the 7 first, because 5 appears once in the first position, whereas the 7 doesn't (though the frequency distribution for the middle and last positions might put you off). You would also very likely try "76" for the last two characters first as 6 appears in the last position 10 times, 7 appears there 5 times and 8 (and 5) only 3 times. If you made these two choices in your example you'd get there in 2 attempts at the most, which is important, as any sensible system would lock you out after (say) 3 failures, at least for a period.

    I suspect you'd find it easier to crack the security number given 22 real life (i.e. random) codes. But then again, I expect it would have to be personal for an attacker to wait long enough to collect 22 codes from one user, rather than find an easier system to attack.

    By the way, although this is all good fun, it may not be the problem Cardiff have identified. The site: http://www.bit-tech.net/news/2006/08/10/HSBC_online_banking_seriously_flawed/ notes that: "According to the researchers, it is possible to get into any online account in nine tries or less (they figure five for most accounts) due to a flaw in the web scripting."
    Perhaps they can somehow glean some information about why a logon attempt has failed and only need the keylogger to get the other confidential data a user has to enter to access their account.

    Finally, Anonymous wrote: "If an attacker can install a keylogger and is specifically looking for HSBC logins, I'd think it's overwhelmingly likely that they'd sniff the requested number positions too." Is this possible? Could some keylogging virus get at the information on my screen directly, without compromising my browser code (I understand this would be necessary to get round the HTTPS)?

    By Blogger SteelyGlint, At 11:54 pm  

  • If an attacker can install a keystroke logger, can we assume that the attacker can install any arbitrary piece of software?

    How about a browser plugin that waits for you to authenticate to any site, then captures the Session ID and sends it off to a third party site (a server under the attacker's control). Then the attacker could jump into the victim's account by replaying the session identifier.

    Sure, the attacker would have to be fast about it, but if you have a couple thousand computers infected you would pretty much have a valid identifier at any moment you wanted one... Alternately, the attacker could have a script that catches the Session ID and uses it to log into the site and try to keep the victim's session alive through periodic requests, or which authenticates and tries to change the password (which require significantly more code and would require the web site to have a feature that permitted that action).

    How about a different piece of malware? Wait until the user authenticates and then send a request (using the current session) to add an online bill pay entry?

    I agree with the earlier comment that if an attacker can install a keystroke logger, its game over. There are a lot of really nasty things you can do that don't depend on keystroke logging.

    For anyone who enjoys reverse engineering authentication systems, you should also check out ING Direct's mechanism and BofA's "SiteKey" system.


    By Anonymous Anonymous, At 2:22 am  

  • In Hong Kong, HSBC use Vasco Digipass security token more than a year now, the keylogger still able to capture the code but it's only valid for 15 seconds, so Maths can't help in this situation. I thought HSBC had used that in UK too but obviously that is not the case.

    The main problem is if your machine has a keylogger installed by someone else, then you cannot trust your machine anymore.

    By Anonymous Anonymous, At 4:10 am  

  • Seems HSBC internet banking site is entirely differant here in Australia.

    For starters, you need to enter your 10digit account number, and a password. Yes - a key logger can grab these. Then however much like it seems the overseas ones do, you have a secureID type of device and when you push the button it generates a random number which you have to enter in full.

    You need to do this every time you attempt to make a transaction, transfers, scheduled bill payment, etc.

    Now, I am 'assuming' that this device is synced to some clock and the number will never be the same. Maybe I can install a keylogger on my mate's PC and using my dongle, log into his HSBC account. I doubt it. The dongles are registed to your account, so much like a secureID token I'd guess neither one is the same.

    Took a while for HSBC to get here, seems they ironed out "the bugs" before they did!

    By Anonymous Anonymous, At 4:52 am  

  • In relation to The MITM attacks, this is the reason why barclays bank have different online banking and telephone banking codes, just to reduce the risk of one MITM scenarios.

    At the end of the day we all know that the haxors are always going to be ahead of the security guys. So in my opinion, the only thing that can be done is what the banks already do quite well at the moment... Manage and reduce the risks!

    By Anonymous Anonymous, At 11:19 am  

  • As another HSBC account holder I'm cheered to hear so many voices declaring this issue to be more smoke than fire. Sounds like prof Jones at Cardiff needs a slap on the wrist for being a bit hysterical. I note that in this morning's Guardian she is not saying "scandalous" anymore, and admitting that other banks have similar flaws.

    Now, am I right in thinking that since this is a keylogger based exploit, logging in from different terminals regularly ought to make it even more unlikely that anyone could crack my account?

    By Blogger Margaret Street, At 11:31 am  

  • If the same three numbers are requested by the bank untill there's a correct login (which I believe is the case), then there's no need to sniff them from the client computer, or use any statistical guessing.

    The attacker merely gets the customer number on the first attempt, then uses that to find out which digits will be requested next, and then waits for the customer to enter them. Rince and repeat. Within eight more logins the attacker will either have all the numbers, or be presented with a set of numbers he already knows.

    By Anonymous Anonymous, At 11:37 am  

  • Well the article seems well over hyped. As some pointed out already once you can run malicious code on a machine you own it. There are already banking Trojans in the wild which hook into your browser and intercept all traffic. This is done before information gets SSL encrypted, and after you use any virtual keyboards or alike. So no matter how you enter it it is always possible to get the information before it is sent.

    Next are the session hijacking trojans, as EH pointed out, a Trojan does not need to know the password. It can simply wait till the user successfully logged in and then submit transactions from within this session (Done by Goldun Trojan). This works as well if you use OneTimePassword tokens, CAPTCHAs or Sitekey images. Taking it one step further, some banks require each transaction to be authenticated with a number. This can be defeated by a Trojan by simply swaping transaction details forth and back and let the user authenticate the spoofed transaction.

    Therefore if you start from a compromised system the only secure way would be external transaction signing.(not eq transaction authentication)

    By Anonymous Anonymous, At 11:49 am  

  • On my home Linux machine I'm quite happy to enter the code as HSBC expect, but on the rare occaisions I'd log in from an untrusted machine at work I'll mix entering the codes with entering the date of birth and other random typing. The keylogger would then need knowledge of where the keys are going. I have used HSBC over an SSH connection running Lynx on my home machine before!

    By Anonymous Anonymous, At 12:52 pm  

  • It seems to me that the hacker will have your login id and date of birth after your first login attempt.
    As the random digits asked for don't change until a successful logon, the hacker can immediately start a new logon (while you are securely logged in). This tells the hacker which digits of your security number will be entered next time. So the next time you log in, they know 3 of your digits (and where they occur).
    This process can be repeated until they know all your digits, or until the digits requested are ones known to the hacker, at which point the account is compromised.

    No stats required!

    But of course, this is all predicated on the hacker having an undetected keylogger installed on the victims PC.

    A simple fix for this would be for the login process to randomise the order of the 3 required digits, even if the digits themselves do not change. (Although with this approach, the hacker would still be able to deduce your security number after sufficient logins, using some fairly simple analysis of the login pages they saw compared to what you typed in).

    By Anonymous Anonymous, At 2:38 pm  

  • this article is obviously biased against HSBC. if keylogging is the concern then all other banks' internet banking systems are also exposed to the same vulnerability. in fact the HSBC mechanism can be seen as less vulnerable then those using a simple ID and password for 2 reasons.

    first of all with the other systems the entire credential can be captured in just one attempt, but for HSBC, only part of the password is captured and one can only use that piece of information to logon on when the system requests for the same character position. secondly aside from a keylogging virus, the potential hacker would also need a screen logger program to know where each character belongs to which position.

    i don't know about everyone else but based on that if i were a hacker i would have picked someone else that HSBC...

    By Anonymous Anonymous, At 7:27 pm  

  • Session hijacking of most bank's online banking site's is not trivial as the session cookie is transmitted by SSL. If they weren't, then why bother installing keyloggers or trojans at client computers, you'd be better off writing a network sniffer, or similar for routers and switches, that just captures session id cookies as they fly past. This could be done easily for web-sites that don't use SSL for the entire session though. For unsecure session hijacking, unsecured wireless routers are where I see big problems .. these can be just as easily hijacked as computers, but won't have anti-virus or malware software installed .. ever! And believe me there are plenty of unsecured ones out there ..

    By Blogger Dave, At 10:53 am  

  • I'm not convinced. I just cannot see how the HSBC system being more vulnerable than the rest. The only thing that was proven was plausibility.

    By Anonymous Anonymous, At 6:38 pm  

  • Your analysis is mistaken: as one of the other commenters said, the key flaw is that they ask for the same three digits after an unsuccessful login. This effectively permits a MITM attack. The obvious solution (and I can't imagine why they don't do it) is to ask for a random three digits every time, regardless of login history.

    By Anonymous Anonymous, At 10:30 am  

  • "Your analysis is mistaken: as one of the other commenters said, the key flaw is that they ask for the same three digits after an unsuccessful login. This effectively permits a MITM attack. The obvious solution (and I can't imagine why they don't do it) is to ask for a random three digits every time, regardless of login history."

    There's a valid reason why they don't ask for random 3 digits every time regardless of logon history. It is to avoid a hacker who somehow obtained any 3 digits of the password to keep refreshing the page which the system will eventually ask for the same 3 digits that he has. Therefore, this is not a flaw.

    By Anonymous Anonymous, At 4:28 pm  

  • Good bit o' math.

    'course the real dummy thing is that if you have installed keylogger, you might as well just replace/shim the DLL doing the TLS encoding with a logging version.

    Bzzzzt. game over.

    By Anonymous Anonymous, At 5:34 pm  

  • SteelyGlint:
    "Also, when NTL lets me down and takes a week to come and fix the fault they've caused to my broadband, or I'm away from home, I want to be able to check my account without having to worry about how "clean" the internet cafe I'm in is."

    Comedy, please come to my "clean" internet cafe! You must be mad if you use an internet cafe for online banking. Muppet

    By Anonymous Anonymous, At 9:56 am  

  • A few points:

    The security passnumber is not forced to be random - for example, you might choose 3141592653, to help you remember it.

    I agree that it would be more secure if the three digits you were asked for were asked for in a random order

    A suggestion for those people that are cold called and challenged to provide various bits of personal information as a security check is to get some of them wrong. If the person at the other end of the phone tells you that unfortunately you have failed their checks, then you can be fairly confident that they already know about you and are probably legit - apologise and ask to have another go. If they don't say that you've failed validation, then be suspicious - but at least they haven't got all your personal details.

    By Anonymous Anonymous, At 1:45 pm  

  • In reply to Steely Glint, yes, there are Trojans out there that will screen shoot every mouse click, HTTPS does not prevent this.

    If you go to a cyber cafe with the random character method used by the other banks the fraudster only needs the 3 characters of the pin typed in, as they can keep returning to the login page until they are asked for the characters they know. Remember you are only locked out if you actually fail the login, they don't need to login to see which characters are requested.

    If you go to a cyber cafe with the HSBC online banking and input your 3 characters the fraudster can't use those characters to get into your account by continually inputting the user ID, as HSBC will just keep requesting the same characters until you login, thus leaving the fraudster with a useless partial authentication.

    This is not rocket science, unfortunately the phishers do have rocket science and are starting to deploy technology that can cut through 2 factor authentication.
    Yes, online banking is risky, but so is walking down the street with money in your pocket. The difference is that the UK banks, to date, are honouring online customer losses.

    By Anonymous Anonymous, At 10:52 am  

Post a comment

Subscribe to Post Comments [Atom]

<< Home