6

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.

1
  • Not really related to authentication, but if a service applies end-to-end encryption, a user password will need to be involved at some point.
    – sourcream
    Aug 2 at 10:46

3 Answers 3

4

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.

5
  • I was mostly thinking about Google Auth, yes. Does it only support 6-digit TOTP? OTP doesn't completely protect against phishing, but the usual [password + OTP] 2FA would be just as vulnerable. Do you have something even better in mind that protects against phishing as well?
    – Gendarme
    Nov 17, 2021 at 19:27
  • @Gendarme FIDO2 / Webauthn provide protection against phishing, at least in the usual sense of look-alike page on a look-alike domain. They can be used as either a single factor or a second factor. You're right that password + OTP isn't any better, though. As for the digits, TOTP could in theory be any number of digits but in practice I've only ever seen six, and while it doesn't allow many valid OTPs at once, it does need protection against brute-forcing. It also wants a backup method in case you lose your phone.
    – CBHacking
    Nov 18, 2021 at 1:27
  • FIDO2/Webauthn seems to be for hardware keys like YubiKey. I am not really convinced by them. An encrypted password manager database can be backed up in 15 different places easily, in public hands. As far as I know redundancy is not as easy (or cheap) with hardware keys.
    – Gendarme
    Nov 18, 2021 at 19:59
  • You can do webauthn with platform authentication too. For example, on my Android phone and work Macbook, I can use the fingerprint reader; on my Windows machine I can use Windows Hello. Redundancy is easy with hardware keys (I also have those, standard advice is to get at least two) but it does add to the price.
    – CBHacking
    Nov 18, 2021 at 23:38
  • I see this more as a comment than an answer, as it really doesn't make a strong case for passwords against OTP. I still wonder why we don't see OTP as the 1st factor in the wild.
    – sourcream
    Aug 2 at 10:49
1

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/

1
  • "What if you lost your device?" You can proceed the exact same way as when you forget your password (confirmation of email ownership, for example). No "massive amount of effort & money" needed.
    – sourcream
    Aug 2 at 10:45
0

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.

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.