I have a client that would like to use one-time passwords (via SMS or Email) for their app, and their requirements spec does not include traditional password-based authentication. I haven't seen this done before -- would it be considered bad practice?

My assumption was that 2FA is generally more secure than 1FA, regardless of which "factor" you're using to authenticate. However, one could surmise that 1FA w/ OTP is more secure than 1FA w/ traditional password.

2 Answers 2


Not necessarily. This is a scheme where you don't want to store a password for the user. Sometimes, this is done so that the user doesn't need to remember yet another password (in fact, there are users heavily relying on resetting the password every time, which produces a similar email-only "passsord").

There are also other parts surrounding this system that need to be taken into account:

  • Suppose we authenticate Alice by sending a SMS code to her phone. Eve is hanging out with her and, while Alice is away leaving her locked phone unattended, Eve logs in as Alice, reads the provided OTP code in the lock screen and performs malicious action. In this case OTP-only would be weaker, as an additional password would have prevented this attack.

  • SMS-only or email-only login mean that compromising such external service will immediately compromise your site account. See eg. Hackers Are Hijacking Phone Numbers And Breaking Into Email, Bank Accounts

  • Consider on the other hand that we require both a password from the user and that they have access to the email. We may consider that more secure than just requiring an email token. But then, how are you providing account recovery when the user forgets its password? Just by sending an email? Then the password doesn't provide additional security from an attacker that compromised your email.

  • Local token generation (like TOTP), are more robust against a third party compromising the service used as login. But phones (where people install them) break / are robbed and get changed much more often that you expect. So you still need to be able to allow some way of recovery for that.

The part I like most about not requiring a password is that it can sustain phishing easily:

  • Alice goes into the company.com and enters its username. The website sends her an email with a link to log in. At that point the opened page is no longer used. She goes to her email and browses from the safe link provided to her. Thus, a fake website can't lure her to provide an email code, to a phishing page, since navigation continues from the emailed link.
  • An attacker could send a fake email with a phishing link, but there arwould be no credentials to harvest there (hopefully, it won't make her enter their credit card details on the "just logged in page").

(Note that albeit less 'natural', you could do the same by requiring the password after following the link, or forcing to close the page after successfully providing the password, and continue on the link.)


Authentication via One Time Pad is still a passord by any other name. What's more, it begs the question of how the pads will be distributed?

In essence you would have to predeploy dozens, hundreds, thousands, of passwords (pad pages) in advance while maintaining synchronized hashes on the server. The client would have to protect the pad pages before use, probably with encryption and a password.

Unless you have a really unusual application, the logistics to use a OTP correctly is crushing while the likelihood of incorrect use is high.

I have seen this kind of thing used years ago as a form of Challenge/Response but it was abandoned pretty quickly as unmaintainable.

  • 2
    OTP in this context means one-time password, potentially sent over sms or email, or generated using HOTP or TOTP. Jan 22, 2019 at 0:46
  • 1
    Hazard of acronyms, they're not always the same to everyone. Thanks! Jan 22, 2019 at 4:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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