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...

Yes. This is to protect against attackers obtaining your full plaintext password on your end, for example by phishing or installing keyloggers. In practice this is a much bigger security threat in the online banking world than someone doing the same by compromising the bank's systems - even if that were to happen they can easily re-verify your identity and issue you with a new password, and you really shouldn't be using the same password elsewhere.

It's a ridiculous practice and storing the passwords in plaintext is deplorable. Banks have your phone number, (which can't simply be changed online) and that is the best additional line of security.

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.

you know. It occurs to me that you could actually do this without storing the password in plaintext!

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.

Realistically you could also just limit it to the first 10 characters.

Phishing is a much bigger security threat, but is a much less harmful one than having the password database stolen. It sounds like they are trying to minimize the day-to-day risks, at the expense of maximize the damage of a catastrophic event.

All the systems I've used that do this make you have two passwords, only one of which they are storing in a reversible way.

If the password database is stolen somehow, that probably means that the bank's online banking systems have been compromised. Having the password database stolen is likely to be the least of their worries at that point.

I wonder how often people just type out the full password into the address bar or into notepad, and then start counting to find the nth digit.

Don't be ridiculous. They probably type it into Microsoft Word.

I hope not the address bar, as that goes to Google (or $searchEngine) for autocomplete.

Except attackers usually get the passwords from other sites' databases that do the same thing and don't use proper backend hashing/salting

If someone has that level of access to your system, they can just send themselved the session cookie. Or if the cookie is tied to an IP address, they can just make requests with that cookie from the compromised machine.

If an attacker is running code on your system, you are already lost.

How does this prevent key logging attacks? You still type in those characters. And secondly, that just immediately made it a hell of a lot easier to brute force your way through the passwords!

It asks for different characters from the password each time. So it'll ask for the 1st, 4th, and 5th characters. Next time you go to login it'll ask from 2nd, 8th, 14th. So a key logger is only getting a small portion of the password each time.

So they attacker just has to run the keylogger for enough time...

Yeah I was thinking they could do that. You'd only need to record a few logins.

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.

The attacker needs to both be able to read the page and key log every keystroke and be able to associate as single letter, digit, or symbol to you password and not only that to the correct placement within the password. This is virtually impossible to achieve by any effective means. They ask random characters from your password in a random order if you login into your bank twice a week it most likely will a year or more until a some one can phish your entire password from you this is not scaleable.

>This is virtually impossible to achieve by any effective means.

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.

It doesn't the passwords will be rotated, and they cannot be used for anything without the token.

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.

Only if they also capture the website output so they know which logged key press represents which character of the password.

They also use 2FA i believe.. but then it makes logging in a right pain the ass for customers: 1) track down your massive identity number 2) enter 2nd, 5th, 8th characters of your password 3) locate your 2FA code from the HSBC device they send.

And they totally wont kill the account after a couple of wrong attempts, right?

They can use Shamir's Secret Sharing to achieve this with no plaintext.

see http://willtracz.co.uk/shamir-secret-sharing-and-passwords

>> "This post is intended to introduce concepts and practically demonstrate a method. The implementation provided is not a reliable/hardened solution (i.e. there are vulnerabilities because finite fields are not used) and should not be used anywhere near a production system."

Above is on the page you're linking to.

Yes, I wrote it and it is intended as a demo only. I have not put in the finite field logic in that implementation. It shows the concepts though.

HSBC doesn't do that any more for me -- they've moved to a Google Authenticator-like 2FA approach[1], but Lloyds[2] does - they have one username and password, and a "memorable phrase" which they clearly store as plaintext because ask for the xth, yth and zth character as a secondary security measure. Lloyds tech folk reading this -- please consider fixing this.

[1] http://i.imgur.com/QCGPDWz.png [2] http://i.imgur.com/VdtGC4T.png

Why cant they just also hash those three letter combinations they ask you? Not nearly as secure but I see many people saying that the plaintext must be stored to achieve this, and all I am thinking is that it would require you to store multiple hashes for each user, each a portion of their password.

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.

Three letter hash combinations and single letter hashes would all be essentially plaintext. The security of a hashed password comes from the fact that the password comes from a field of 2^(# of bits) possible values (with more useful bits the more types of "characters" allowed). If you only have a few characters that is so easily crackable (by brute force of every letter or three letter combination) that it might as well be plaintext. It is a security failure if they can get at some of the characters in a password.

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.

It would be absolutely trivial to enumerate all possible three-letter combinations and hash them. That's no better than storing in plaintext.

HSBC always used a token for online banking you can either order a secure Key or for the past year or so use a mobile authenticator.

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 :)

Authy addresses the losing your phone scenario.

Edit: I realise you're probably referring to proprietary bank authenticator apps

Yes they do so do quite a few others, but this is about the HSBC authenticator :P

Same for Natwest, but this does not mean they store it in plain-text.

I have the memorable phrase and have to use the HSBC app for my password. Now, the fun thing is that my actual HSBC password is 40 characters randomness, so pretty secure. The mobile password that is used to derive the 2FA key must not be longer than 8 characters. So essentially I traded a long and secure password for an 8 character password.

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.

Plus the unintuitive navigation, the ridiculous over-skeuomorphism of 'past statements', and the insanely-low, seemingly non-configurable session timeout. At least you can finally use a payment reference > 10 characters, but HSBC's online banking is still stuck in the stone-age overall.

I do not agree that they store a password in plain text. You cannot say for sure. What if they hash each character and store each with its position in the db?

That wouldnbe still pain text actually, because it's easy to have a table for hash -> char. Chararcters being limited by their numbers.

Fine. Refer to my detailed answer below that shows longer hashing difficult to bruteforce.

I don't find your other answer. But, basically if you hash one character, there is only ~ 255 possibities (a-zA-Z0-9 plus some special chars). So, a 10 characters password is only ~ 2,500 hash to compute and that's nothing. Might as well store it in plaintext, because it in fact is.

Lloyds UK has a system that I quite like, you have your credentials and then to login they ask you 3 random letters of another password that you select from 3 dropdowns. This way you have your password that is presumably secure, and you have this thing which is pretty fast to complete once you get used to it, that should help with people looking at you or keyloggers.

Around here every bank require 2fa for logon and then again for signing payments (although you can queue and batch sign a number at a time. )

Barclays in the UK does 2fa if you order it, otherwise this strange bit with just parts of the password.

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.

> 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.

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.

> though it's often not a second factor but just the way you log in to online banking.

That's still 2FA though, isn't it? You're proving to the server that you have the card and the pin.

The Rabobank system when used for online shopping using the "rabo scanner" works by redirecting to their site. Then displays a color QR code that your scanner reads.

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)

>> You get a pocket-calculator-like device > Such a thing is rather common in The Netherlands,

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.

That's because they are reusing a multi-purpose device. Nationwide uses the same calculator-like device to make you sign new withdrawals with your card in the machine.

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)

The Co-operative Bank does this too. They absolutely store the password in plain text, because if you phone up, you have to tell the whole thing to the phone operator.

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.

That does not mean they store plaintext passwords. When you login to most any website you have to submit your whole password. It is usually hashed and the hash is compare to the stored hashed pasword

From my conversations with the telephone banking operators, it's clear that they have the plaintext password in front of them.

On the other hand a publicised password leak from a major bank would be the end of the bank whether they stored passwords hashed or plaintext.

Not necessarily. It might actually store multiple versions of your password as A.....B...C (where . means some known-to-them character, basically salt), ..A....B.C., etc, basically all the combo-of-3 templates encoded as PWs. Then it asks for one of them and recreates the template before comparing.

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.

They could be extracting the 1st, 6th and 7th characters, concat them and storing the hash (+salt) of the resulting string. That way they can check equality without storing the plaintext password.

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.

You realize that this is trivial to brute force, though.

I never said it was a good way of storing passwords. It reduces entropy. I'm just saying there is way to both have hashed password storage as well as "asking for 3 random letters of you password at login".

You replied to a comment saying "That implies that they store plaintext or something reversible." You posted about hashing in a way that implies that comment is wrong. But that comment is completely correct. Taking three characters and hashing it is easily reversible. And then the attacker gets to log in.

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.

Not when they'd presumably lock the account for some period of time after a few failed attempts.

Password hashing is used to prevent the brute forcing when the attacker already has the copy of the password database, and is free from any failed attempt limits and timeouts. And in this case storing hashes of all 3-letter combos is basically useless, since all those hashes are very easy to bruteforce.

Ah ok, so you're starting from the assumption that the site has already been owned and the attacker has the hashed passwords. In which case yes, it does make it easier.

Can't it be achieved by this simple steps? Consider ur password is y. a) f(y, i) = a func that gets i'th character of a pass. y; b) hash(x) is ur hashing func; c) x0 = hash(y); d) concat(a, b) - concatination func; 1. x1 = hash(concat(f(y,1), x0)); 2. x2 = hash(concat(f(y,2)+x0)); . . etc

Store in DB id position hash user_id 1 0 x0 1 2 1 x1 1 3 2 x2 1

No. You limit to 3 attempts per user before you go to the bank to show ID.

Why do hacker news people think they are better at security than multi billion dollar banks?

Because in some cases they are.

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.

Hashes are meant to secure the password in the event of a db compromise. The 3-try-lockout thing is useless if you have the hash.

You're conflating completely different kinds of security.

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.

I'm guessing you've never worked in IT, but security is a joke in the entire industry.

Everybody knows that we are hopeless at it, and often the flaws that are exploited are just as simple as this.

Presumably in case someone is watching you type in your details.

Or the answers are premade when the password is created.

Not necessarily – they could be hash + salting multiple permutations

No amount of salting is going to make a 3-character recognizer secure.

The 1, 6, 7 is random

The problem is, if you have a bunch of partial passwords 1, 2, 3; 1, 2, 4; ... you can just brute force three character combinations of the passwords, which just takes something half a second (times the number of rounds) if you write your password cracker in bash. So your complexity goes from 52^n for a n character password consisting of lower and upper case to n/3* 52^3 which is a lot more manageable.

But three strikes and your out - out to the physical bank with proof of ID to change it.

You're assuming that the verification is being done by the bank itself. This is under the assumption that there has already been a security breach. The password database has been stolen, and has just been sold to the highest bidder. In that case, there is no lockout.

Not if they steal the database. No matter how you limit the external access you also have to protect against people with unlimited time with a copy.

That is nice and all, but the scenario we are talking about is a db compromise, in which case any rate-limiting is circumvented.

That defense also works for plaintext passwords.

Tell me why plaintext password storage is bad, and you'll defeat your own argument.

That's irrelevant.

This one at least makes some sort of sense; it's designed to prevent keyloggers from reading your password when you type it in. You can just MiTM the connection though.

It doesn't. Today's banking malware will capture the form values on submit, either as text or as a screenshot. And it will do so, silently, every time you log in.

All this scheme does is limit an attacker to gathering three letters per login attempt. Given an eight-letter password, three logins will probably disclose most of it; or at least enough for an attacker to pass the challenge when he tries to log in.

In addition, if the attacker is actually interested in your data, he can easily inject a fake "wrong password" message after your first attempt and have you try again, gathering 6 characters per login.

Modern keyloggers track mouse and take screenshots on clicks.

I know of some of those sites that randomise the location of keys and then hide the key labels on mousedown, I assume to try and avert that issue.

(Curious as to whether it would actually work though.)

A hacker can get around that by also taking a screenshot when there is no mousedown event, it's literally one extra line of code.

Or just take screenshots periodically each second and then submit with a mouse click the one before the click.

It still doesn't work when the bank asks for different characters the next time you connect.

Gah, i have seen one too many asian made online game do this.

First you enter a password, then you have to enter a pin using a on screen numpad with jumbled placements.

And likely the game will be doing all manner of things client side, thus it is cheaters all over the place.

> don't even let you type your password in. Instead you have to use their janky on-screen keyboard to fumble your way through login.

Wow that's just insane. I'm glad I haven't run across any services like that. I'm not sure what their line of thought it; it only inconveniences normal users. A person attempting to try multiple passwords can likely figure out how to get around that restriction without issue.

> I'm not sure what their line of thought it;

It's theoretically a defense against key loggers. Of course, if someone has compromised your machine to the point where they're tracking key strokes there's no reason to assume they can't also grab your mouse presses and websites.

This isn't even their worst security practice. What truly got me to leave was their security questions: they're presented as multiple choices. My randomly generated string stands out rather obviously next to the "typical" choices.

Yeah it's stairs and ladders. One I saw also randomized the position of numbers on the keypad, so you need now also to track that.

Which is pointless anyway because at the point you access the keyboard buffer you can as well install a certificate and get a proxy going

This is where convenience trumps security. Virgin Money used to require you to enter your password using an on-screen keyboard, except they REARRANGED THE LAYOUT EVERYTIME YOU USED IT. Thank fuck they eventually got rid of it, but it was such an abject pain in the ass, I cringed everytime I needed to log in to view my details.

I wouldn't even call it a trade-off between convenience and security, because there is no security gained. This is a trade-off between convenience and stupidity. If someone suspects that a keylogger is there, the entire computer should be assumed to be compromised. Trying to guess the capabilities of the keylogger and working around them is ludicrous.

It's a valid defense against hardware keyloggers, ignoring that you're way more likely to encounter a software keylogger.

If your account is interesting enough for criminals to break into your computer room and attach dongles to your PC (I'm imagining a Mission: Impossible style break here), congratulations: you've clearly made some good financial decisions in life :-)

Not unrealistic to assume a scenario where a disgruntled IT technician installs countless hardware key loggers throughout an open plan office. Could be easier and less noticeable than trying to circumvent the business-grade antivirus.

FWIW Tradeking no longer do this. Not sure when it changed, but I haven't had any issues using a password manager with them since.

TreasuryDirect formerly had this and it drove me nuts. That and the crazy drogan's decoder ring they forced you to use.