tutao / tutanota

Tuta is an email service with a strong focus on security and privacy that lets you encrypt emails, contacts and calendar entries on all your devices.
https://tuta.com
GNU General Public License v3.0
6.13k stars 531 forks source link

Disallow logging in with aliases #1557

Open itisafrickinhighlander opened 5 years ago

itisafrickinhighlander commented 5 years ago

I believe I have to raise this issue, which shall not be a "feature request". Alias should NOT be allowed to log into the account, only the main address should (an option to change which it is is appreciated, but that is a topic for another day). Doing so and not exposing the main, original e-mail address adds up to 80% of e-mail security as unless credentials leak other way, no malicious attempt to hack the account would be successful, it would be merely a guessing. With aliases we use every day we expose ourselves to multiple points of danger.

This issue was brought to a light in a recent Reddit post here with a recommendation to never use the original e-mail as not exposing it anywhere is a fantastic step towards e-mail security, which was afterwards "debunked" by other Reddit user. So far there it makes us 4 asking if that is for real in a regular overlooked type of Reddit post, which I would already consider that a sign of "Oops, something has gone wrong here".

From the e-mail response on this topic you seem to give an answer that you plan to change it. In my opinion, planning in this case is not enough, I hope you will see how this actually is a security flaw in the design.

I hope, you don't find a calendar having a higher priority. I will rather use a paper calendar than having anyone knowing my login e-mail into my own private e-mail, as that is how it is right now.

charlag commented 5 years ago

Slight correction: we don't believe it is a security issue. There are rate limits. It makes absolutely no sense to try and bruteforce it online. There's no real threat model: someone steals your password without stealing your address? I don't think so.

We will change that but we need to take care of existing users who already do log in with their aliases and who may find it convenient. We should allow changing the main mail address first. It's not a snap of the fingers.

armhub commented 4 years ago

Depends on #1769

geedelur commented 4 years ago

+1

One of the reasons I started using the service was for the aliases feature. I though that by doing that I'd be able to successfully hide my username from e-commerce and other sites.

sed-i commented 2 years ago

we don't believe it is a security issue. There are rate limits. It makes absolutely no sense to try and bruteforce it online. There's no real threat model: someone steals your password without stealing your address? I don't think so. -- @charlag

There is a use case in which this is indeed a potential security issue:

  1. a user intentionally only using aliases, to keep the main user name hidden, so only aliases are used for all subscriptions/correspondences.
  2. some website leaks email addresses and hashed passwords, and the hashed passwords are brute-forced.
  3. attacker attempts to sign in with the alias and the cracked password, assuming the user reused the password.

In fact, I believe that keeping the main login secret and only using aliases for comms is best practice, and users should be able to configure which alias(es) can be used to login.

aaxdev commented 2 years ago

we don't believe it is a security issue. There are rate limits. It makes absolutely no sense to try and bruteforce it online. There's no real threat model: someone steals your password without stealing your address? I don't think so. -- @charlag

There is a use case in which this is indeed a potential security issue:

  1. a user intentionally only using aliases, to keep the main user name hidden, so only aliases are used for all subscriptions/correspondences.
  2. some website leaks email addresses and hashed passwords, and the hashed passwords are brute-forced.
  3. attacker attempts to sign in with the alias and the cracked password, assuming the user reused the password.

In fact, I believe that keeping the main login secret and only using aliases for comms is best practice, and users should be able to configure which alias(es) can be used to login.

I agree, a toggle button would be required to either allow connection through any alias or only from a chosen one.

From my point of view it's not a real security issue since there's 2FA, but more a privacy one even if having a not know identifier for login increase the requirement to be logged in. Also any attempt to login with aliases can be reported to the main email account to notice that someone tried to connect, it could be very helpful.