What's more likely - that the bank gets hacked, or that you install a keylogger?

Also there are ways to implement this without keeping the whole password in plaintext/reversibly encrypted. One example I just thought of:

Ask for 75% of the password each time, remember random 1/3rd of that (25% of full password) till the next login together with the hash, and on the next login ask for all the letters you haven't remembered (and fill the ones you remembered, then hash everything and compare).

You can adjust the percentages as needed if having 25% of the password in clear text is too insecure.

> What's more likely - that the bank gets hacked, or that you install a keylogger?

Given the (apparent) lack of security for the bank, I'd say the former. IF the bank was actually secure, then sure it'd be more likely for me to have a keylogger.

> Also there are ways to implement this without keeping the whole password in plaintext/reversibly encrypted

Maybe.

> One example I just thought of: Ask for 75% of the password each time, remember random 1/3rd of that (25% of full password) till the next login together with the hash, and on the next login ask for all the letters you haven't remembered (and fill the ones you remembered, then hash everything and compare).

I challenge you to really think about what you're proposing to do. I think it's far more convoluted: it does not solve the keylogger problem and adds complexity to both the client and the server. If you think I'm wrong, then write it up in a spec and show us.

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

> What's more likely - that the bank gets hacked, or that you install a keylogger?

The bank gets hacked. I say this with the utmost certainty because while I haven't been hacked since I started behaving securely at 15 years old, my bank that uses partial passwords was recently hacked. I live in Pakistan, a lot of banks were hacked 2018-2019.

I also complained to them about saving passwords in plaintext. They never replied. Every bank in my country is terrible.

So you're still storing part of the plaintext... That's still insecure

Plus, the keylogger could just collect a few logins and it completely defeats the whole thing, so it doesn't help anyway. It's just terrible, it makes everything worse

25% of the password. Shouldn't matter that much. And you can change the percentages to for example 10% (asking for 90% of the password each time). Demand slightly longer passwords if that's a big problem.

Hm, actually instead of masking the password to defeat keyloggers they could also just permutate the characters. So that you have to enter password in different order each time. But usability would suck so much :) I prefer the masking.

Also - universal keylogger wouldn't know which characters of the passwords you were asked for. They would need to make a keylogger designed for this bank website so it can understand which characters you provide. And they would need to update the keylogger with updates on the login website (which preasumably would be written in a way that makes it hard to know which characters these are - for example with randomly generated ids of the input fields and provided in random order then positioned with javascript).

I know - security by obscurity. But it does help.

I'm sure it will help the bank's helpdesk job security, but not much else.

Remembering a specific character of a password is not easy to do, so people will probably type it into notepad and then count to get the right one anyways.

TOTP is much more usable, and probably more secure than inventing your own ridiculous partial password scheme.

You just spell your password in your mind and when the character is needed you press the key, when it's not needed you don't. The login site looks like this:

    [x] [ ] [x] [ ] [ ] [ ] [ ] [x] [ ] [ ] [ ] [x] [ ]

And when you press a key it jumps to the next empty field.

If you actually use random passwords, this isn't possible. You have to pull up your password in plaintext so you can view it in its entirety and manually count to the correct character,

This partial password stuff is just utter garbage. It's lower security than a typical password, way lower security than multi-factor auth, blocks use of password managers, and is generally inconvenient for no good reason.

I don’t spell passwords in my mind; I have muscle memory for the password.

Well, yes, it's slower. But not by much. A few seconds.

Some of my passwords I have memorized only as muscle memory. Without going into too much detail, if I didn’t have a qwerty keyboard, I wouldn’t be able to enter it without a couple minutes of thinking “okay, this key is there on a qwerty keyboard...”

I create my passwords from long, easy-to-remember sentences that I sample to be like 15-25 characters long with capitalization and special characters added in a pattern.

Makes it easy to remember the password without muscle memory.

This means you're re-using passwords. There is zero chance that you remember hundreds of unique passwords for all the different sites you need access to. Good money says that your pattern is extremely predictable and anyone who sees one or two of your passwords has enough context to know the pattern for all other passwords.

I have exactly the same issue with my passwords. I can remember what the letters, numbers, and symbols are, but I can only remember which letters are uppercase by typing it out on a keyboard.

My bank has been hacked (affecting my account) twice since I started using it, but I'm yet to see any effect of a successful attack against my machines...

Considering that password databases are getting leaked on a regular basis at this point, depending on any specific password database not getting leaked is a pretty bad bet.

How many users get compromised if a bank gets compromised vs. if one user installs a keylogger?

The answer in your [0] link is pretty uninformed. The author admits in comments that they never heard about Shamir's secret sharing.

But yes, all of the points raised in the answers [1] are totally valid. The extra security benefit is so small that really not worth the negative impact on usability. System designers should rather focus more on implementing 2FA.

It took me a little bit to find the explanation for this scheme: https://web.archive.org/web/20160909032102/https://smartarch...

I'm not defending this strategy, but you could still do this with hashing. Just create a different hash for different combinations when creating the hash.

Your hash is going to be of a tiny set though, the same as a 4- or 5-character password. That's possible to brute force in seconds, even with the slowest algorithm.

Not only that, but enumerating all possible combinations of 4 or 5 characters from a 20 character password would be untenable.

Also, if all those combinations were stored would the software use separate salts for each one? Well designed software would but I suspect anyone intelligent enough to consider that would also raise a loud voice at the meeting where this feature was being discussed. They probably use a common salt and if it's known how long (at most) each partial password is (say 5 characters) it's super trivial to generate a rainbow table to break it.

Honestly, even if the salting was done independently per chunk, the fact that you know each chunk is under 5 characters long massively reduces the time to generate a rainbow table to verify the password, even more so if the entry field only allows 36 character entry.

Again, not defending this I'm just being technical. You wouldn't need every permutation. 100 is probably plenty.

20 choose 5 = 15504. You could enumerate them all in less than a second and store all the hashes in less than a megabyte.

Problem with this is that you just transform the problem into generating collisions on multiple hashes of multiple short strings, rather than one collision on a long string. Even if you salt the hash, you have a substantially smaller search space on each of the sub-sequence hashes.

I was just going to comment that implementing this requires storing the password in cleartext on their servers... that's absolutely terrible and not at all best-practice... in fact, the furthest thing from!