Reversed One-Time-Password - generating secret server side

Question

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 -->      |                        |      <-- time
         |  fn  +--> OTP          OTP <--+  fn  |
secret -->      |                        |      <-- secret
         +------+     ^            ^     +------+
                      |            |
                      +- matches? -+

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

`

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

         +------+                        +------+
  time -->      |                 time -->      |
         |  fn  +--> OTP -----+          |  fn' +--> secret
secret -->      |             +---------->      |
         +------+                        +------+

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?

Answer 1

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.

Answer 2

As you note, HOTP/TOTP authentication is based on a shared secret. The server and client agree in advance on the (symmetric) shared key and this improves security if and only if the secret remains a secret.

There is another 2FA authentication scheme called U2F. U2F uses (asymmetric) public key cryptography in place of the shared secret model at the cost of an additional round trip in protocol. U2F enables the secret to be retained on the client side only. The process is illustrated below.

Note that in this case the server is performing a validation of the signature to authenticate the credentials. The client retains the secret key and would have to share the associated public key with the server in advance (instead of the client and server sharing a secret in advance).

There are several vendors offering hardware tokens which support the protocol, but there is of course no reason it couldn't be implemented in software.