Enhanced SMS 2FA with Domain-Bound Codes

https://developer.apple.com/news/?id=z0i801mg

This is being introduced as part of iOS 14 and MacOS Big Sur

The gist of it is fairly simple. Apple devices (and some other devices) can autofill received 2FA from SMS. In an effort to improve the security of the use of SMS as a second factor and reduce the ability for phishing attempts, domain-bound codes add an additional piece of information so that that code can only be auto filled for the website or app it was meant for.

Ex:

123456 is your Example code.

@example.com #123456

The last line is the new additional data. Not example.com? no code for you.

Personally I think this might be a good improvement (and it looks like Google may agree), SMS isn’t the best for MFA, but SMS is provable better than nothing and highly accessible.

3 Likes

A few problems I see:

  • How do you link an app to a website. Currently, apps can just go ‘yep that website’s links are for me’.
  • If the SMS includes a DBC and the device is compatible with it, don’t allow the user to access the SMS. As LastPass had discussed somewhere, they found that users were copy-pastaing passwords, when the autofill didn’t work (to a phising site). They allow business users to disallow non-autofill logins.
  • How do you determine if the code is for user’s phone, or desktop, or something else. Same point with multiple accounts (where entering the code for the wrong device/account could invalidate it). Probably the best way would be to advertise that a webpage/app is ready to receive a DBC (and the device only forwards the code, if the sms’s device token matches).

SMS is not a great way to do 2FA, but at least a way.

  • Some of the forementioned improvements should be done.
  • The whole protocol encourages stuff to use SMS as the first recommended method.
    For using something like a yubikey, around half of the websites want you to first set up SMS or OTP (where it would fall back to, sometimes you can only choose SMS), then get recovery codes, and then can sometimes add one, sometimes multiple (backup) hardware tokens (you could replace SMS/OTP requirement with just a recovery code, if you have the recovery code anyways).
1 Like

Somewhat related:

Apps are approved (unless you side load junk on andoird), and websites can’t use domains they don’t own.

It’s certainly an issue, and it likely doesn’t stop people manually pasting it in, however I wouldn’t say its a reason not to implement it, its an extra very easy layer of checks that’s essentially zero cost to everyone.

I’m not sure what you mean here? The fact that an SMS sends to your desktop (on Mac) and phone? Its not really an issue, im not sure how often people are logging into sites on two devices at the exact same time (and in fact if they were this would actually improve usability for differing site access), for logging into the sam site, which again seems like a rare use case, its the same as it ws before. you get two codes.

It’s crap.

As far as I can tell, it seems to me that until we have TOTP or similar built-in to the OS of every device then we’re never going to have as easily an accessible solution as SMS. Its ridiculous, OTP apps are easily available, they’re not actually that hard to use, but quite frankly to the average person, they’re a pain, and not user friendly, and not easy to use.

1 Like