Ask HN: Is this bad security? "Enter the second and fifth password characters" | Hacker News Reader

Ask HN: Is this bad security? "Enter the second and fifth password characters"

12 pointsMarkMc26 comments

When I log into my bank, it doesn't ask for my full password - instead, it asks for two randomly chosen characters from the password. I guess the idea is to make it more difficult for a keylogger to determine the password. But doesn't it mean that my password must be stored in plain text on the server? Isn't that far worse for security than having the user provide the full password?

Edit: Actually the bank requires more than just two characters. Here's their login screen: http://imgur.com/ngRcB The bank is NatWest in the UK. And yes, it's over HTTPS.

View on HN

Yes, it's bad security. Either they have the password in plaintext or they hash each character individually. Either way, it's less secure than you just providing the full password.

But why would you bother hashing if there are only 26+10 possible combinations?

I have no idea. Clearly neither of us know enough about security to work at the bank in question.

This is a terrible idea - incredibly easy to bruteforce, among other things. You now have effectively a two-character password, and even though those characters rotate based on a different set of criteria, the number of valid possibilities is still limited by the length of the full password.

Yes, it also means they're storing your full password in some sort of reversible format. We can't be sure it's plaintext, but given their roll-your-own approach to security that's probably the case. I understand that they're trying to cut back on the damage a keylogger can do and I commend them for that, but they've lowered the overall security of the site in attempt to increase the security in a corner case. More to the point, if a keylogger is installed, the whole system is compromised which means they'll eventually get the entire password even if it's only a couple of letters at a time.

The only effective solution to this problem is real two-factor authentication. Not this password plus "is this your image?" or "security question" crap that a lot of banks employ: that's two-step, one-factor authentication (both are things you know), but a real second factor based on something you have (RSA token, etc.) or something you are (eg. biometrics, which is obviously impractical on the web)

One of the banks I use has an on-screen keyword for password entry to solve the key logger problem.

http://i.imgur.com/8ZwS0.png

Don't most keyloggers also log mouse clicks, along with their location?

I've seen UI's where the keyboard/number pad has the location of the characters randomized, which looked like a good way of solving that problem.

I've seen randomized images bypassed by simply taking a screenshot in conjunction with logging keyboard and mouse actions.

Yes, quite often the "On Left Click" action is tied to a "Take Screenshot" function, useful for defeating these types of on-screen keyboards, randomized or not.

That seems like it would take up a lot of space/bandwidth, but I suppose that it's 2012 and it's trivial.

HSBC asks for a primary password as well as 3 random characters of a secondary password. They could hash your original password + each of the characters in your secondary password, which would mean an attacker would have to crack your primary password first if the database was compromised.

From a UI perspective though it's pretty annoying having to enter 3 random characters of a (complex) password, although it's something you get used to.

No. Banks - hopefully - spend a lot of time and effort securing their systems so that side of things should be secure enough (though obviously not impenetrable). The weakest link will in fact be the user's PC (e.g. keyloggers) in this case as even a few hundred passwords stolen could get the thieves a pretty significant sum of money. So, this is much more secure than entering the full password each time.

You are almost certainly correct in thinking that the password is stored as plain text - which is a massive no-no.

Do they use HTTPS?

The technique could be OK if this is a "second" password (you have already supplied one password and this is a second check) as it would then make it difficult for automated scripts trying to hack the site without compromising your primary authentication.

Maybe they also hash every character separately?

Which would be far less secure than just hashing the entire password. I don't think it takes long to generate a rainbow table based on one character long pass-phrases.

I seriously doubt they do this, storing a hash for every single character would eat up a lot of space very quickly. My guess is that they store your password in plain-text. What bank is this btw?

Most UK banks do this (RBS, Co-op and Halifax all do, and I've heard reports that others do as well)

HSBC also did this. For business they use hard tokens. IIRC they were moving personal accounts to hard tokens too, I moved countries and lost access to my online account because of this (there was no money there, I tried to get them to send me a token to my new address but the person I talked to was hard to understand and the token never arrived).

What would be the point? The purpose of hash functions is that they are difficult to invert. How many characters are there? How difficult would it be to hash each character? Answer: easy.

I'd argue that this is actually good for security in that keyloggers are indeed useless. There's one downside: if the bank gets hacked, you lose your password. But seriously, let's face it, that's not an issue because nobody uses the same password on multiple sites.

>But seriously, let's face it, that's not an issue because nobody uses the same password on multiple sites.

You would expose the password for the most important site though.

They dont necessarily store your password in plain text, they could (and probably do) store each character of your password in a salted hash.

Hashing each character doesn't provide any additional security. The main reason why we hash passwords in the first place is so if an attacker where to get read access, they couldn't deduce the password. But if they are looking in the database and see 15 or so fields of hashes, they can deduce any user's password in at most 256*15=3840 (assuming ascii) tries, which is trivial.

Perhaps they hash every two character combination with a salt? Don't know if that makes it any less or more secure however.

Hashing is pointless. It's trivial to brute force the hash of a two character string with or without salt.

Just out of interest, what would peoples suggestions be for implementing a secure bank login system?

The same way you create any secure login system: Require long-ish complex passwords (numbers, upper, lower, and symbols, 8+ characters). Store those passwords only as slow-to-generate hashes (bcrypt or the like) with a per-user salt. Run everything over HTTPS. Make sure your password reset system doesn't have some trivial bypass or information leak.

If possible, two factor authentication is preferable (whether via hardware dongle or smartphone app, a la' blizzard's authenticator), but that adds a ton of overhead.

You can use the customers phone as the dongle, generate the one time code at the bank end and send it out-of-band as a text message.

You could even have an app that takes the users location from their smartphone and does a loose check on geographic location of the IP being used. The bank end gets the GPS+IMEI or whatever, produces the one-time code and texts it to the user. The user then enters the one-time code and their password on the login screen - perhaps it's used locally to encrypt the password (to combat MITM) before sending over the https connection.

For those without smartphones then charge for a dongle or have a phone based system that you can telephone (enter your postcode and get back the one-time code).

Reply on news.ycombinator.com