I wrote to them pointing out the issue and apparently it was put on their backlog for the following year. I think I received an update about it a couple of years later.
Asking for random letters is a poor man's version of a zero knowledge proof. It's only marginally more secure than asking for the full password (if you want to break into an account you need to observe someone entering the password a few times instead of just once), at the cost of a very crappy user experience.
The key difference between storing plaintext passwords and hashed passwords is that with hashed passwords, you can only compromise users who log in during the interval when the system is compromised, and even then, only for worse compromises (eg if all the attacker gets is arbitrary disk read, compromising hashed passwords would be impossible in most scenarios.)
Though, my bank uses a dual-password setup where the first password is required in its entirety and a few letters of the second password are required. I suspect this is stored by using a (hopefully memory-hard) salted key derivation function/password hash function (such as Argon2 or scrypt) to derive an encryption key from the first password, which is then used to decrypt the second password.
At least, that's the way I'd design the system to minimize consequences of database compromise. Users are often not creative and often use related passwords. You'd want all of the stored information about the second password to provide clues to the first password only if the attacker had already cracked the first password. Hashing all of the permutations really blows up storage space and DB I/O.
Ok, yes. Encryption could work, but encrypted passwords aren’t much better than plain text ones.
I think a lot of implementations don't do anything clever and just have a fixed set of combinations they use each time, so the number of stored hashes is smaller.
With Shamir's Secret Sharing, you start out with your secret expressed as a finite field element, and pick N-1 polynomial coefficients uniformly randomly from your finite field, and give M different participants values of the polynomial evaluated at different points. Information theory shows that having at most N-1 points on the polynomial still leaks no information about F(0). It's as secure as a one-time pad, and in the degenerate case of N=2 over a Galois field, is in fact a XOR-based one-time-pad. The amount of entropy added at generation time is greater than the amount of entropy in the secret.
In this partial password case, you'd want the "shared secret" to be a single value, and construct a polynomial such that, say 4 field elements, would always be sufficient to recover the same "secret". You're running the algorithm the wrong way, and unless you're forcing a password on the person, those letters are actually low-entropy instead of maximal entropy field points as in Shamir Secret Sharing.
I really don't see a way to use polynomial interpolation in this way without leaking entropy. I thought about using something similar to Schnorr threshold signatures[0] to solve the information leakage, but then you end up storing one elliptic curve public key per password letter, and the private key for each public key is a single letter, so trivial to bruit-force.
But yeah, that's infuriating.
It plugs in as an HID so that passwords appear to have been typed in, not PW managed.
Useful little thing, it seems too good to be true.
Edit: I'm also a bit uneasy about securing access to all by accounts by one single PIN that can be used to unlock a physical device that is easy for someone to steal unnoticed.
