2

I'm looking for the typical ways to generate a One Time Password. I know about the HOTP and TOPT. But, in my case, the problem is that the "server" only has a display as interface and the otp-generator-app should work on one or more mobile devices.

Currently I am thinking about using a secure Pseudo Random Number Generator. The generated number will be displayed on the "server". Then the user has to enter this number into the mobile devices. The generator uses the input random number and a pre-shared secret, links them together, and hashes them several times. The result is the OTP.

Is there a similarly standardized way to generate an OTP?

Edit:

I have a server with a login to a secret area. On the other hand I have different mobile devices that maybe able to login in the same secret area. So there are many devices that have to be synchronized before each login.

In the HOTP there two possible kinds of shared secrets: Random Generation and Deterministic Generation.

In my opinion the random generation is not possible because of the multiple mobile devices for the same login. I can think of no solution as synchronizing the secure prng like the HMAC_DRGB or other.

With Deterministic Generation, the master secret is only stored on the server. I am not able to find a way to share the shared secret securely with only a display.

So that's the reason why I'm looking for other standards to generate a OTP...

Or is there any way to store the secret securely on the server and the clients?

4
  • How are you seeding your Pseudo Random Number Generator? It had better not be something predictable like time.
    – user288447
    Commented Sep 10, 2014 at 11:49
  • 2
    I can't understand why you can't use HOTP or TOTP. Could you describe your requirement in more detail (and while you're at it, reformat your question so it becomes more readable)
    – Stephane
    Commented Sep 10, 2014 at 12:26
  • You ask about the typical ways, then reject the typical ways. Are you sure that you are looking for standard implementations, or rather that you need a custom solution?
    – schroeder
    Commented Sep 10, 2014 at 15:38
  • 1
    hash(shared secret + timestamp) might be a more userfriendly solution depending on your application.
    – guest
    Commented Sep 10, 2014 at 23:01

1 Answer 1

1

Think about this implementation (Disclaimer: this is basic):

Server displays a Random Number that changes every 30 seconds (R)
Mobile device has a unique device ID (DID)
Server maintains a record of authorized DIDs
Both server and mobile device share a secret (S)

When the mobile device wants to log in, it requests the active R from the server. The mobile device then calculates hash(S + DID + R) and sends the result to the server along with the DID. The server uses the same algorithm, and if it matches, then you have some level of assurance that the authorized device is the one now actively logging in.

Couple this with a typical username/password credential that is tied to the DID and you have a VERY basic 2FA. The downside is the necessity to maintain and communicate S before this process begins.

This process is the basic function of OTP generation, but there are more secure means of implementing it if you look. Remember the rule:

"Don't Roll Your Own"

2
  • Do you mean share the secret for each OTP Generation or only once? Secondly how can I find out if the DID is not faked? And last but not least how can I store the secret safely in the mobile device?
    – Andreas
    Commented Sep 12, 2014 at 7:09
  • The secret would be shared beforehand, and would be unique to the DID. You can help deal with faked ids by also paring the DID to the user login. Storing on the device is it's own separate question...
    – schroeder
    Commented Sep 12, 2014 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .