Feature Request: Allow disabling 'login by email'

[skyguy]

Firstly, I'd like to say "Thank you"! Thanks for creating Mox and making it available to the world!

I had been procrastinating on upgrading my server, dreading having to configure DKIM, et al, but mox has made it all so much simpler. I was especially inspired during your FOSDEM talk when you said how mox will check your setup and warn you of problems - that's really useful.

Of course, I do have a request!:

I've always given my users an accountname which is distinct from their real name and email address and is thus never published anywhere. This helps tremendously with stopping crackers from guessing passwords because they first have to guess the correct accountname, so even a poor password is not a great security risk.

It seems with mox that my strategy wouldn't be effective anymore, as crackers can use any published email address to attempt password cracking? (Many of my users use a 'catchall' alias so they can implement my other tip: to give out email addresses as <companyname>@my.domain )

Is it possible to configure mox to have account names seperate from email addresses?

Many thanks
-Kevin

[mjl-]

Hi @skyguy! Great to hear. I had the same problem with my previous setup (dreading making any changes to it), which in the end resulted in mox. :)

Is it possible to configure mox to have account names seperate from email addresses?

Indeed this is not possible at the moment. But I understand your reasoning. It will indeed make any password guessing less effective. It should be possible (technically) to add login-by-account name.

There are some minor complications:

• Autoconfiguration may not work at all (or not as well). For autoconfig, users will use the account-setup flow of their email client to configure their account. This typically involves specifying their full name, email address, and password. That is enough to fully configure the account, and it's all that for example Thunderbird is asking. With a different account name, either the user needs to also input their account name (but more likely simply not use the easy autoconfig setup flow), or the autoconfig endpoint that returns the config for an email address would mention the username to login as (but this defeats the purpose because attackers can just lookup the account name that way too). The general direction email setup has been going into, is login by using the email address as username. Btw, using just the localpart of an email address as username won't help because password guessers will typically try those too.
• The email address used during authentication is used in at least submission (smtp) for some (optional) behaviour. Like choosing the SMTP MAIL FROM address to use when delivering the email. An account can have multiple addresses and doesn't have a primary address. In short, some functionality may not be available when using account names as email addresses (like using "unique mail from addresses per message"), and mox would have to gain some code to use the address in the From-header of the submitted message to find the address to use as SMTP MAIL FROM. Not a showstopper, but does complicate code and explanations to users about these limitations.

Some reasons why I haven't considered password guessing a big problem:

• Mox has builtin limits on active connection, per ip/network. It slows down connections with failed authentication attempts (increasingly longer wait time on same connection, and remember that attackers can't have too many open at once). And it has rate limits per ip/network from which failed login attempts are coming, rejecting new connections for a while after too many failures. This limits the number of authentication attempts (password guesses) an attacker can do greatly.
• Password attacks won't be effective on good random passwords. I think they can only be effective for passwords reused from/shared with other services where the password is leaked, or perhaps for very very weak passwords. Mox does warn users about bruteforce attempts when setting a password, and helps users generate a random password. So essentially, this only is a problem when the user makes a mistake in picking a password. By keeping the username secret, it feels like it's a bit like another part of the password. Perhaps it could be better to not let the user choose their own (potentially weak) password, and just generate one for them when they want a new one? We could make this an option per account (which you enable when you don't trust someone to generate a random one). Btw, I saw just now that the new-password warning message doesn't mention the risk of reusing passwords, I'll at least add that to the text.
• Luckily, many attackers attempt authentication on the port 25 for SMTP delivery (where authentication makes no sense nowadays and isn't allowed at all by mox), not on the submission ports (where authentication is required). So many guessing attempts are futile in practice. Of course, this won't last forever, attackers will wise up at some point...

Btw, a recent change went in to log authentication attempts, both successful and failed. Updating to pre-release versions is safe (almost always is, commits only go into the main branch after testing and when I'm OK running it myself). Can be interesting to see how many attempts you're getting, and from where.

So, summarizing: Login-by-accountname is not possible at the moment, there are a few minor reasons why, but I think it could be implemented. But I'm not so sure it's worth it given the mitigating factors already in place.

[mjl-]

@skyguy I added a config option for not allowing custom passwords for an account. That should prevent password reuse across services and weak passwords for the common case. It's only automatically enabled for newly created accounts. I'm hoping this is enough to resist brute force password guessing attacks.