10 ms·

With app- or token-based 2FA, there is no token sent across the wire until the user submits an auth request. With SMS-based 2FA, the token is sent via insecure

With app- or token-based 2FA, there is no token sent across the wire until the user submits an auth request. With SMS-based 2FA, the token is sent via insecure channels to the user BEFORE auth, which is an opportunity for state actors and telecom to intercept it before use.

nkozyra 12y ago
Right, I'm pretty sure we're taking about SMS-based (or perhaps email-based). Even in cases where that token is intercepted, it's a one-time use token, so you know if it's been intercepted.
- acqq 12y ago
  If somebody can MTM both SMS and your internet connection, you wouldn't know a thing. That one use would be done by the MTM and not you and thanks to the MTM everything would appear normal to you. (MTM is not only the "man in the middle" but also "the machine in the middle" -- a computer which would react in real time.)
  - nkozyra 12y ago
    Yes, you would know, because the token exists to establish a password and an active connection. If someone MTM the 2nd part of a 2FA, you won't be able to log into your account. MTM your internet connection means whatever the service is you have to replicate exactly, which is not feasible at any scale.
    - acqq 12y ago
      MTM is the point where your active connection ends. It uses the token to connect with the server (which it knows since it MTMs the SMS too), you comunicate with it, seeing the copy of what MTM receives. You don't see anything strange. It's not that hard to implement.
      - nkozyra 12y ago
        Again, this is confusing the MTM attack we're (and most people are) talking about in general with the 2FA mechanism we're specifically talking about here. They're two entirely different vectors. If you wanted to hijack a token as part of a 2FA, that serves the purposes of initializing an account. In this case, the second MTM (intercepting communications) will not work, because the user will be unable to log in (as you initialized their account and therefor had to set a password). Further, in the traditional MTM attack, there's no need to steal that 2FA token in the first place - not only because it prevents an active, working account, but because you can already get the information you want through data interception.
        acqq 12y ago
        > In this case, the second MTM (intercepting communications) will not work, because the user will be unable to log in (as you initialized their account and therefor had to set a password). OK, once again: both SMS and internet are MTMed. Now why can't the machine doing the internet MTM use the user's password? Why do you think it has to do that before the user inputs it?
        nkozyra 12y ago
        What you're describing is so inordinately complicated that it really could only be used for specific targeting. Meanwhile it's so redundant it would be a waste of everyone's time. In this case, we're talking about a MTM on SMS and Internet. When a token is sent via SMS, we intercept that and use it to initialize an account (this is totally superfluous since we already have the MTM on the Internet, but for the sake of this argument, let's go with it). Now when a user logs in, we know our generated password, so we need to eschew user input and supplant it with the password we generated by intercepting the 2FA, then return the response as expected. You can sort of understand what I'm saying here. If you have MTM on the network side, you don't need to bother on the SMS side, it provides no advantage. Meanwhile, if you have MTM solely on the SMS side, there's no way to do this without alerting a user, because they will be unable to log in anyway.
- GauntletWizard 12y ago
  Those tokens are rarely actually one-time-use; They're more commonly time-limited (and you still have cache invalidation problems even if they're supposed to be one-time). Further, they fail to deliver so often that it's not hard to intercept one and use it, forcing the user to retry.
  - nkozyra 12y ago
    That's interesting because most of the ones I've seen work like this: - user created, 2FA token created, user not active - user gets 2FA token via 2nd channel - user enters token, gets to create a password for account - user active, token invalidated this isn't airtight - nothing is - but it means either you got the token or you can't log in to your account, which should raise a red flag.

nkozyra 12y ago

Right, I'm pretty sure we're taking about SMS-based (or perhaps email-based). Even in cases where that token is intercepted, it's a one-time use token, so you know if it's been intercepted.

acqq 12y ago
If somebody can MTM both SMS and your internet connection, you wouldn't know a thing. That one use would be done by the MTM and not you and thanks to the MTM everything would appear normal to you. (MTM is not only the "man in the middle" but also "the machine in the middle" -- a computer which would react in real time.)
- nkozyra 12y ago
  Yes, you would know, because the token exists to establish a password and an active connection. If someone MTM the 2nd part of a 2FA, you won't be able to log into your account. MTM your internet connection means whatever the service is you have to replicate exactly, which is not feasible at any scale.
  - acqq 12y ago
    MTM is the point where your active connection ends. It uses the token to connect with the server (which it knows since it MTMs the SMS too), you comunicate with it, seeing the copy of what MTM receives. You don't see anything strange. It's not that hard to implement.
    - nkozyra 12y ago
      Again, this is confusing the MTM attack we're (and most people are) talking about in general with the 2FA mechanism we're specifically talking about here. They're two entirely different vectors. If you wanted to hijack a token as part of a 2FA, that serves the purposes of initializing an account. In this case, the second MTM (intercepting communications) will not work, because the user will be unable to log in (as you initialized their account and therefor had to set a password). Further, in the traditional MTM attack, there's no need to steal that 2FA token in the first place - not only because it prevents an active, working account, but because you can already get the information you want through data interception.
      - acqq 12y ago
        > In this case, the second MTM (intercepting communications) will not work, because the user will be unable to log in (as you initialized their account and therefor had to set a password). OK, once again: both SMS and internet are MTMed. Now why can't the machine doing the internet MTM use the user's password? Why do you think it has to do that before the user inputs it?
        nkozyra 12y ago
        What you're describing is so inordinately complicated that it really could only be used for specific targeting. Meanwhile it's so redundant it would be a waste of everyone's time. In this case, we're talking about a MTM on SMS and Internet. When a token is sent via SMS, we intercept that and use it to initialize an account (this is totally superfluous since we already have the MTM on the Internet, but for the sake of this argument, let's go with it). Now when a user logs in, we know our generated password, so we need to eschew user input and supplant it with the password we generated by intercepting the 2FA, then return the response as expected. You can sort of understand what I'm saying here. If you have MTM on the network side, you don't need to bother on the SMS side, it provides no advantage. Meanwhile, if you have MTM solely on the SMS side, there's no way to do this without alerting a user, because they will be unable to log in anyway.
GauntletWizard 12y ago
Those tokens are rarely actually one-time-use; They're more commonly time-limited (and you still have cache invalidation problems even if they're supposed to be one-time). Further, they fail to deliver so often that it's not hard to intercept one and use it, forcing the user to retry.
- nkozyra 12y ago
  That's interesting because most of the ones I've seen work like this: - user created, 2FA token created, user not active - user gets 2FA token via 2nd channel - user enters token, gets to create a password for account - user active, token invalidated this isn't airtight - nothing is - but it means either you got the token or you can't log in to your account, which should raise a red flag.