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:

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?

  • Why do you think that regularly regenerating is a requirement? Much of what passed as gospel about password security has broken down under scrutiny, such as the complexity rules. Do you have specific reasons for this, or is it just because someone on the Internet advises to do it?
    – Tom
    Apr 6, 2021 at 13:34

2 Answers 2


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.

  • This is a good answer. However, a few points: for (2), a keylogger can of course grab the contents of the clipboard also, and take screenshots of the screen too. (3) if you click on a phishing website, it could also ask for the token, or you may realize that the normal password doesn't work and put in one of your application passwords Dec 7, 2020 at 3:18
  • App passwords are also often limited in what they can be used for. An email service would allow sending and receiving emails of course, but not changing the account's password or deletion of the account. At best, you would have separate passwords for sending and receiving, which would allow, for example, an IoT device to send mail but wouldn't give access to your emails in case the device got hacked.
    – Bachsau
    Nov 4, 2023 at 20:31

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.

  • Thanks for the extensive answer. So in general: When using a passwordmanager, do I have to bother turning 2FA on, when the service offers the app password fallback (for which I totally get the necessity)? At my current understanding, the gain is close to zero - even more, Microsoft's auto-generated passwords (which I can only revoke but not customly edit), only contain lower-case letters
    – PhilLab
    Feb 10, 2020 at 16:27
  • @PhilLab: only lower-case letters is not really a problem. What matters is the length... Feb 10, 2020 at 16:32
  • You are right. Microsoft generally allows you a maximum of 16 characters for password (yes, believe me) and it seems they have enforced this limit for app passwords as well -.-
    – PhilLab
    Feb 10, 2020 at 16:42
  • @PhilLab: 16 lower case only gives an entropy close to 75 bits. Not marvelous but not that bad. It just means that you should not forget to change the app password from time to time... Feb 10, 2020 at 16:47
  • @SergeBallesta why do you need an app password? You talk about IMAP/SMTP. But there are plenty of sotware that support 2FA (Thunderbird for example), and you can always use the webmail Dec 7, 2020 at 3:15

You must log in to answer this question.

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