> If you think I'm wrong, then write it up in a spec and show us.

Sure. It's fun.

On password creation:

0.0. demand 25% longer passwords from users than considered safe

0.1. along with the hash of the whole password remember a randomly choosen 25% of the characters of the password and their positions (in clear text or reversibly encrypted)

On each login:

1.0. ask only for the characters in positions you haven't remembered

1.1. server-side fill the positions you remembered

1.2. hash the result and see if it matches

If hash matches:

2.0. randomly choose 1/3rd of the freshly provided positions and remember them in clear text on server replacing the previous ones

2.1. give access

If hash doesn't match:

3.0. deny access, don't change anything on server

If I understand correctly - to get the whole password keylogger must be specific to this bank site (to understand which characters are provided), and must be active on at least 4 logins. In my book that's a big improvement.

And I can imagine writing the login page in a way that makes parsing it in keylogger to understand which characters are masked.

> If I understand correctly - to get the whole password keylogger must be specific to this bank site (to understand which characters are provided), and must be active on at least 4 logins. In my book that's a big improvement.

The difference in difficulty of keylogging 4 logins, and 1 login is, in practice, small. Once your computer is pwned, all bets are off.

I think there's a big difference between capturing the whole password at once, and having to reconstruct it contextually - it may be difficult to recover the typing context. Even if the context is known 100% reliably, it will take far more than 4 logins to scrape enough information to reconstruct the password - you need overlap to match the fragments. It the user visits any other site that uses a similar scheme, it gets harder. If a a site chooses to 'salt' the password by making the user retype random characters, it gets much harder - now you need enough logins to apply statistical analysis. If the site makes the user type the characters in the wrong order, you can't reassemble the password at all - all you can do is guess the order.

To gather enough contextual information to defeat all this reliably, the keylogger would also need to be a screen scraper, internet monitor, etc. Straight away, this defeats the not-uncommon case of the inline USB keylogger.

Someone breaking into my apartment, and putting an inline USB keylogger on my computer, that is incapable of doing anything but recording keystrokes, to steal my banking login, is both seriously overthinking their crimes, and, at the same time, seriously underachieving.

That spec seems pretty nice (if rough) and I think I understand what you're trying to do. But, I must agree with @vkou; like I said earlier, it does not solve the keylogger problem.

If there's a keylogger on the system then it'd be trivial to log out the user a few times (and combine with manipulating what the user even sees such as which locations of the password to enter), or just simply be more patient.

Also, what about database backups? Given enough of them and the ever-increasing frequency they occur and time that backups live, you could recreate more of the user's password than intended.

If you only remember 25% of the characters, then you have to ask for 75% of the characters to generate the full hash. Asking for 75% of the characters defeats the purported reasons for partial password auth.

Why? Now all the universal keyloggers don't work (because they remember which keys were pressed, but not which positions they refer to).

Keyloggers don't wrap themselves up after the first log in. They could easily take the data from several log-ins (if they can't scan the HTML) and eventually get a complete password.

Besides which, the partial login isn't random either. It's always sequential. You'll never be asked to enter character 3, then 1, then 8. It will always be asked in the same order as the password string itself.

> It's always sequential.

It's monotonic, but not sequential. On one login you will be asked for positions 1,3,4,7,9, 10, on another you will be asked for letters 1,2,5,6,7,8. Merging such partial information isn't trivial if you don't know which positions you got.

Let's say you have 16-letter password. That's 4 missing letters during each login.

There's (16 over 4) = 1820 possible ways that the characters the keylogger see can be positioned in the real password.

When computers can generate billions of hashes per second, what makes you think a mere 1820 possible considerations are significant?

You get 75% of the letters every time, in order. It's pretty trivial to merge these together after a few examples. Every time you ask for a set of characters, the set of possible outcomes shrinks, and 1820 isn't exactly a large set of possibilities to start with (for your 16-character example).

Given that most people do not use random passwords (and are even less likely to in with a scheme like this), guessing the missing characters is likely trivial for most passwords.

Also the scheme you're describing is very clearly not the one in use here given that they asked for only 4 characters.

I mean... for keyloggers and easier approach is just to distribute some sort of possession authentication device (like a dongle or codes via SMS) where a replayed password will fail to work or... insist that passwords meet some crazy entropy requirements (like 48 characters) and provide download links to password managers that can assist in generating/storing these along with some rudimentary education efforts on the site.

Sms codes are used anyway, to authorize transfers and changes in the account.