6 ms·

Overall some good ideas - but I’m curious, why would SMS-based 2FA be LESS secure than no 2FA at all for unsophisticated users? Yes, SIM-jacking is a real thre

by cal5k 8y ago

Overall some good ideas - but I’m curious, why would SMS-based 2FA be LESS secure than no 2FA at all for unsophisticated users? Yes, SIM-jacking is a real threat, but it still requires directed effort on the part of the attacker. It can’t be done en-masse. I think the author also fails to mention techniques for detecting account hijacking - Facebook and google for example both look at IP addresses and user agent strings, probably along with other factors, to detect unusual account activity.

StavrosK 8y ago
> why would SMS-based 2FA be LESS secure than no 2FA at all for unsophisticated users It's not about the user, it's about the attacker. If your account has something worth bothering with, SMS 2FA is a way for an attacker to tell support "yes, I own the phone number, I just forgot the password", which gets the account transferred to the attacker more easily. It's a tradeoff between that and a keylogger meaning game over, but, really, how hard is it to implement TOTP? > I think the author also fails to mention techniques for detecting account hijacking - Facebook and google for example both look at IP addresses and user agent strings, probably along with other factors, to detect unusual account activity. That's a very good point, but those are more high-effort functions and only allow detection after the fact, rather than prevention. They're definitely great to have, but I wanted to show two simple features that can help your users' security greatly while being easy to implement.
- cal5k 8y ago
  What you’re saying about support indicates poor process rather than an issue with SMS per se. All password resets should require email verification... so an attacker would have to either compromise both the email account and the phone number, or the password and the phone number. It’s still not great - U2F is the way to go in my opinion - but good luck getting my dad to use any of that stuff.
  - StavrosK 8y ago
    > good luck getting my dad to use any of that stuff That's exactly the reason for the "poor process", most users have trouble with these things and it's not uncommon for people to say "the email address I signed up with is old and I don't have it any more, but I do have my phone number". So common that support can't just ignore those, unfortunately, which is how attackers get in. That, and support staff are people and sometimes just want to help users, even though you've said "absolutely no password resets without email verification".
    - cal5k 8y ago
      I understand the point of view, but it still smacks of weak process. Support should not be able to do anything other than trigger an email reset link. If they lost the email password, they need to take it up with their email provider. Otherwise a manual process involving ID verification of some type should be required to reset the email or phone number on the account. I’m not saying doing this properly is easy, but I think “don’t use SMS ever” is a bit extreme.
      - StavrosK 8y ago
        This is just offloading the responsibility for security to the email provider. If their security is weaker than yours, you've disadvantaged your users. If you have an easy way to do ID verification, that's great, but that's not always possible.
        jessaustin 8y ago
        Isn't email still the skeleton key? Most popular email providers can be secure enough for many uses. We could imagine e.g. a bank that hands out OTP devices to its high-value customers who bring passports to the bank, but that's overkill for many situations.
      - jschwartzi 8y ago
        Ideally the manual process should require ID verification live and in-person, not over the phone. This raises the bar for an attacker from "has to have access to the Equifax hacked database" to "has to get a decent fake ID made before their appointment with the ID verification people."
- cal5k 8y ago
  Also, if we’re talking about high-security applications, it’s really not enough to focus on authentication. Detecting account hijacking can prevent an attacker from executing some damaging action (transferring money, buying stuff) even though the credentials might be compromised. I think user authentication needs to be a holistic process that looks at a bunch of factors.
- carbocation 8y ago
  > how hard is it to implement TOTP? I've been asking BofA and Merrill for awhile. Apparently for the institutions that control my money, "very."
  - robotdan 8y ago
    If you're a dev, there are a lot of implementations, or code examples online. Here is an open source Java example of some of the algorithm impl, and an HTML / JS example to test out in the browsers. https://github.com/inversoft/prime-two-factor/blob/master/src/main/java/org/primeframework/twofactor/TwoFactor.java https://github.com/inversoft/prime-two-factor/blob/master/sr... https://github.com/inversoft/prime-two-factor/tree/master/web https://github.com/inversoft/prime-two-factor/tree/master/we...
    - carbocation 8y ago
      My comment was made in the hopes that someone can interest financial institutions in real 2FA.
    - tptacek 8y ago
      The expense is in added support, not in software development cost.
- brokenwren 8y ago
  I don't think this is correct for most uses of SMS currently. 2FA (MFA) is on top of password authentication, not to the side of it. If you forget your password, 2FA does nothing to help you out. I think what you are talking about is "SMS password reset", which is a different beast. And it also sounds like you are talking about SMS based identity verification for customer service representatives. If you are only using SMS for identity verification in your CSR workflow, that is a broken workflow. In FusionAuth (https://fusionauth.io https://fusionauth.io), we implemented SMS MFA that only works after the user has successfully put in their password. Therefore, the attacker would need their password and a clone of their phone. While this is still possible, the threat surface is quite small.
  - robotdan 8y ago
    What is FusionAuth? Is this like an Auth0 or something like that?
    - brokenwren 8y ago
      Similar to Auth0, except you can run it anywhere (dev-box, bare-metal, VPS, Docker, etc). It has all the features that most applications need. Plus, it's free for unlimited users.
rzwitserloot 8y ago
Adding a security measure knowing that it is insufficient or is relatively easily circumvented, just because, 'hey, it can't hurt!' is really dangerous. You MUST ensure that ALL involved parties are aware that the secondary measure is a 'bonus' and CANNOT be used to consider the entire system safe. For example, let's say someone calls the helpdesk and says: I forgot my password, but, I can answer the 2FA thing for you. Maybe the helpdesk operator makes a reasonable judgement here: That's pretty good, the party on the other end of the line sounds pretty convincing, okay, I'll reset their password for them. Whoops: Now JUST a SIM jack gets you in, whereas if there was no SIM based 2FA whatsoever, the helpdesker wouldn't have reset the password. Another example: During a security audit, some pentester figures out that there is no rate limit on trying passwords, there are no logs or any other detection for figuring out that some system is trying a ton of passwords, and a password check is very fast (let's say no bcrypt or similar system in place either) and the server is hosted in a virtual datacenter, and it is not too difficult to spool up a (virtual) server in the same place: That would allow an attacker (because latency has now been reduced to next to nothing) to have guessed many billions of passwords over the past 6 months. The team analyses this potential leak and concludes that, due to the existence of the secondary system, there's really no need to go public or otherwise spend any further resources. However, you don't even need to be all that capable or motivated to do a targeted attack here; SIM jacking is easy enough, and getting a server under your control that is latency-wise extremely close to the target is pretty easy for, say, AWS ec2 servers. Had the 2FA not been there, this issue would have received more appropriate attention. Generally, I advise to never add a security feature just because 'hey, can't hurt': It confuses the authentication pipeline and muddies discussion and understanding. Either a feature is adding real security, and any circumvention of said security is definitely something that should be escalated, or, it's useless and should not be added. With that mindset, I'd prefer to just get rid of SMS based 2FA vs. keeping it around (I'd _strongly_ prefer to fix it and make it 2FA that isn't sim-jackable, for example by using TOTP protocol, but let's hypothetically posit that that's somehow not an option).
chayesfss 8y ago
It's more secure than single factor no doubt...
jwr 8y ago
Other good replies in this thread — I will just add some examples of why SMS-based 2FA is less secure than pretty much any other 2FA method. Example 1: at a first approximation, 100% people have their phones set to display the content of SMS messages even if the phone is locked. So gaining the physical possession of a phone (even for a brief time) allows the attacker to gain access. Example 2: taking out a SIM from a modern phone takes less than 10 seconds. Again, at a first approximation, 100% people have no PIN on their SIM cards. The card can be inserted into another phone and used to gain access immediately. Note that while you might notice that your phone is missing, you might not immediately notice that your SIM is missing. I'm not even considering other (more complex) ways of redirecting SMS messages. And what I hate most are services which allow you to use SMS or a phone number to recover/unblock your account. That makes it so much easier for attackers go gain access. The only way to recover your account should be with recovery codes. If you lose those, there should be no way to recover.

by cal5k 8y ago

StavrosK 8y ago

> why would SMS-based 2FA be LESS secure than no 2FA at all for unsophisticated users It's not about the user, it's about the attacker. If your account has something worth bothering with, SMS 2FA is a way for an attacker to tell support "yes, I own the phone number, I just forgot the password", which gets the account transferred to the attacker more easily. It's a tradeoff between that and a keylogger meaning game over, but, really, how hard is it to implement TOTP? > I think the author also fails to mention techniques for detecting account hijacking - Facebook and google for example both look at IP addresses and user agent strings, probably along with other factors, to detect unusual account activity. That's a very good point, but those are more high-effort functions and only allow detection after the fact, rather than prevention. They're definitely great to have, but I wanted to show two simple features that can help your users' security greatly while being easy to implement.

cal5k 8y ago
What you’re saying about support indicates poor process rather than an issue with SMS per se. All password resets should require email verification... so an attacker would have to either compromise both the email account and the phone number, or the password and the phone number. It’s still not great - U2F is the way to go in my opinion - but good luck getting my dad to use any of that stuff.
- StavrosK 8y ago
  > good luck getting my dad to use any of that stuff That's exactly the reason for the "poor process", most users have trouble with these things and it's not uncommon for people to say "the email address I signed up with is old and I don't have it any more, but I do have my phone number". So common that support can't just ignore those, unfortunately, which is how attackers get in. That, and support staff are people and sometimes just want to help users, even though you've said "absolutely no password resets without email verification".
  - cal5k 8y ago
    I understand the point of view, but it still smacks of weak process. Support should not be able to do anything other than trigger an email reset link. If they lost the email password, they need to take it up with their email provider. Otherwise a manual process involving ID verification of some type should be required to reset the email or phone number on the account. I’m not saying doing this properly is easy, but I think “don’t use SMS ever” is a bit extreme.
    - StavrosK 8y ago
      This is just offloading the responsibility for security to the email provider. If their security is weaker than yours, you've disadvantaged your users. If you have an easy way to do ID verification, that's great, but that's not always possible.
      - jessaustin 8y ago
        Isn't email still the skeleton key? Most popular email providers can be secure enough for many uses. We could imagine e.g. a bank that hands out OTP devices to its high-value customers who bring passports to the bank, but that's overkill for many situations.
    - jschwartzi 8y ago
      Ideally the manual process should require ID verification live and in-person, not over the phone. This raises the bar for an attacker from "has to have access to the Equifax hacked database" to "has to get a decent fake ID made before their appointment with the ID verification people."
cal5k 8y ago
Also, if we’re talking about high-security applications, it’s really not enough to focus on authentication. Detecting account hijacking can prevent an attacker from executing some damaging action (transferring money, buying stuff) even though the credentials might be compromised. I think user authentication needs to be a holistic process that looks at a bunch of factors.
carbocation 8y ago
> how hard is it to implement TOTP? I've been asking BofA and Merrill for awhile. Apparently for the institutions that control my money, "very."
- robotdan 8y ago
  If you're a dev, there are a lot of implementations, or code examples online. Here is an open source Java example of some of the algorithm impl, and an HTML / JS example to test out in the browsers. https://github.com/inversoft/prime-two-factor/blob/master/src/main/java/org/primeframework/twofactor/TwoFactor.java https://github.com/inversoft/prime-two-factor/blob/master/sr... https://github.com/inversoft/prime-two-factor/tree/master/web https://github.com/inversoft/prime-two-factor/tree/master/we...
  - carbocation 8y ago
    My comment was made in the hopes that someone can interest financial institutions in real 2FA.
  - tptacek 8y ago
    The expense is in added support, not in software development cost.
brokenwren 8y ago
I don't think this is correct for most uses of SMS currently. 2FA (MFA) is on top of password authentication, not to the side of it. If you forget your password, 2FA does nothing to help you out. I think what you are talking about is "SMS password reset", which is a different beast. And it also sounds like you are talking about SMS based identity verification for customer service representatives. If you are only using SMS for identity verification in your CSR workflow, that is a broken workflow. In FusionAuth (https://fusionauth.io https://fusionauth.io), we implemented SMS MFA that only works after the user has successfully put in their password. Therefore, the attacker would need their password and a clone of their phone. While this is still possible, the threat surface is quite small.
- robotdan 8y ago
  What is FusionAuth? Is this like an Auth0 or something like that?
  - brokenwren 8y ago
    Similar to Auth0, except you can run it anywhere (dev-box, bare-metal, VPS, Docker, etc). It has all the features that most applications need. Plus, it's free for unlimited users.

rzwitserloot 8y ago

Adding a security measure knowing that it is insufficient or is relatively easily circumvented, just because, 'hey, it can't hurt!' is really dangerous. You MUST ensure that ALL involved parties are aware that the secondary measure is a 'bonus' and CANNOT be used to consider the entire system safe. For example, let's say someone calls the helpdesk and says: I forgot my password, but, I can answer the 2FA thing for you. Maybe the helpdesk operator makes a reasonable judgement here: That's pretty good, the party on the other end of the line sounds pretty convincing, okay, I'll reset their password for them. Whoops: Now JUST a SIM jack gets you in, whereas if there was no SIM based 2FA whatsoever, the helpdesker wouldn't have reset the password. Another example: During a security audit, some pentester figures out that there is no rate limit on trying passwords, there are no logs or any other detection for figuring out that some system is trying a ton of passwords, and a password check is very fast (let's say no bcrypt or similar system in place either) and the server is hosted in a virtual datacenter, and it is not too difficult to spool up a (virtual) server in the same place: That would allow an attacker (because latency has now been reduced to next to nothing) to have guessed many billions of passwords over the past 6 months. The team analyses this potential leak and concludes that, due to the existence of the secondary system, there's really no need to go public or otherwise spend any further resources. However, you don't even need to be all that capable or motivated to do a targeted attack here; SIM jacking is easy enough, and getting a server under your control that is latency-wise extremely close to the target is pretty easy for, say, AWS ec2 servers. Had the 2FA not been there, this issue would have received more appropriate attention. Generally, I advise to never add a security feature just because 'hey, can't hurt': It confuses the authentication pipeline and muddies discussion and understanding. Either a feature is adding real security, and any circumvention of said security is definitely something that should be escalated, or, it's useless and should not be added. With that mindset, I'd prefer to just get rid of SMS based 2FA vs. keeping it around (I'd _strongly_ prefer to fix it and make it 2FA that isn't sim-jackable, for example by using TOTP protocol, but let's hypothetically posit that that's somehow not an option).

chayesfss 8y ago

It's more secure than single factor no doubt...

jwr 8y ago

Other good replies in this thread — I will just add some examples of why SMS-based 2FA is less secure than pretty much any other 2FA method. Example 1: at a first approximation, 100% people have their phones set to display the content of SMS messages even if the phone is locked. So gaining the physical possession of a phone (even for a brief time) allows the attacker to gain access. Example 2: taking out a SIM from a modern phone takes less than 10 seconds. Again, at a first approximation, 100% people have no PIN on their SIM cards. The card can be inserted into another phone and used to gain access immediately. Note that while you might notice that your phone is missing, you might not immediately notice that your SIM is missing. I'm not even considering other (more complex) ways of redirecting SMS messages. And what I hate most are services which allow you to use SMS or a phone number to recover/unblock your account. That makes it so much easier for attackers go gain access. The only way to recover your account should be with recovery codes. If you lose those, there should be no way to recover.