I'm working on one smaller system where it will be required to enter One-Time-Password (OTP, not to be confused with a One-Time-Pad) to download sensitive files which will be delivered to the user.

The primary idea was, to send an OTP via SMS within a pre-set time limit.

But since the SMS in not enough secure, I started to think about any other alternative for delivering an OTP to my users.

I can suggest to my users to use Signal and then deliver them information, but in that case I'm afraid that it will be too complicated for them.

Any idea or should I follow my primary idea?

  • 2
    Who are the users? General population? Worldwide? Enterprise employees? Etc.
    – techraf
    Commented Jun 17, 2016 at 0:17
  • @techraf General population, and this system is not meant to be for large group of users max. 200-300 clients.
    – Mirsad
    Commented Jun 17, 2016 at 0:42

5 Answers 5


Why can't you use TOTP or HOTP which is standard and supported by most authenticator apps?

When people register for your service they need to enroll their authenticator app by scanning a QR code which contains the secret seed used to generate codes.

On subsequent visits the site prompts them to enter codes generated by the app, without any network access since codes are generated locally on the device.

As a bonus, since you're using standard protocols your users may already have a compatible authenticator app installed, and if not, could nudge them into using the app for more services (their Google account, etc). In the end, users are more secure and everyone wins.


Since the question is about ideas:

Automated voice call with PIN code verification before spelling out the OTP.

  • Very easy for inexperienced users - doesn't require additional software, instructions given in real-time, for example:

    Hello this is mirsad's verification system. Please enter your PIN to hear the password for your download

    Thank you, your password is ....., please use it within five minutes. Remember, do not give this password to anyone else!

  • Requires users to remember PIN code

  • Safer than SMS - prevents passive password retrieval (an attacker cannot read from the screen of an unattended device)

  • Requires measures to prevent snooping, for example:

    • listening side produces random audible tones during PIN input and retrieves user-provided code by calculating the difference (my bank does it)

    • ask user to type a different set of random digits from a longer PIN, i.e. "press the 6th digit of your PIN, press the 3rd digit of your PIN" (my other bank does it)

  • Hm, I don't understand this fully, where is PIN code verification happening? Any example of this kind of service?
    – Mirsad
    Commented Jun 17, 2016 at 1:02
  • 2
    "Hello this is mirsad's verification system. Please enter your PIN to hear the password for your download" - "Thank you, your password is ....., please use it within five minutes. Remember, do not give this password to anyone else!" Just like Google 2FA, but with individual identification code for each user.
    – techraf
    Commented Jun 17, 2016 at 1:06
  • I wrote which attack vector is mitigated (using unattended device to retrieve the code). Why this comment? Shall I improve or clarify something?
    – techraf
    Commented Jun 17, 2016 at 10:35
  • @techraf sorry, I wasn't criticizing your particular answer, just that as I said I don't see sending an OTP over a call/SMS as a good idea - this looks equivalent to sending confidential data over plain HTTP. Commented Jun 17, 2016 at 12:44

Vulnerabilities in A5/0 and A5/1 are unlikely to be a major issue for your authentication of a small system with a few hundred clients.

However, if you want to avoid using GSM as a delivery channel, you could have a time-based OTP (TOTP) using Google Authenticator. You would need to create a secret for each user on your server, which he/she can scan with the Google authenticator app. A sample of how this works is here

  • 1
    I would be more concerned about a malicious/compromised carrier than vulnerabilities in the actual wireless protocol which requires to be near the phone you want to attack, where as a carrier vulnerability could mean someone located anywhere with an internet connection could get a real-time feed of all SMS messages received by that carrier. Commented Jun 17, 2016 at 1:30
  • 2
    I don't think anyone is going to compromise a carrier to get some unknown app's credentials. Rather, I assume they already pwned the carrier, and now it's just a game of "what else can we pwn using all this sensitive SMS data?" Commented Jun 17, 2016 at 3:33

As mentioned previously, both TOTP and HOTP are both standards which exist as alternatives to sending one-time codes over SMS.

  • TOTP are time-based codes, and are often available using apps like Google Authenticator, or as RSA SecurID-style fobs or cards.

  • HOTP are HMAC-based, and are often available through token-generating software, including Google Authenticator and similar platforms.

  • There's also the OTP standard implemented by Yubico in the early-model Yubikeys, where the hardware USB dongle emulated a keyboard in order to enter an extremely long one-time password.

And finally, if we are to bring up options which aren't strictly OTP, but can act as a second factor:

  • U2F, an open second-factor standard (stands for Universeal 2nd Factor). It relies on a challenge-response mechanism with a key exchange occurring at hardware registration time. Yubikeys are probably the most popular U2F fobs out there right now.

  • Because they also rely on a key exchange and challenge-response mechanism, SSH keys could conceivably be used as a second factor when authenticating. This method doesn't see widespread use, however.

  • PGP keys, likewise, can be used for this purpose — and like SSH keys, applications where PGP is used as a second factor are, to my knowledge, currently limited.


I agree with @André-borie. But in case you insist on sending some Authentication Code to the user, you might want to take a look at the pushover app. I checked with Telegram but I think Signal is similar. Telegrams API does not allow to intiate a communication to a device.

But you may take a look at pushover.

You must log in to answer this question.

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