6 ms·

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

12 points by MarkMc 14y ago

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.

Juniper 14y ago
Maybe they also hash every character separately?
- Ralz 14y ago
  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?
  - deleted 14y ago
    [deleted]
  - stordoff 14y ago
    Most UK banks do this (RBS, Co-op and Halifax all do, and I've heard reports that others do as well)
    - Adirael 14y ago
      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).
- recursive 14y ago
  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.
kaolinite 14y ago
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 14y ago
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.
TamDenholm 14y ago
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 14y ago
  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.
debacle 14y ago
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 14y ago
  But why would you bother hashing if there are only 26+10 possible combinations?
  - debacle 14y ago
    I have no idea. Clearly neither of us know enough about security to work at the bank in question.
alinajaf 14y ago
Perhaps they hash every two character combination with a salt? Don't know if that makes it any less or more secure however.
- recursive 14y ago
  Hashing is pointless. It's trivial to brute force the hash of a two character string with or without salt.
tvdw 14y ago
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 14y ago
  >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.
jameswyse 14y ago
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 http://i.imgur.com/8ZwS0.png
- pavel_lishin 14y ago
  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 14y ago
    I've seen randomized images bypassed by simply taking a screenshot in conjunction with logging keyboard and mouse actions.
    - nik_0_0 14y ago
      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 14y ago
        That seems like it would take up a lot of space/bandwidth, but I suppose that it's 2012 and it's trivial.
gtsc 14y ago
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.
TamDenholm 14y ago
Just out of interest, what would peoples suggestions be for implementing a secure bank login system?
- showerst 14y ago
  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 14y ago
    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). ?
Firehed 14y ago
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)

12 points by MarkMc 14y ago

Juniper 14y ago

Maybe they also hash every character separately?

Ralz 14y ago
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?
- deleted 14y ago
  [deleted]
- stordoff 14y ago
  Most UK banks do this (RBS, Co-op and Halifax all do, and I've heard reports that others do as well)
  - Adirael 14y ago
    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).
recursive 14y ago
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.

kaolinite 14y ago

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 14y ago

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.

TamDenholm 14y ago

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 14y ago
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.

debacle 14y ago

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 14y ago
But why would you bother hashing if there are only 26+10 possible combinations?
- debacle 14y ago
  I have no idea. Clearly neither of us know enough about security to work at the bank in question.

alinajaf 14y ago

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

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

tvdw 14y ago

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 14y ago
>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.

jameswyse 14y ago

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 http://i.imgur.com/8ZwS0.png

pavel_lishin 14y ago
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 14y ago
  I've seen randomized images bypassed by simply taking a screenshot in conjunction with logging keyboard and mouse actions.
  - nik_0_0 14y ago
    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 14y ago
      That seems like it would take up a lot of space/bandwidth, but I suppose that it's 2012 and it's trivial.

gtsc 14y ago

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.

TamDenholm 14y ago

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

showerst 14y ago
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 14y ago
  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). ?

Firehed 14y ago

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)