Welcome to the mailbox.org user forum!
 

Two-factor authentication with regular password instead of PIN

2266884 shared this idea 2 years ago
Proposed

For most services it's common to use TFA with the account's regular password and a token, that is valid for a limited time. In most cases that is also more secure than an easy to guess 4-digit PIN number.

Comments (11)

photo
3

> For most services it's common to use TFA with the account's regular password and a token, that is valid for a limited time

Agreed. Mailbox.org is the only mail provider I've seen using this kind of multi-factor authentication. I feel the most common MFA/2FA in use on the Internet right now is that which user 2266884 has noted.

That is, login with your standard account passphrase and then provide a second one-time-valid, dynamic passcode generated by a hardware token or special smartphone application. (Codes sent via SMS are, thankfully, not one of the MFA available options; see https://www.bellingcat.com/news/2016/04/30/russia-telegram-hack/ )


> In most cases that is also more secure than an easy to guess 4-digit PIN number.

This sort of one-time password method does strike me as less secure than a more layered approach—such as the common 2FA method described above (assuming the initial master passphrase is sufficiently secure itself; see https://krebsonsecurity.com/password-dos-and-donts/ ).

Two points for the Mailbox.org team:

1. Where it is actually the case that a one-time password method is described (that is, providing a user-defined PIN plus dynamic password token to login), please consider re-wording it to state this, foregoing any mention of 'two-factor authentication'. Also, ideally, explain the difference, between these authentication schemes.


2. Please actually deploy the more common 2FA method described above.

photo
2

i think that this should be optional.

OTP make sense if you want to protect your email from keyloggers etc. If you put your normal password instead of a pin and if you allow to connect to your email through smtp then someone could login to your email using smtp.

photo
1

Exactly.

I wrote a more verbose explanation below for the people who would like extra clarification.

photo
photo
1

Any news on this?

photo
4

Actually, I think the PIN is a great feature and makes 2FA more secure. At least, when you keep IMAP and SMTP access enabled.

Why is 2FA interesting?


  1. Because you want to log in on untrusted devices and not risk your password being logged (or seen by lurkers etc.).
  2. If your password is no longer secret, people still can't log in, because they're missing the OTP generated on a trusted device.

Thus, if you would log in with your regular password, it could get exposed and people would get access to your emails via IMAP, because authentacting via IMAP can't be done with OTP (imagine the hassle by the way). They would not be able to take over your account, though, as all settings are only accessible via the web interface and thus protected by the OTP as well.

However, if your PIN is exposed, it's completely useless without the additional OTP. They can't even access you're email via IMAP. Sure it's easier to guess than a complex password, but you're only vulnerable if your trusted device gets stolen too (and it's not encrypted and locked). If you're even a little bit careful, this is easily avoided (unless you're a profiled target).

Google does this a little different. You can use your regular password with 2FA, deny insecure access with just your password and use IMAP with a key that's generated for your trusted device only. Mailbox.org has stated that they don't want to generate special keys that get linked to devices because of privacy concerns: Each device would have to be registered and linked to your account. I respect that.

That being said, in theory a complex password would be more secure than a 4-digit PIN. Maybe they could let you set an (additional) password instead of the PIN, or a longer PIN. This way you could set your standard password to a very complex string for secure access via IMAP (which I do) and set an easier to remember password to use in combination with the OTP.

photo
3

> Thus, if you would log in with your regular password, it could get exposed and people would get access to your emails via IMAP, because authentacting via IMAP can't be done with OTP (imagine the hassle by the way).

If you look again at how Google (or any other mail provider) have implemented multi-factor authentication, you can see that this is a non-issue. For instance, with GMail, you cannot log into IMAP with your regular password -- you need to create a randomly generated "app password" which is only usable for API access like IMAP. You can then revoke these app passwords to give you granularity and the ability to revoke stolen passwords. Please note that these app passwords can be shared between devices, which should eliminate this concern that you brought up:

> Mailbox.org has stated that they don't want to generate special keys that get linked to devices because of privacy concerns: Each device would have to be registered and linked to your account. I respect that.

The way that Mailbox.org has designed their system makes it less secure than common alternatives (and people like me cannot reasonably use 2FA with Mailbox because I use a password manager -- so filling in their weird password format is just silly).

Not to mention that IMAP supports SASL, which would in principle allow for TOTP-based authentication (using the "EXTERNAL" SASL scheme). But as I said above, it makes much more sense to just follow how Google designed their authentication scheme for Google Apps.

photo
1

In short:

If the privacy concern of registering devices with mailbox.org is lifted, as you seem to suggest, I agree that it would be awesome for mailbox.org to adopt the same authentication system as Google. However, I still believe mailbox.org's system is already a step up from authenticating with your password + OTP if the same password is used for IMAP access (as most common alternatives). I feel more than comfortable with the security measures in place right now, but that's personal.


Too long:


> Please note that these app passwords can be shared between devices

Hmm, I did not know this. So basically you're saying that Google's app passwords are app specific rather than device specific? So the "Thunderbird password" could be used on all instances of Thunderbird across devices and you wouldn't have to register any new devices/instances?

> The way that Mailbox.org has designed their system makes it less secure than common alternatives

Not most common alternatives, as far as I know, which is why I mention Google. (Do you know others?) Most other services just use your regular password instead for IMAP and this common method is suggested by the OP, I believe. By the way, I suggested above that mailbox.org allow you to set a different password than the 4-digit PIN to increase security (but at the same time I think the PIN+OTP is already plenty safe for my use). In short, I think Mailbox's way is more secure than most, but not as secure as Google's.

> people like me cannot reasonably use 2FA with Mailbox because I use a password manager

I don't know which password manager you use, but this works fine with mine. You have to manually insert your OTP anyway, right? I suppose the one-line password (pin+otp) gives you a problem? Maybe your password manager doesn't allow you to type the password without submitting it automatically? I know KeepassX allows you to change how it enters the password...

All this being said (and not really in response to your comment), I do believe Google is top notch on the security front and I do trust their security measures to be solid. However, I think most people here are looking for alternatives because account security isn't their problem with Google, but privacy is. If you want both, you just use PGP for everything and use a keypair generated by yourself...

photo
1

> So basically you're saying that Google's app passwords are app specific rather than device specific? So the "Thunderbird password" could be used on all instances of Thunderbird across devices and you wouldn't have to register any new devices/instances?

Yes, it's what I'm currently using for my Google Apps account. Here's the Google documentation about App Passwords: https://support.google.com/accounts/answer/185833. I use the same App Password for esmtprc, Mutt, and mbsync across all my devices.

Actually, Mailbox has an opportunity here to be more secure than Google (in principle) if they also added OAuth-style scopes to App Passwords. This would allow you to only authorise an App Password to be able to (for example) use IMAP and SMTP and not allow access to other Mailbox services. Though of course this is not a blocker for this isue (but note that obviously you cannot log into the Mailbox.org website with an App Password).

> Not most common alternatives, as far as I know, which is why I mention Google. (Do you know others?) Most other services just use your regular password instead for IMAP and this common method is suggested by the OP, I believe.

I can't really comment on Email services (aside from ProtonMail -- which uses Google-style 2FA -- but they don't allow IMAP access). However, most websites I've used that offer 2FA work in the same way as Google (you use your normal password and then provide a 2FA token afterwards) -- examples include GitHub, GitLab, BitBucket, CloudFlare, DigitalOcean, NextCloud, Mastodon, Twitter, and so on.


> I don't know which password manager you use, but this works fine with mine. You have to manually insert your OTP anyway, right? I suppose the one-line password (pin+otp) gives you a problem? Maybe your password manager doesn't allow you to type the password without submitting it automatically? I know KeepassX allows you to change how it enters the password..

I use KeePassXC, and yes I could use AutoType and then manually fudge the OTP part, but this is more of a hassle than it should be (and the 4-digit PIN is just a silly restriction). I can understand having this system for YubiKeys (because this workflow is the same as the YubiKey PAM module), but for 2FA it is a complete departure from normal login workflows.

photo
1

> Yes, it's what I'm currently using for my Google Apps account. Here's the Google documentation about App Passwords: https://support.google.com/accounts/answer/185833. I use the same App Password for esmtprc, Mutt, and mbsync across all my devices.

Thanks for the link. From the docs it sounds to me like you need to select the device you're using to be linked to an app password. I'll take your word for it that you can use this password on more devices. I haven't tried it myself.

> However, most websites I've used that offer 2FA work in the same way as Google (you use your normal password and then provide a 2FA token afterwards)

By Google's method I didn't refer to the fact that you use your regular password + OTP, but the fact that they solve the security problem of logging into applications that don't support OTP - or where you don't want to use OTP - with just you're password.

As I've explained in my first post in this thread, if you can use your regular pass to read your mail via IMAP, you open yourself up to an attack when logging into an untrusted device with that same pass + OTP.

Google solves this by giving you the option to not allow login with just your password and letting you generate these app passwords instead (which are useless without an OTP).

Mailbox solves this with the PIN for web login and password for IMAP. The PIN can be snooped, but is useless without the OTP.

I understand this seems irregular, but I believe this is more secure for an email service that offers optional logins without OTP. Not as secure as Google, but more secure than others.

I'm guessing the other accounts you mention using the "common 2FA" don't offer app passwords for you to log in without OTP (except maybe via a dedicated app?). But there's not the same security issue there, as they don't have to be compatible with existing widespread protocols or third party apps for access.

As far as the matter of having to combine the PIN and OTP in a single line is concerned, I don't really have an opinion on that. Either way is fine for me. Maybe it could be useful to users if they changed it, but I don't feel strongly either way.

I don't really understand though, how login workflow (with KeepassXC) is different one way or the other. Could you elaborate?


I hope that I'm making myself clear. If not, I will try to explain my point more clearly and I'm of course open for further discussion!

photo
photo
1

I also find this PIN approach unique to mailbox.org, haven't seen it elsewhere.

It may have its benefits however I like the "normal" approach better.

To clarify, here's how I'd like to authenticate presumed 2FA is enabled:


  • mailbox.org web client: I login using my password followed by 2FA token (no 4-digit PIN is required for setup/login).
  • external email clients / SMTP servers etc: All attempts to authenticate with my password without 2FA token is denied. In order to get around this for applications that does not support 2FA I get the option to generate a app passwords somewhere under the mailbox.org settings (with the options to create/revoke/label different app passwords).

As the ignorant user I hope improving 2FA and implementing app password support will be among your next development priorities - just my 2 cents :)

photo
5

I'd like to add a third suggestion, which hopefully entails all your previous demands on a secure authentication/login scheme. Furthermore, I hope that it has manageable administrative complexity.


The Scheme would consist of the following three passwords:


The Master Password:

  • Purpose: only for administrative stuff, like resetting your passwords, changing your account details, or changing your email plan
  • Frequency of use: rarely
  • Usage: This password should be stored in some sort of password manger as you only need it once in a while. It is your last defence line against identity-theft, and should only be used on trusted devices.
  • Password limitations: none (it should be as complex and long as possible)


Web-App Password/PIN (+optional 2FA):

  • Purpose: Logging in to the Webinterface of mailbox.org
  • Frequency: often
  • Usage: This password is your daily driver if you do not use a Mail Client (Thunderbird/Outlook/...). So you should know it by heart, or have it ready in the password manager of your choice. You can secure it with 2FA if you want to have higher security (e.g. against key loggers), but it's optional.
  • Password limitations: none (if you want to use 4-digits with 2FA go ahead, if you want 64-digits with 2FA have fun typing ;) )


API-Password:

  • Usage: For IMAP/SMTP and alike
  • Frequency: once (for each device)
  • Usage: This password is only for IMAP/SMTP access to the mailbox.org server. It should not work in the Web-App. However, there is only one such device password. So the only knowledge mailbox.org obtains is that you use IMAP/SMTP which they see in their logs anyways. Furthermore just one API password eases the pain of administration on their sysadmins. The only drawback in case of api-password compromise is that you need to reset the password on all devices, but as this shouldn't happen on a regular basis, the pain is limited.
  • Password limitations: none (should be long and could be randomly generated by mailbox.org)


One could even decide to make this scheme opt-in, as 2FA is right now.


If 3-passwords are to complicated for you, you only use the "Master Password" for all three usecases, which actually is the default right now.

If you want more security you only need to set 2 more passwords (Web-App, API) and optionally 2FA.


Pros:

  • It does not affect privacy in a negative way
  • It's requires 2 more Fields in the User Database for the Web-Interface Password and the API Password (relatively sysadmin friendly)
  • Your as safe against identity-theft as you can be. Even if your device is owned, or you access the Web-App on a keylogging machine, you still have your Master Password to kick the intruders out of your account.
  • It can easily be configured to be opt in.


I hope I didn't miss any of your points. I'd be happy to read your opinions!