Security implications of partial passwords

0x6e6562

Hi all,

This is not an issue for 1P per se, but I thought this forum might be a good place to get some pointers about password strength.

Many banks require you to enter the i(th), j(th) and k(th) letters/digits of your password.

So if the underlying password is, say, 30 symbol random password, is requiring only a subset of the passwords making it easier to brute force?

Or is there some security magic that I'm not aware of that is retaining the unguessability of the underlying?

Or is it the case that most banks would argue that 3 random characters is still large enough to make it hard to attack from a practical/pragmatic perspective?

Thanks,

Ben

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

RichardPayne

Or is it the case that most banks would argue that 3 random characters is still large enough to make it hard to attack from a practical/pragmatic perspective?

It's enough given that the attempts will be rate limited.

The real problem with the "pick X characters" approach is that it requires that the bank have access to your password. Sure it will be encrypted on the server (at least you'd hope) but the encryption key must also be on the server and so the system is at risk if the server is penetrated.
It is far safer if they hash the password and then compare the stored hash with the hash of the entered password.

The one way in which it is better is that it makes it less vulnerable to key loggers. However, a hashed password plus 2FA setup covers both key loggers and server side compromises and so is a generally better solution than picking random chars and storing the password with reversible encryption.

AGAlumB

@0x6e6562: What RichardPayne said. :(

The only rationale I can come up with for these shenanigans is that this ensures that someone "eavesdropping" won't get your whole password. And, presumably, subsequent login attempts will require different n th characters to be entered, making even the portion that is captured less useful...

..but all of this seems to be predicated on the assumption that the system you're using to login has been compromised. It can't be concern over a network attack, as the connection should be end-to-end encrypted over HTTPS. They are using HTTPS, I hope! :dizzy:

And if you're put the user through this "in case s/he is compromised", well...at that point an attacker probably has other means of stealing data. After all, they may not have the full password to your bank account, but all they have to do is wait and collect screenshots and save copies of webpages as you navigate the site.

So I really don't see the point of all of this. Maybe I'm missing something. :unamused:

RichardPayne

I've noticed a really crappy pattern from my bank. I have a 20+ char password but it only ever asks for 2 of the first 5 chars and 1 of the last 2. I might as well just have an 8 char password.

Megan

Hi @RichardPayne ,

The security measures of some banking institutions never ceases to amaze me.

0x6e6562

Thanks very much @RichardPayne, @brenty, @Megan for your observations, much appreciated :-)

I get the feeling that the requirement to choose the two from n[3-5] together with either n-1 or n-2 comes from the old telephone banking setup whereby you knew you had to transmit a certain percentage of your secret key over an inherently insecure medium (the medium being either the insecure RTP stream handling DTMF input from your handset or just saying it outright to a call centre agent and having them input it into the backend).

So it's like an old technical limitation has evolved itself into a becoming a current business requirement, despite the fact that technology has moved on.

khad

So it's like an old technical limitation has evolved itself into a becoming a current business requirement, despite the fact that technology has moved on.

I think that is an excellent way to put it, @0x6e6562. It's sad how often that sort of thing happens. It's a bit like cargo cult security, doing something that someone told them was secure (once upon a time) without really understanding why it was useful in the past which would reveal that it isn't helpful anymore.

RichardPayne

More than likely @0x6e6562 and banks are notoriously conservative and backward with security. They see change as a risk.

AGAlumB

I get the feeling that the requirement to choose the two from n[3-5] together with either n-1 or n-2 comes from the old telephone banking setup whereby you knew you had to transmit a certain percentage of your secret key over an inherently insecure medium (the medium being either the insecure RTP stream handling DTMF input from your handset or just saying it outright to a call centre agent and having them input it into the backend).

@0x6e6562: Oh wow. You may be onto something here! It's been so long, but if I think real hard, I can recall using telephone banking in the 90s. It's chilling to think about, but certainly there's a lot of really creaky legacy stuff still running the show in the financial sector. Chilling, but fascinating all the same.