Email is a large attack vector for any individual and not having the ability to separate auth by something you own vs something you know makes an easier attack vector. It has become pretty common place within the industry to require it and yet some of the providers are not supporting it.
Just securing the account settings of your profile is a start that these providers should consider.
I use 2 of the ones you listed and what you're saying is not true for any of them.
Confirmation needed mean? Tutanota doesn't require any confirmation.You're suggesting to remove ProtonMail - a provider that does support 2FA and separate passwords for logging in and decrypting, because they don't support 2FA (while they actually do).
"Confirmation needed" is to confirm if they support it in their accounts.
Good to know about proton mail, I quickly checked and it wasn't on!
Tutanota is blocked by some other e-mail providers, as they don't even use a captcha, and therefore is used a lot for spam.
@Shifterovich perhaps a column in the table for 2FA support or advice like "just use for spam" etc.
What do you mean? I was saying that because of absence of any verification, Tutanota is frequently abused. Anyway, I would only add a column "2FA support", as it's undesired for some people, since privacy != security. Removing a provider because they don't support a feature good for security, but bad for privacy makes no sense.
I mean perhaps adding a seperate comments section below each provider on with any comments like you mentioned would help people decide without having to do further research. So Tutanota would have a comment like: "Highly abused service and is blocklisted by many providers, consider using only for throwaway emails".
Sure, however without decent security you likely have no privacy. However a 2FA column is good enough anyway.
Well, it's blacklisted by some and not too abused, still very usable.
2FA is bad for privacy but good for security. We should add 2FA column to the email provider comparison table though. Outright removing these providers is a bad idea (we're a privacy project, not a security project). #144
@Shifterovich
2FA is bad for privacy but good for security.
other than:-
The user must share their personal mobile number with the provider, reducing personal privacy and potentially allowing spam.
https://en.wikipedia.org/wiki/Multi-factor_authentication#Mobile_phone_two-factor_authentication
why is 2FA "bad for privacy"?
Use of an authenticator app gives away nothing:-
https://prism-break.org/en/all/#authentication
@jonathanKingston
Kolab Now does indeed appear not to have 2FA.
A big let down!
however it is on our roadmap
I'm a Kolab Now customer --- but not for much longer.
Two Factor Auth List
https://twofactorauth.org/
2factorauth/twofactorauth: List of sites with two factor auth support which includes SMS, email, phone calls, hardware, and software.
https://github.com/2factorauth/twofactorauth
@Hillside502 Giving away your personal phone number is bad for privacy and anonymity per se.
@Shifterovich
By using an authenticator app, how would one "give away a phone number"?
@Hillside502 I was not talking about authenticator apps, you were. I was answering a question regarding giving away phone number.
Authenticator apps require you to have a device that supports them. I never used any apart from the Google one, but I think the website would have to support them too?
@Shifterovich
Authenticator apps require you to have a device that supports one.
True --- and it's probably true that ALL smartphones are privacy nightmares to one degree or another.
Startmail seems to support 2FA, see https://support.startmail.com/index.php?/Knowledgebase/Article/View/704/0/how-to-set-up-two-factor-authentication-2fa
Startmail seems to support 2FA. See https://support.startmail.com/index.php?/Knowledgebase/Article/View/704/0/how-to-set-up-two-factor-authentication-2fa
Most helpful comment
2FA is bad for privacy but good for security. We should add 2FA column to the email provider comparison table though. Outright removing these providers is a bad idea (we're a privacy project, not a security project). #144