Reversed One-Time-Password - generating secret server side In our company we're thinking about a new auth scheme (not a 2FA!) where vault is secured by secret. User should be able to access the vault just by typing the One-Time-Password (OTP) into the webform.

Here is the theory as I understand the normal OTP works:


generated secret is stored on both the server and user's auth app
some function now accept time and secret and generate OTP (6 digits)
server verify if the OTP entered by the user matches the server generated OTP in the same time slot


`

          client                          server
          ======                          ======

         +------+                        +------+
  time --&gt;      |                        |      &lt;-- time
         |  fn  +--&gt; OTP          OTP &lt;--+  fn  |
secret --&gt;      |                        |      &lt;-- secret
         +------+     ^            ^     +------+
                      |            |
                      +- matches? -+


I was thinking if this scheme can be anyhow turned around like this:

`

          client                          server
          ======                          ======

         +------+                        +------+
  time --&gt;      |                 time --&gt;      |
         |  fn  +--&gt; OTP -----+          |  fn' +--&gt; secret
secret --&gt;      |             +----------&gt;      |
         +------+                        +------+


That way our server application will not store the secret anyhow and we get nice familiar UX for users to unlock the vault.
Is it possible to reverse the OTP algorithm like this?
No, that can't work. Reasons:


There would still be the need to compare secret out of fn' against some reference in order to determine if it is correct, hence something confidential in the server (a comment has clarified this is not an issue in the application)
One Time Passwords are short and have little entropy, secrets are longer/have more entropy, and fn' is thus impossible by an information-theoretic argument.
The time is not always the same on the client and server. That issue also occurs for normal OTP, and has various workarounds (trying variations of time, or/and replacing time with an incremental counter which additionally saves on timekeeping power consumption on the client's OTP device).
[Addition] If fn' was public, then knowledge of one OTP and time would be enough to reconstruct secret, allowing to forge other OTPs (assuming fn is public or OTPs are short). That goes against a basic requirement in OTP authentication.