16

When I log in to hotmail or Google or posteo I can only log in using the 2FA that I have set up. However, each provider seems to have an alternative for apps that do not auth via a web client.

  • Hotmail/Google: 16-lowercase-characters "app-specific" password
  • Posteo: IMAP/POP3

This app-specific password gives any app complete access to your account. I can use the same app specific password from thunderbird to read all the messages using a mailing app on my phone.

In Posteo's case, I simply enter the password as if 2FA was not set up, and I would be able to load any inbox.

Now given the above situations, I really don't understand how IMAP/POP3 and app-specific passwords can exist when 2FA is enabled, as they completely bypass 2FA.

What is the critical thing I'm missing here?

Improve this question
1
  • In case of Posteo, there is only a single password and 2FA only secures the web login and account administration. What you are 'missing' here is that Posteo actually recommends to deactivate IMAP/POP3, so that you can only login through the web client. It's really inconvenient that they don't support app passwords.
    – kapex
    Commented Apr 10, 2022 at 12:17

4 Answers 4

Reset to default
10

You are not missing anything.

It is a convenience option that usually has to be opted into specifically when 2FA is enabled - and somewhat defies 2FA.

Otherwise, smart phones and email clients would be quite useless, or at least cumbersome.

In the case of smart phone mail clients: for most 2FA options, the smart phone is the second factor, so there is no massive benefit from it either. (And other options might not be possible, for example iPhones cannot use yubikeys).

Nonetheless, 2FA still helps you when the IMAP/POP3/SMTP password is strong and unique for that account and the connection is secured by TLS: you can still not be phished and can use your smartphone and the password can not be brute forced and can not leak (because it is strong and only used there).

Improve this answer
6

Authentication on the server side isn't magic. It's just algorithms doing what algorithms do. If 2FA is enabled on a site, the site will ask for your password, then assuming that is correct, it will request your 2FA code. If the site has a mechanism like app-specific passwords, and you supply one, then it won't ask for the 2FA code. That's simple enough.

The advantage with app-specific passwords is that you can configure an application or service with limited access to your account. An app-specific password typically can't be used to make changes to your account (unless a site is badly designed or buggy). You would still have to have your master password and 2FA code to do that.

Improve this answer
0

In general I agree to @Craig

typically can't be used to make changes to your account

to clarify this part:

2fa in combination of app / domain specific passwords is a good practice to secure your digital identity as good as technically possible atm *) i.e. better than without, but isn't the holy grail. 2fa addresses not only (the most important part) of enriched security level but also making logins easier without a password safe, since you might lower your password 'complexity' (to be kept in mind) while in combination of the second factor (possession) your account security might be improved. (I don't say you should do this that way ;) )

Still: a compromised app / mail password can be used to abuse your account, e.g. opening accounts on other systems or make orders in behalf of you with your correct mail address; even the attacker isn't able to make changes to your password or account details on your Identity Provider in general. You are still able to recover ... if you are in knowledge of an abuse usage.

Still: if 2fa is just on top of a bad password and there are no app specific password, app (mail) security is "compromised" because of false positive safety feeling of 2fa in web; watch out for your provider security settings what is possible, it might be more secure to keep your "old password" ( https://www.xkcd.com/936/ ).

app specific passwords are nonetheless just as secure as the provider generates them. And their advantage is only given, if they do restrict access to a given resource. Providers like "the big G" doesn't make a great job her in my eyes, since the passwords are generated 128bit only with a low entropy (no special chars, etc) and this password can be used for any API without restrictions. The given "application" is only a hint to you, where you do use this if you like to revoke one.

*) as far as I know there are no known RFCs for advanced IMAP/POP protocols that would take mail clients in advantage of 2fa. And I doubt we will get one because of the "big" backward compatible problem of legacy mail clients.

Improve this answer
0

You have to specifically allow that option for a reason: it does defeat the 2FA, because the password is enough to allow access.

The reason is to allow rich clients that are unable to use 2FA like mail readers on computers or smartphones to still access your mail. The expected counter measure to cope with the loss of 2FA is to use a strong password. I would never use that below 12 random characters. But it is not really a problem because in that case you let the computer or the smartphone remember and type the password, and the security is handled on the terminal.

That means that you should only use that on a trusted and secured computer or smartphone, and only use 2FA on less secured (or trusted) environments.

Improve this answer
5
  • App-specific passwords really don't defeat 2FA, because they don't provide administrative access (unless a site/system is very poorly architected). If compromised, an app-specific password would certainly provide access to read and send emails from your account, but that's a partial compromise at most. The app-specific passwords are randomly-generated, and a specific warning is typically give that the password should not be saved anywhere. It doesn't need to be. It can easily be disabled and replaced with a new one.
    – Craig Tullis
    Commented Dec 24, 2019 at 20:25
  • @CraigTullis While access to read and send emails is indeed 'only' partial compromise in regards to the email service, it usually means complete compromise of all services that are linked to that email address and don't have 2FA enabled (or if email access allows to bypass 2FA). Random app passwords are ok, but Posteo which is mentioned in the question, does not support them. There is only a single password (chosen by the user) and 2FA is only required for the web login but not for imap/pop3. In that case it defeats the purpose of securing emails in my opinion.
    – kapex
    Commented Apr 10, 2022 at 12:12
  • @kapex If you use a service as lame as Posteo, that's on you.
    – Craig Tullis
    Commented Jun 25 at 13:39
  • @CraigTullis Whats the issue with posteo?
    – kapex
    Commented Jun 25 at 17:47
  • @kapex Its inability to support paradigms as common as app-specific passwords. And no, app-specific password implemented correctly don't defeat the purpose of 2FA, because the authority tied to those app-specific passwords will be limited as well. For instance, an app-specific password will grant the ability for a service (which cannot utilize interactive 2FA) to retrieve emails via POP3 or IMAP, but not administer the account. There's a balance between usability and security.
    – Craig Tullis
    Commented Jun 27 at 16:33

You must log in to answer this question.

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