Is it a bad idea to replace passwords with OTP?

Question

As I understand things, given a user with proper password management (e.g. with a libre password manager like KeePassXC) the only realistic threat is having passwords leaked the following ways:

• A: password keylogged (e.g. logging in to your account on any compromised device) or phished

• B: manager database leaked (e.g. unlocked on your compromised device)

OTP as single-factor authentication is enough to protect against A if not attacked before token expiry (but perhaps that is not a realistic assumption after reading the answer of @CBHacking). In this regard, OTP is superior to passwords (even if not as much as I previously thought), and I cannot think of any way they would be inferior. Thus, OTP seems strictly superior to passwords.

2FA mitigates the risk of B, but it seems excessive for marginal benefit: it is relevant if and only if the first factor is compromised while the second one is not. While this might not be an uncommon situation today, I think it would be uncommon in the case where OTP replaces passwords and even more uncommon with the premise of a user with proper password management for the following two reasons:

• OTP is less likely than passwords to be stored on a compromised device (PC).
• A user who uses a password manager is more likely to store both factors on the same device (I myself have my TOTP and passwords in the same KeePassXC database).

Even if I am wrong about 2FA being excessive, and especially if the user is not good at password management, it seems superior to have [OTP + OTP] rather than [password + OTP] as 2FA.

---

Is it a bad idea to offer users to replace passwords with OTP?

Is it a bad idea to force users to replace passwords with OTP?

If passwords are not used, does 2FA (double-OTP instead of single-OTP) offer substantial benefit?

---

P.S. While writing this I came up with one reason [password + OTP] might be superior to [OTP + OTP]. In the former case it is less likely that both factors are stored on the same device.

Answer 1

The main way that OTPs are weaker than regular passwords is that they need to be made available to the user through some method, before the user has authenticated. There are a few ways to do this, with widely varying security. For example, SMS is very weak - it's considered weak even for a second factor, so using is the only factor is extremely poor security - because it's relatively easy to intercept, re-route, or access on a stolen device (lots of phones configured to display SMS even on the lock screen). On the other hand, an OTP from a hardware device or phone app (could be HOTP or TOTP, the latter better known as the algorithm Google Authenticator uses) is generally pretty safe (though still weaker, if used alone, than almost any two-factor approach).

OTPs are also often weaker than traditional passwords in that their maximum entropy is much lower, and they're easy to enumerate. Typical six-digit OTPs have a million possibilities, or roughly 20 bits of entropy. That's as much as a decent but not great password. The odds of anybody successfully guessing it are generally low enough to not worry about, but it's well within the range that a large botnet could brute-force trivially if you don't have protections against such threats. On the other hand, if you allow the user to request OTPs (e.g. for delivery by SMS or email), and each request delivers a new OTP (because you're hashing them in the DB, to reduce the risk of them being exposed while still valid), then the attacker could make their job a lot easier. Suppose they are able to get 1000 OTPs valid at once for a given user; then they have a 1/1000 chance of guessing right, and that's doable with a single Internet connection and at most a few minutes. There are ways to protect against this, of course - rate-limit requesting new OTPs, disable existing OTPs when a new one is requested, deactivate all OTPs for a given user if there are some small number of wrong guesses, monitor for things that look like brute-force attacks and block them possibly by disabling the targeted user account - but these all have their own threats as well (usually that an attacker can prevent another user from logging in, though this threat also exists for traditional passwords).

It should be noted that your two threats miss the biggest threats BY FAR: phishing and credential stuffing. In terms of real-world compromises, phishing almost certainly causes the greatest monetary losses to businesses and probably also individuals, but credential stuffing (reusing a compromised password from site X to log in as the user on site Y) is also common. (You might argue that a "user with proper password management" precludes password reuse, but in the real world people reuse passwords constantly, often even if they also use a password manager, and if you're choosing the auth systems to support, you have to take real-world user behavior into consideration.)

OTPs eliminate the credential stuffing attack, and in that way are a substantial improvement over traditional passwords. However, they don't help against phishing; if the user expects to be entering an OTP, and they get an OTP, they will enter it (even if the site they enter it into is actually an attacker's phishing page). If the session is short-lived and requires a new OTP to log in again once it expires, that that limits the damage possible from a single phishing success, but usually sessions can be long-lived after you've authenticated once, and even short-lived access can do a lot of damage.

Answer 2

OTP is indeed a lot more secure than regular passwords. However, one example that I could counter that would be "What if you lost your device?" How would you prove that it is you who are the one that has the access to the account? How would you prove to the other programs, such as your email, telling that it's you who's trying to log into your account? Trying to figure this out would take a massive amount of effort & money, for both user and company, to remediate this.

For multi-factor authentications, entering an information that only you know (information that you constantly know) single-handedly helps improve security. Even if you lose access to OTP (Password + OTP), you still have some information that you entered prior to creating your account to help back up your claim.

Is it a bad idea to offer users to replace passwords with OTP?

Overall, it's not a bad idea to replace passwords with OTP, guaranteed if they are trusted to not lose the IoT devices. However, the general consensus is to not trust the users at all.

If passwords are not used, does 2FA (double-OTP instead of single-OTP) offer substantial benefit?

Even though it takes a lot more effort, which wastes time for users, I believe it should help a lot because if website don't implement the security system to keep track and suspend accounts with a specific number of failed attempts, it is possible to brute force the account with 1 OTP until they keep guessing it correctly.

Edit: The basic rule of 2FA is also based off of the user providing 2 out of the 3 things: "Something you Know, Something you Have, Something you Are". Just purely having a OTP without any of the 2 other rules will defeat the purpose of security.

Source: https://auth0.com/learn/two-factor-authentication/

Answer 3

I am also asking myself this.

I'm not too fond of passwords.

I think they are an awful design and need to be eradicated.

My current idea is only to use OTP but in the form of QR Codes. So instead of entering a six-digit code, you scan a QR code just like many are doing at the moment with the vaccine passes.

First, you add an account by scanning a QR Code to my authenticator app (Replacement for GoogleAuthenticator). Then you can use your phone to generate a new constantly(sub-second) changing QR Code to authenticate with.

All my services require a webcam and multi-platform access anyway, so this is not a hindrance.

That way, I can make the OTP as long as I want to or the QR Code allows. It does not matter if the OTP is hundreds of symbols and should make brute-forcing impossible. Also, it should significantly help that the Code will be changing too fast to have enough time to crack it. Also, depending on the level of risk, I can make the user scan Codes many times at specific points of the service, making fishing less likely.

Second, to remove or lower the risk of account loss due to device loss, I want to use a system based on what we often do with physical keys. Users can give their private keys to people they trust. Let's say you have three friends and share your key with them. You can then set how many of your friends need to come together to forge your private key again. So if you lose your phone, you would gather 2 of your 3 Friends and recreate your private key. No need for me to authenticate you because only your friends have access to your key, and only your friends know that those essential parts are for your account. So even if they were to be stolen, you would have to try endless combinations of key parts to generate an account again eventually.

As the service provider, I don't even want to be able to get into a user account eventually. I hope that I can have this on a more web3 basis and have users authenticate each other removing the risk of significant data leaks on my side.

I just started working on this, so nothing to show now, but I hope to in the coming month.

What you describe is better than what many people have now, so it is a significant improvement. Most people have horrible habits when it comes to passwords, and anything that makes reuse less likely can be a considerable improvement.