Oh boy another plug for 2FA. I won't deny the obvious security advantages it confers, but that well has been poisoned a long time ago.
Call me paranoid, but I have a hard time seeing the push for 2FA as anything other than a plot to collect valuable user data. As with most any good lie, it's mostly true -- 2FA does improve security -- but what happens when a company goes bankrupt and sells off it's assets?
Moreover, I can't help but to question the actual necessity of this security feature. The OP's mess could have been avoided if he'd ... you know ... systematically chosen secure passwords.
Call me paranoid, but I have a hard time seeing the push for 2FA as anything other than a plot to collect valuable user data
Exactly. Mostly when I see companies like Google, Facebook, etc constantly trying to trick me to activate it. And yes, I say trick: The option to ignore/skip is always hidden/disguised, totally ignoring the UX and accessibility needs.
This and the fact that the input text fields already have my phone number populated on them ...and are just waiting for my consent.. this does not inspire trust, no.
Another interesting thing most people don't realize is that if you switch IP addresses Google demands a phone number for Gmail login, even if the account has no 2FA and no phone number was specified initially. "Give us some phone number to log in". Isn't that strange from security perspective?
2FA doesn't automatically require giving any user data. Using SMS-based 2FA requires giving over your mobile phone number, but it's not like that's the only option available to you. TOTP gives the provider absolutely nothing, and has the added benefit of not being able to be compromised by a call to your mobile phone network or SIM cloning.
You make this sound like it's part of a conspiracy to force 2FA on the unsuspecting masses so that the Illuminati can sell your contact details to aliens from Mars, or something. That's a bit insulting to the original poster, who is sharing useful information learned through real world experience.
The OP's mess could have been avoided if he'd ... you know ... systematically chosen secure passwords.
In this exact scenario that is true but in general, not necessarily. He could of had a very secure password on his dns provider but through some other method that account could still have been compromised (social engineering, sql injection, poor brute force rate limiting, some other attack vector). And then once the dns account is compromised a password reset on github is trivial if there isn't 2FA on the github account - or any other account linked to that email account.
I can make the same argument for 2FA: social engineering can defeat it, or I can turn to some other attack vector.
This isn't to say that 2FA doesn't add security. The point is rather twofold:
1. with a little extra attention, I can secure my system without 2FA and achieve comparable security
2. it's absolutely scandalous that the proverbial well has been poisoned and we are, by virtue of the fact that extra attention is required and that most people won't put in the work, in a less secure state. Again, this is due to the irresponsible data-policy of the overwhelming majority of service providers.
So again: 2FA is a valid security layer, but I'll pass. :/
with a little extra attention, I can secure my system without 2FA and achieve comparable security
How? Lets play devils advocate here and pretend your email is compromised (account takeover or redirect). What have you done on any of the services you use that has given you comparable security to enabling 2FA on them that now prevents the attacker from resetting your password?
By hardening your email server. Yes, assuming the email server is compromised implies a compromised system in this scenario, but that is tautological and therefore uninteresting.
The extra attention should go towards hardening the weak link, in this case the email server that, de facto, provides authentication services.
Server hardening is a vast topic, so I leave it as an exercise for the reader to research what can be done. Surely you don't deny that "a little extra attention" to server configuration can provide additional security without necessarily resorting to 2FA?
But again, 2FA is valid security, so why not host it yourself? I have nothing against 2FA in principle, but I don't trust Google, Github, Facebook et al with my phone number.
So you're running your own DNS server then too right? A hardened email server doesn't prevent a targeted attacker from just redirecting your mx records (as happened to OP).
but I don't trust Google, Github, Facebook et al with my phone number
Github doesn't require a phone number to use 2FA.
And if you don't trust Google or Facebook with your phone number then that means you don't use either of them at all? Because otherwise holding back your phone number from them is a rather pointless exercise as they already know everything about you [1]
And if you don't trust Google or Facebook with your phone number then that means you don't use either of them at all?
More or less. Email I can handle, and there's stuff I stupidly gave up in the past, but I see no reason to provide them with additional info.
Github doesn't require a phone number to use 2FA
Are you referring to the application? That might be a fair compromise depending on what kinds of permissions the application requires.
A hardened email server doesn't prevent a targeted attacker from just redirecting your mx records (as happened to OP).
What on earth are you on about? Of course it does. The OP had a crappy password, which is about as fundamental as it gets with regards to server hardening...
If you don't understand the different types of 2FA available, I don't think you're really in a position to be making blanket statements about if people should be using it or not.
"The application" is an open standard called TOTP, which doesn't require any specific application. I just set up 2FA for my personal GitHub account using a TOTP app on my Pebble watch. The actual crypto for the 2FA is done locally on the watch, no other device can spoof it, and GitHub get exactly zero feedback or information from this - other than the 2FA code that I type, of course.
There's other ways to do 2FA - U2F is an upcoming standard and people have been using dongle-generated codes from RSA for years.
Before making pronouncements that go against current best practices for end users, you really need to get a much better understanding of what you're talking about. Saying nonsense in a confidence voice is enough to convince people that your terrible advice is worth following, and could result in them having worse information security as a result.
You can have the most secure/hardened email server on the planet but if I can change your mx record at your dns provider it will do you no good. And there are multiple attacks against DNS that don't require me to target your provider even (e.g. https://en.wikipedia.org/wiki/DNS_spoofing)
And once all your emails are being sent to me, I can own every account you've signed up for using that email (through reset password). And currently the only reliable defence against that is 2FA.
Having a hardened email server and good passwords does nothing for your security if the attacker targets and takes over either:
* Your DNS Records - MX records point to your email server, the attacker just changes the record to point to their email server, taking your hardened email server out of the loop.
* Your Domain Registrar - the attacker can just change your DNS records to point to their own DNS servers (with their own MX records pointing to their own email server).
Do you trust your DNS provider is completely secure from hacking and social engineering?
Do you trust your Domain registrar to adequately secure their systems from hacking and social engineering? Remember, you only pay them ~$10/year for your domain.
In theory, if the receiving end enforces TLS and if the sending end checks that the certificate is valid for the domain, you don't need to trust the DNS or the registrar. But nobody does that, and you still have to trust the sender.
I'm beginning to think that a possible solution is to use an email account entirely different from your primary email for all website registrations.
Which leads me to another idea. If websites supported separate email accounts for messaging and authentiaction/resets and kept the second account name hidden from general public it would (somewhat) help in a lot of cases.
Also, I would be much more likely to do 2FA on more accounts if websites gave me the option to use printed lists of tokens instead of my phone number.
Comments
Oh boy another plug for 2FA. I won't deny the obvious security advantages it confers, but that well has been poisoned a long time ago.
Call me paranoid, but I have a hard time seeing the push for 2FA as anything other than a plot to collect valuable user data. As with most any good lie, it's mostly true -- 2FA does improve security -- but what happens when a company goes bankrupt and sells off it's assets?
Moreover, I can't help but to question the actual necessity of this security feature. The OP's mess could have been avoided if he'd ... you know ... systematically chosen secure passwords.
I'll pass, thanks.
P.S.: thanks for Requests!
Call me paranoid, but I have a hard time seeing the push for 2FA as anything other than a plot to collect valuable user data
Exactly. Mostly when I see companies like Google, Facebook, etc constantly trying to trick me to activate it. And yes, I say trick: The option to ignore/skip is always hidden/disguised, totally ignoring the UX and accessibility needs.
This and the fact that the input text fields already have my phone number populated on them ...and are just waiting for my consent.. this does not inspire trust, no.
Another interesting thing most people don't realize is that if you switch IP addresses Google demands a phone number for Gmail login, even if the account has no 2FA and no phone number was specified initially. "Give us some phone number to log in". Isn't that strange from security perspective?
Exactly: the dark-pattern design speaks to the true motivation behind this push... and it ain't security.
2FA doesn't automatically require giving any user data. Using SMS-based 2FA requires giving over your mobile phone number, but it's not like that's the only option available to you. TOTP gives the provider absolutely nothing, and has the added benefit of not being able to be compromised by a call to your mobile phone network or SIM cloning.
You make this sound like it's part of a conspiracy to force 2FA on the unsuspecting masses so that the Illuminati can sell your contact details to aliens from Mars, or something. That's a bit insulting to the original poster, who is sharing useful information learned through real world experience.
A lot of the time, though, it really is. I always prefer TOTP over SMS, but it's rare to be given the option.
In this exact scenario that is true but in general, not necessarily. He could of had a very secure password on his dns provider but through some other method that account could still have been compromised (social engineering, sql injection, poor brute force rate limiting, some other attack vector). And then once the dns account is compromised a password reset on github is trivial if there isn't 2FA on the github account - or any other account linked to that email account.
I can make the same argument for 2FA: social engineering can defeat it, or I can turn to some other attack vector.
This isn't to say that 2FA doesn't add security. The point is rather twofold:
1. with a little extra attention, I can secure my system without 2FA and achieve comparable security
2. it's absolutely scandalous that the proverbial well has been poisoned and we are, by virtue of the fact that extra attention is required and that most people won't put in the work, in a less secure state. Again, this is due to the irresponsible data-policy of the overwhelming majority of service providers.
So again: 2FA is a valid security layer, but I'll pass. :/
How? Lets play devils advocate here and pretend your email is compromised (account takeover or redirect). What have you done on any of the services you use that has given you comparable security to enabling 2FA on them that now prevents the attacker from resetting your password?
By hardening your email server. Yes, assuming the email server is compromised implies a compromised system in this scenario, but that is tautological and therefore uninteresting.
The extra attention should go towards hardening the weak link, in this case the email server that, de facto, provides authentication services.
Server hardening is a vast topic, so I leave it as an exercise for the reader to research what can be done. Surely you don't deny that "a little extra attention" to server configuration can provide additional security without necessarily resorting to 2FA?
But again, 2FA is valid security, so why not host it yourself? I have nothing against 2FA in principle, but I don't trust Google, Github, Facebook et al with my phone number.
While we're on the subject, the inherent insecurity of the SMS protocol should also be weighed in any serious endorsement of phone-based 2FA: http://www.itnews.com.au/news/telcos-declare-sms-unsafe-for-...
So you're running your own DNS server then too right? A hardened email server doesn't prevent a targeted attacker from just redirecting your mx records (as happened to OP).
Github doesn't require a phone number to use 2FA. And if you don't trust Google or Facebook with your phone number then that means you don't use either of them at all? Because otherwise holding back your phone number from them is a rather pointless exercise as they already know everything about you [1]
[1] https://en.wikipedia.org/wiki/AOL_search_data_leak
I'm assuming a setup similar to that of the OP's.
More or less. Email I can handle, and there's stuff I stupidly gave up in the past, but I see no reason to provide them with additional info.
Are you referring to the application? That might be a fair compromise depending on what kinds of permissions the application requires.
What on earth are you on about? Of course it does. The OP had a crappy password, which is about as fundamental as it gets with regards to server hardening...
If you don't understand the different types of 2FA available, I don't think you're really in a position to be making blanket statements about if people should be using it or not.
"The application" is an open standard called TOTP, which doesn't require any specific application. I just set up 2FA for my personal GitHub account using a TOTP app on my Pebble watch. The actual crypto for the 2FA is done locally on the watch, no other device can spoof it, and GitHub get exactly zero feedback or information from this - other than the 2FA code that I type, of course.
There's other ways to do 2FA - U2F is an upcoming standard and people have been using dongle-generated codes from RSA for years.
Before making pronouncements that go against current best practices for end users, you really need to get a much better understanding of what you're talking about. Saying nonsense in a confidence voice is enough to convince people that your terrible advice is worth following, and could result in them having worse information security as a result.
You can have the most secure/hardened email server on the planet but if I can change your mx record at your dns provider it will do you no good. And there are multiple attacks against DNS that don't require me to target your provider even (e.g. https://en.wikipedia.org/wiki/DNS_spoofing)
And once all your emails are being sent to me, I can own every account you've signed up for using that email (through reset password). And currently the only reliable defence against that is 2FA.
Having a hardened email server and good passwords does nothing for your security if the attacker targets and takes over either:
* Your DNS Records - MX records point to your email server, the attacker just changes the record to point to their email server, taking your hardened email server out of the loop.
* Your Domain Registrar - the attacker can just change your DNS records to point to their own DNS servers (with their own MX records pointing to their own email server).
Do you trust your DNS provider is completely secure from hacking and social engineering?
Do you trust your Domain registrar to adequately secure their systems from hacking and social engineering? Remember, you only pay them ~$10/year for your domain.
In theory, if the receiving end enforces TLS and if the sending end checks that the certificate is valid for the domain, you don't need to trust the DNS or the registrar. But nobody does that, and you still have to trust the sender.
I'm beginning to think that a possible solution is to use an email account entirely different from your primary email for all website registrations.
Which leads me to another idea. If websites supported separate email accounts for messaging and authentiaction/resets and kept the second account name hidden from general public it would (somewhat) help in a lot of cases.
Also, I would be much more likely to do 2FA on more accounts if websites gave me the option to use printed lists of tokens instead of my phone number.
Umm what valuable data exactly does TOTP (which for example Github uses) give the companies?