Secret sharing, using methods such as Shamir's Secret Sharing allows for t out of n shares to recreate a secret.

For authentication, the secret can be a user ID. A client with a logged-in user can store a token holding both a user ID and secret share. A server can hold another secret share for each user ID.

When requesting something that requires authentication, the client can send the user ID along with its' secret share. The server can use the client share and its' own share for the user to recreate the secret user ID. If the recreated user ID matches the ID that the client claims to be, then the server can proceed to fulfill the request. If not, then the request can be rejected.

Is this authentication scheme secure? If an adversary were to intercept a secret share for a user, would anything other than the user be compromised? Does this method have any practical use?


1 Answer 1


This scheme is no different from standard password-based authentiation / standard cookie-based authentication:

You have a token (call it "password", "cookie" or "share") and an ID (call it "username"), you send it to the server, the server does some processing using additional values only it knows and gives you a yes / no answer for whether or not you are authenticated.

  • For classic passwords, this would be password-hashing with a DB-stored salt and comparison to the stored salt.
  • For cookies, this would be either a static comparison or an integrity check on the cookie server-side with a server-side static key.
  • For the given scheme, this is the secret-recovery and verifying whether the recovered content matches a specific format.

Is this authentication scheme secure?

It is as secure as the standard approach of sending a username and a password. So it usually works, especially if your channel is authenticated, eg using server-authenticated TLS, anyways.

If an adversary were to intercept a secret share for a user, would anything other than the user be compromised?

Well, if the server-side shares are user-dependent and the shares are unrelated / independent, then obviously nothing can happen to the others if one is compromised. The exception being of course if the user in question can log-in as an admin or something and just read-out or modify the shares or the received shares.

  • $\begingroup$ Ahh I see, thank you. What if the scheme were asymmetrical, and the server had only one secret share that, when combined with unique client secret shares, produces a user ID secret that verifies each user? $\endgroup$
    – Kabir Shah
    Commented Dec 30, 2018 at 4:46
  • $\begingroup$ @KabirShah then the share of the user is a password and the server share is a secret pepper applied to each password -> you still need some way to confirm users, especially if they lose / get their shares compromised -> you will probably hash the resulting secret. $\endgroup$
    – SEJPM
    Commented Dec 30, 2018 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.