[sleepyhead]

We at MakePlans were affected by this breach as we use Twilio. We are not using Twilio Verify (their 2FA api) but rather handle 2FA SMS ourselves in our app using Twilio as one of our providers. So the CCC definition of this being only 2FA-SMS is incorrect, it was all SMS sent through this Twilio third party gateway that was exposed to a limited set of countries (France, Italy, Burkina Faso, Ivory Coast, and Gambia).

GDPR is not necessary applicable here. An SMS gateway is most likely classified as a telecom carrier, and thus any local telco laws would be applicable and not GDPR. That applies only to the transfer of the SMS though, so for example a customer GUI of sent SMS would be out of that scope.

(And before someone tells us that SMS 2FA is insecure I would like to point out that we use this for verification purposes in our booking system when a customer makes a booking. So for end-customers, not for users. It is a chosen strategy for making verification easy as alternatives are too complex for many consumers. All users however authenticate with email and password, and have the option of adding TOTP 2FA).

[slow_typist]

I think 2FA via texts is better than no 2FA. But only if you do not make the texts world readable.

Apart from that, to me it seems justifiable to follow a risk based approach. Booking systems up to a certain value/amount, fine. Online Banking and health related services, thank you, no.

[sleepyhead]

It's not really 2FA even. More like a magic link (which is what we use for verification via email). The customer has no password, just verifies using a code via sms/email.

[slow_typist]

Passwordless, so to speak. Does it help with conversion rates?

[sleepyhead]

It’s for the booking site so most visitors come to make a booking thus conversion rate would be high generally. We never had passwords there so can’t compare conversion rates.

For signups to our app (to get an account with a booking site) we require a password.