HSBC has this really odd system where they only ask for the (e.g.) 1st, 6th, and 7th characters of your password. That implies that they store plaintext or something reversible...
Re brute forcing, some like firstdirect make you type a word as well and they probably block you after 3 fails so it would be quite hard to brute force. Tddirectinvesting only ask a 7 digit account number and 3 digits from the password so you could probably brute force coms of those with a botnet though they only let you transfer money to a pre nominated bank account so it would still be hard to nick people's money.
Actually it's very simple to achieve.
First, those digits will not be randomly placed among all the things you've typed, but they'd follow some specific patterns (the most obvious one being you typing all of part --due to autocomplete-- of the bank's url).
(Of course if you can run a keylogger you can also check what website is loaded on the browser and log that information alongside the keys too, but you don't even need to go that far).
So, we established that the attacker checking the keylogger logs can trivially tell - "now they're typing their banking password".
If they also knew the correct placement that would be handy, but they can do without it too. Just knowing those N characters are from your password (in any order) really improves the possibilities they need to search.
Even if it takes a year, either they are very dedicated to you as a special (large bank account) profile target, so they can wait, or they are logging tens of thousands, via some malware, so it's still worth it to wait.
Such attacks rely on large scales rather than being targeted.
If you target a specific account there are much better attacks out there to do if you target specific individuals or organizations.
Yes this isn't the best method and I've had and still have a lot of objections to it (it requires the password to be stored in a reversible encryption, but that is also sadly a regulatory requirement).
But I've tested it a 10 character password using their random characters random order request method took at the least 413 (that was the lowest in my case, I didn't run a full statistical analysis on it) login requests. This is because that asking for 1st 2nd and 3rd characters, and 2nd 1st and 3rd, and 3rd, 2nd and 1st etc. are all considered "different" authentication requests by the bank.
Your keylogger would have to be also able to read the page and know that the 1st box wants the 4th character and the 2nd box wants the 3rd and the 3rd want's the 7th. This isn't that trivial, and this doesn't scale for an attack that can target 10,000's of users over a short time period.
You need to understand that banks constantly change their web pages, they monitor for bank related malware and some of them even use additional protection like for example randomizing the names of the input fields and even the number of the fields to make effective keylogging with full browser compromise even harder.
You also are incorrect when assuming that if i know the 1st 3 characters of a password it somehow helps me it doesn't because you do not have an authentication mechanism to brute force against there isn't some login page that takes the full password, and 3 incorrect login attempt lock your user and require you to initiate a recovery by phone or by visiting a branch.
This system overall is pretty good at preventing direct attacks against the bank's own system, it's resilient to phishing, brute forcing is not an option, and a keylogger can be active for 1-2 years without effectively getting the password. Effective security isn't black and white, there are is a lot of grey areas that might seem asinine and many of them are but they do work when you have the proper mitigating controls.
But let's ignore all of what we've established so far and go back to your assertion you assert that this attack is effective against high value accounts / individuals. Well that's great, because from the point of view of the bank it says hey look we've put in a control that can effectively protect 99% of our users, let's see what can we do to protect the 1%. That's how you achieve good security, you don't pool everyone into the same group, accounts with an average balance of 5000$ do not have the same risk portfolio as accounts with an average balance of 1M$. Differential security and risk management is how you apply effective security on very large groups, you employ shared controls that cover the basics and add mitigating controls based on the individual risk portfolios for each sub group.
The scrambled on-screen keyboard / n-th character request only poorly "protects" against cases where the attacker has full root access to the customer's machine (how would it protect against phishing?), and in those cases the attacker is likely already capable of making all kinds of payments, even without access to the online banking account. If security is done properly, an attacker can't make direct use of a banking account anyways: creating a new transfer recipient should require phone confirmation by default.
All you'd have to do is iterate every potential answer into a bloom filter and store that. The math gets a little hairy around the 50 character mark as you'd have 117600 operations to do to construct the bloom filter, and it gets worse if you expect more characters.
Here's how you would construct it.
For every 3 choose n of the password, insert a value of those 3 characters ("abc") + delimit (":") + the positions (1,2,4), You can't just insert the characters because the index of characters is part of the answer.
all you'd need to do is store... a ~1MB bloom filter per client. Huh, that number was bigger than I thought it would be.
Well nevermind. Fun thought though.
If an attacker is running code on your system, you are already lost.
see http://willtracz.co.uk/shamir-secret-sharing-and-passwords
Above is on the page you're linking to.
[1] http://i.imgur.com/QCGPDWz.png [2] http://i.imgur.com/VdtGC4T.png
I really really dislike HSBCs online banking as a whole, the password system plus the constant “We encountered an error, please try again later” messages.
Still a lot easier to guess a portion of a password than a password, but it doesnt follow in my mind that it is definitely in plaintext.
However this is a memorable phrase (not password), similar to a security question. These are not generally hashed because customer service uses them to confirm authorization to reset a password.
The "password/memorable phrase" is only used as a secondary authentication measure and in order to initiate a token recovery procedure on the site.
P.S. I still use the physical OTP token, just got a new one last month it's a Vasco Digitpass 270 supports upto 8 digit pins and it locks out automatically after IIRC 5 attempts.
I don't recommend using a phone authenticator for the sole reason that losing a phone is annoying enough on it's own you don't want to lose your bank account access too :)
Edit: I realise you're probably referring to proprietary bank authenticator apps
They also have the most complicated 2fa I've seen. You get a pocket-calculator-like device where you need to insert your card (chip and pin type), then you enter your personal code, and then you do a challenge-response thing where you enter a code generated from the website into the device, and it responds with a number you have to type into the website.
They also have this anti-paste function that was triggered by me typing too fast.
Such a thing is rather common in The Netherlands, though it's often not a second factor but just the way you log in to online banking. It avoids having you remember yet another password, instead you just use the same card and PIN you need "offline".
Side note: At the end of 2014 Rabobank (one of the banks with such a system) replaced those devices (which they called "random readers") with "Rabo scanners", which have a built-in camera to automatically read an image from the website instead of having you manually enter a code.
That's still 2FA though, isn't it? You're proving to the server that you have the card and the pin.
You insert card and enter PIN, then scan the QR code.
The device actually displays amount+account that you are transferring money to. Then asks you if that is correct.
If you enter "yes", it will give you a 8 digit code that you can enter in the website to confirm.
[0] https://www.rabobank.nl/images/how_does_the_rabo_scanner_wor...
[1] https://www.youtube.com/watch?v=f5FIxRsqFUA (work flow - in dutch, start at 20 sec, before that they show the old reader)
These devices are very common in Germany as well but I heard they are phased out and replaced with a solution using a mobile phone.
> have a built-in camera to automatically read an image from the website instead.
In Germany we have a variant that has five photo diodes along one edge. You hold it against a flickering pattern on your screen. This works reasonably well. In my experience it is about equally fast as typing, just a little less reliable.
You can also use it to login with Nationwide, but they also allow login with a password, which is far simpler (and you don't need to find your card to do so either)
To be fair, they're right in the middle of rolling out a new banking site which I think has proper passwords. The current system is a holdover from when they only had phone banking.
Still crappy entropy, though. An eight char password has 56 combinations of 3 positions each, so with N character choices that's 56 * N^3 vs. N^8 the normal way. Gets much worse in comparison with longer passwords.
You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.
Store in DB id position hash user_id 1 0 x0 1 2 1 x1 1 3 2 x2 1
The question is not whether on a technical level something got hashed. The question is whether a hash protects the password against brute forcing. And the answer is no.
Why do hacker news people think they are better at security than multi billion dollar banks?
Many banks (I work for one of them) follow reasonable best practices, allow or require strong passwords, store them safely and require sensible second security factors. Others are decades behind in security, using nonsensical security schemes like the ones morgante and mng2 described above or requiring your password to be letters and numbers only between 6 to 8 characters.
If you care about security, stick with the banks who do as well. Make sure their password guidelines are in order, go with the ones that make you use a second factor, and if you ever see any hints they're storing your password in plain text, run.
Banks are good at not losing money.
But website security is an afterthought for them.
It's easy to make a website that has better security practices than a typical bank website.
It's not about having better skills or resources, it's about having the motivation to do it in the first place.
A bank could set up spectacular security, but that doesn't mean they usually do so.
Everybody knows that we are hopeless at it, and often the flaws that are exploited are just as simple as this.
Tell me why plaintext password storage is bad, and you'll defeat your own argument.