

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

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?<p>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.
======
debacle
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.

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

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

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

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

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

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

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

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

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

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

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

------
Juniper
Maybe they also hash every character separately?

~~~
Ralz
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?

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

~~~
Adirael
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).

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

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

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

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

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

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

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

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

~~~
pbhjpbhj
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).

?

