4 ms·

I proposed a scenario where it seems to me that SMS-2FA does achieve something. What is wrong with my understanding with how it helps with that scenario? To be

I proposed a scenario where it seems to me that SMS-2FA does achieve something. What is wrong with my understanding with how it helps with that scenario? To be clear, I'm not talking about credential stuffing. I'm talking about my credentials from Foo being used with Foo.

UncleMeat 6y ago
I think this is a somewhat questionable threat model. Some people would say it is reasonable. Other people would say that the service has already been pwned so relying on that breach being exclusively contained to the password database and nothing else, requiring the hackers to actually use the ordinary authentication flow to do anything bad, is a fairy tale. I personally don't feel like I have enough information to decide whether this is a reasonable threat model or not.
- quinndiggity 6y ago
  Defence in depth - too often I hear "whelp, we had a tiny crack in one of our measures, so it's game over, why even try?". Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated. One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere. I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.
- pythonaut_16 6y ago
  Scenarios where someone might have my password but not my SMS: keyloggers, password written down at my desk, video surveillance or shoulder-surfing, audio analysis of keyboard and/or CPU tones[0]. The stronger or less guessable a password is, the more likely it is to be written down or recorded somewhere where it could be compromised. [0]https://en.wikipedia.org/wiki/Acoustic_cryptanalysis https://en.wikipedia.org/wiki/Acoustic_cryptanalysis

UncleMeat 6y ago

I think this is a somewhat questionable threat model. Some people would say it is reasonable. Other people would say that the service has already been pwned so relying on that breach being exclusively contained to the password database and nothing else, requiring the hackers to actually use the ordinary authentication flow to do anything bad, is a fairy tale. I personally don't feel like I have enough information to decide whether this is a reasonable threat model or not.

quinndiggity 6y ago
Defence in depth - too often I hear "whelp, we had a tiny crack in one of our measures, so it's game over, why even try?". Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated. One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere. I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.
pythonaut_16 6y ago
Scenarios where someone might have my password but not my SMS: keyloggers, password written down at my desk, video surveillance or shoulder-surfing, audio analysis of keyboard and/or CPU tones[0]. The stronger or less guessable a password is, the more likely it is to be written down or recorded somewhere where it could be compromised. [0]https://en.wikipedia.org/wiki/Acoustic_cryptanalysis https://en.wikipedia.org/wiki/Acoustic_cryptanalysis