Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Google Voice is, by and large, just* using Bandwidth.com's API to send and receive SMS. The same attacks still work though it is marginally harder to forcibly port or steal a number from a Google Voice account because Bandwidth passes the port auth request onward to Google for approval.

Point being, Google Voice is not a telco on its own. They rent underlying access, of sorts, and that access still relies on SS7.

* For suitably large values of "just."




Do you know if this includes Google Fi as well? From what I can tell, they appear to share much of the same infrastructure. There's even a link to Google Voice at the bottom-left side of the screen of the Google Fi website.


I don't have much knowledge of how Google Fi works but what little I know makes me think that, yes, Fi and Voice are doing the same thing. If they are, then yes, a Fi number is on the exact same footing as a Voice number for port-out shenanigans.

One data point for why Fi and Voice numbers are the same: For a long time, hip-and-trendy apps like Uber and Venmo wouldn't accept Google Voice numbers because they show up in API calls as "voip." About a year after Fi became widespread, Google Voice numbers show up in services that provide information about phone numbers with a carrier of "Bandwidth.com/GV" or similar so now the apps can whitelist that carrier as "yeah it's VoIP but it's fine." If I test the number of someone who I know uses Google Fi--but did use that number with Google Voice before Fi, so I don't know for sure if this is valid--the information returned still comes back as Google Voice.


What about using a service like Twilio to receive texts?


This will not work. A Twilio Number cannot receive messages from a short code. Almost every single two factor authentication code from a bank or other institution comes from a short code. No number you receive or port into Twilio is Classified as a mobile number – so they cannot receive messages from short codes.

I spoke to engineers from Twilio at the 2018 Signal conference and they confirmed - there is no technical limitation, but they would have to do a lot of work and deal with a lot of spam issues if they allowed their numbers to be classified as "mobile" and able to receive SMS from shortcodes - and they are declining to do that for now.

So whether you source a new number from Twilio or port in an existing mobile number, once it hits Twilio it is no longer a mobile number. Yes, you can receive SMS/MMS from "normal" numbers just fine.


I think Twilio is running its own infrastructure so some of the attack risk is mitigated but there's still no prevention of doing things like temporarily rerouting SMS or other things like that through SS7 access.

Point being, SMS-based "authentication" is so laughably insecure as to be pointless if you become a target of someone who wants into your checking account.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: