2FA: Do app passwords render the second factor invalid?

Question

I am currently in the process of employing a 2FA authentication on as many services as I can. If it is relevant for the question: I use a time-based OTP authenticator app.

When setting up, I noticed that some services offer a way to login on systems which don't allow 2FA by generating specific app passwords:

• Microsoft offers app passwords to login e.g. via IMAP /SMTP

Effectively, this is a fully working "alias" password for my account, bypassing the second factor. Also, due to its "hiddenness" I might certainly forget to regularly regenerate it every now and then.

Is 2FA with activated app-password really still 2FA or have I just replaced my password-manager-generated password with one generated my microsoft?

Answer 1

Another point: people who type a password usually have it remembered and will surely use it on another service - password reuse. In this cases, no matter how long and strong your password is, it is as secure as the least secure service you use the same password.

So if you have a random 128-byte password, but use it on 3 services, and one of them stores it on plaintext (and it happens more than you think), it only takes one leak to your unbreakable password to be left on the wild. And there goes your security.

To protect on those cases, you have the 2FA. It protects the password on every service you activated it, but protects the third party services sharing the same password. Even if the attacker manages to grab both the password and the 2FA token on, say, orange.com, and you use the same password on pear.com, I can bet the 2FA tokens will differ, and the attacker will not be able to log in at pear.com with your password.

Application passwords solves some problems:

• No password reuse. Every application will have its own secure, long and unique password.

• Less chance to a keylogger grab it. They are usually set-and-forget, and most of the time it gets displayed only once, and if you forget to copy it, you must generate another one. As they are long, you will copy and paste, not type.

• Less change to fall for phishing. User will most of the time go to the service they want to connect, generate a password, go to the application, and configure the password. It's very rare to see a phishing site asking for the user to setup an application password.

• Easy to revoke. One application is misbehaving? You suspect something is wrong with one application? You don't want to use a service anymore? Easy: revoke its password. No need to change the main password, and change it on every single connected service.

As the threat models for user entered password and protocol-used password are different, you need a different protection. That's why an app password is secure, even without 2FA.

Answer 2

The problem with OTP authentication, is that human interaction is involved. You are supposed to first type your password, they type the second factor (or let the usb thing simulate a keyboard and type it for you). That is fine for web form authentication, where passwords are expected coming from a keyboard - in fact it even forces password managers to be able to simulate keystrokes.

But if you want to use IMAP or SMTP, the client application must first acquire the credentials and then send them to the server by the protocol. And the protocol generally has no provision for a second factor.

That is the reason why services that allow other accesses that web via a browser, have to find another way. The common one (application password) normally uses a long random password that cannot be easily guessed nor remembered by a normal human being.

You are right in thinking that this is exactly what can be done with a good password manager: you can ask it to generate a 32 characters random password that nobody (not even you) will ever remember.

But we could just stop a little and think about the rationale for the second factor. A human typed password is generally a weak password. If you can remember it, someone else could also. I am not speaking only of the reversed user name, or the first name of the children but even what is generally seen as good password (the first letters of a rather long sentence for example). A good password cannot be guessed, but it can be remembered much more easily that a truely random generated one!

TL/DR: when using application password you are indeed lowering the security provided by 2FA. It is up to you to know whether it is acceptable of not for the threats you want to address. You should simply ensure that the app password has an acceptable length and change it from time to time.