There are ways to use your phone's secure storage capabilities for key storage; this tool isn't leveraging the secure compute capabilities of your phone's SIM in any way. I've dabbled with using Krypt.co [1] for this, though that's sadly been deprecated and will at some point be replaced by a paid-for cloud service from Akamai. I'm sure there are other options available as well.
A far superior method for SSH security would be a physical U2F key or even a smart card. It's also possible to set up TOTP as a second factor ([2], works with any TOTP solution, not just Google Authenticator). I don't see a need for this paid-for third party service unless you're already using their services for some kind of verification mechanism.
[1]: https://krypt.co/
Maybe the next feature could be sending a bombardment of emails every time ssh is used. Subject: WARNING: ssh session "attempt" (msg 1/10). Subject: WARNING: non interactive ssh command rsync blah blah blah (msg 2/10). Subect: Are you sure you wanted to run ssh? (msg 3/10). Subject: We noticed the ssh client isn't running on OSX/Windows, and is therefore insecure (msg 4/10). Subject: Is your SSH up to date? Think about upgrading ssh today (msg 5/10)...
Seriously this "MFA" shit has gotten ridiculous. I don't want to open my email and copypaste crap every time I want to login to a website, and I don't need another email telling me I've logged in "from a new device". Your website is not that important. Yes, yours.
Active SIMCheck USD 0.090
Strong SubscriberCheck USD 0.200
Phone numbers are neither good user identifiers nor viable authentication factors.
That still doesn't make using a phone number a good authentication or identification value, though.
I can think of at least three different ways of performing that kind of authentication (SMS-OTP, leveraging the operator’s metadata about via a HTTP proxy, or actually using the SIM via e.g. EAP-AKA).
Arguably, only the last one would be "using a SIM card", as the title suggests, and neither of them are appealing to me as a user:
Why would I tie authentication to a mobile operator (which aren‘t usually known for stellar security practices) when all new iOS and Android phones support FIDO, both internally and with external authenticators?
The mobile device makes the GET request to that check url over a cellular data request. The MNO verifies the phone number assigned to that sim card making that data request matches phone number used in the creation of that check url.
Also the link at the end for more details, goes to https://developer.tru.id/docs/phone-check/guide which is a 404.
The cost per authentication is high, and even if that weren't a concern, I'd certainly never advocate for a solution that I can't even test since my country isn't on the supported list.
Finally, getting locked out of my servers if your endpoint goes down is a hard pass. I can't really imagine anyone seriously considering implementing this type of access control to servers.
It sounds like it has some features around sim swap protection. I’d be interested in this, but how realiable is it? And what countries does it work in?
Why use this over OTOP via a generator?
It's also taking away the possibilities of the user entering numbers incorrectly (TOTP for example).
Some countries have started introducing rules for certain industries where they're not allowed to switch between apps on a mobile phone. For example when trying to find their Authenticator app or checking their SMS/email for a TOTP.
And finally, it is phishing resistant. You can phish for a users TOTP. You can't with a data connection the mobile device itself has to make over cellular data to the mobile network operator directly.
There is an API specifically for SIM Swap. Or SubscriberCheck does both PhoneCheck and SimSwap together. Further increasing the security of the authentication process for the mobile app.
This is/was used for micropayments for services and app downloads via phone bill, for example.
It would only work over mobile data, though (i.e. users would need to disable wi-fi for every authentication and it would not work without cell signal at all, unlike SMS-OTP or actual SIM authentication).
I think the intended method of using this API is to use apis from within a mobile app to make the request transparently (and ensure mobile data is used to avoid users having to manually disable wifi), but the person in the article is just generating a QR code that you have to scan so I assume you would indeed have to disable wifi by hand each time which would make it more trouble than its worth.
I had no idea mobile network operators were tacking on my phone number to requests though (presumably unsecure http only but still)...
The device makes a GET request to the check url, with a cellular data connection. The mobile network operator is able to verify that the phone number used to create the check URL matches that of the phone number assigned to that SIM Card making the data connection request.
And if SIM Swap is a concern, we also have an API that allows you to first check whether that phone number has recently switched SIM cards before proceeding with the verification.
I was curious how this actually worked but according to Lxgr's reply the network operator adds HTTP headers that allow the phone number to be verified.
