In the previous posts, we've listed the issues with passwords and what are the features that ideal password scheme should have

In this post, I'll try to present the solution I've thought about, and explain why it solves the issues I've listed.

A solution to password woes

In the previous post, we've seen that a password is merely a secret (can be seen as a contract) between one or more participant. Here, I'm going to consider that this contract will simply cherry-pick some part of a larger secret and use that for one participant, then use another part with another participant and so on.

Imagine you have a secret dug somewhere only you know, and you store in a huge treasure box many evidences to find the hidden place. You need all of them to find the hidden place, yet if I present any of the evidence, you can easily say if they are part of the treasure box.

Now, let's say you give some parts to some participants. Obviously, you need to keep some (most?) of them, because else, if all participants were to meet, they could find the secret by themselves.

Finally, let's say that when you need to execute the contract (that is, for example, get allowed access to the administration panel), one participant will present you a pool of parts, some of them being part of your secret's pool, and some of them being part of something else. Because you know your own secret, you'll select your parts. There is no reason to select any part from any other set from a computing point of view. Obviously, "testing your knowledge" here is limited, either by a number of guesses, either by a number of guesses per minute.

For the most secure scheme, some part could be marked as mandatory (you must select them every time they are presented), and some might only be optional (you might select them if you want, but you are not forced to).
The correct selection score grants your access or not.

Finally, let's say you have an assistant that selects the parts in the treasure box to share with participants so you don't even need to bother with "setting up" the system.

Why does this scheme would solve the issues I've reported earlier?

Issue 1: Dumb password

With this scheme, it's obvious that you can't create a dumb password, since you originate the parts of the secret you want to share. In fact, since it's difficult to remember a hard password (a task we are bad at resolving), we now have to remember some meaning (a task we are made for). You might even not require to remember anything.

Issue 2: Forget password button

You can not forget your password, since there is no unique password anymore. If you remember enough to overcome the threshold to pass the test, you'll be granted access. In the worst case, the assistant will reshuffle the cards for this participant.

Issue 3: No password expiration date

Again, without a single - fixed - password, there's no need to expire it.

Issue 4: Password reuse

That's the whole point of this scheme, use the "reusing" as a good for you without reducing your risks.
We've seen in part 2, that a security of 10^-12 (a random guess with a probability of success of 1/10^12 ) is considered enough for banks (that's your credit card PIN security), so it's a security level we'll try to reach.
Also, since you know what part of the secret you've shared with each participant, you can track the leaks (if any) and dismiss those parts from your treasure box test.

Issue 5 and 9: Delegating passwords

If the acceptance test for a participant is defined, you can share as much part as required for someone else to pass the test without revealing your secret. It's not impossible anymore to share the remaining parts with an escrow or a person of trust that, without being able to guess your complete secret, can give the last missing parts that other participants requires to find the complete secret. Said differently, it's like if you gave the escrow half of a key (which is useless by itself alone) and the other half to the participant. Until they both reunite, the secret is safe.

Issue 6: Identification

This part is not solved with the current scheme.
In fact, there are some article about PII but although feasible (the set of secret's part you're sharing can be a form of identification), it might infer with national laws.

Issue 7: Cookie persistence

While this is more an issue with website tradeoff, we can think about a partial password renewal while a cookie is about to expire. Instead of having to perform the complete acceptance test again, the website could display only a smaller test (lowering the security level here but improving the convenience). That's up to the developers to find an acceptable trade-off.

Issue 8: Single point of failure

I know this goes against the web cloudifying movement, but for such important power delegation, you should not trust the GAFA to act for your interests. Instead, you should implement/install the assistant in your place (if you are tech savvy enough) or use one of the thousand delegated servers. Having numerous servers is a good thing because it spreads the attack's force (it's much harder to attack 100 stronghold than a single one) and you can also decide not to store all your secrets in all servers. It's a bit like initial OAuth servers but without the technical complexity.

Issue 10: Single point of dependency

Unlike a password manager you might bring with you anytime, you might decide to split your secret part's pool in numerous server. If this splitting is made correctly, loosing one assistant might be solve by having enough remaining part in the other assistants that the secret could be rebuilt from those. Obviously, this is a trade off between how much redundancy you expect and the security level. Yet, this trade off is possible, unlike a password manager that hold all your passwords.

Issue 11: Dual authentication scheme

Seen from outside, this is even more than a dual authentication, it's a thousand-al authentication scheme (since you need a lot of parts to authenticate). Yet, none of the single part is required every time. So even if you loose (forget) a part, you'll still be granted access.

Issue 12: Password databases

That's the hardest part to solve. If we consider that assistants are the real holders of the data that are presented to the user, then the password database are "kind of" concentrated and thus, can be hacked. However, since having only part of the secret is not enough to grant access, this will not break the authentication scheme, but only lower the security.
Yet, if such leaks are detected (that might not be the case, or a website owner might not say it!) one can dismiss the leaked part, making the leak useless for hackers anymore.

Conclusion

In the next part, I'm going to explain the algorithms used to implement such a scheme.
If you have spotted any weaknesses in the explanation above, feel free to say so in comments below.