Using your SIM card for MFA when logging in to an SSH server
developer.tru.idUsing your SIM card for MFA when logging in to an SSH server (through paid API requests to a third party)
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/
So in addition to all of the nags websites have created that make logging in painful, now there can be nags to interrupt me in the terminal? Why in the hell would developers ever want this?
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.
Does tru.id work for people using apple’s private relay service or just a VPN in general? If keeping those off is a requirement, I don’t see how this is a significant improvement over existing solutions since some people prefer to not share all their web traffic with TMobile. Webauthn with Face ID on iOS and the equivalent for android seems more compelling.
Instant PhoneCheck USD 0.030
Active SIMCheck USD 0.090
Strong SubscriberCheck USD 0.200
I haven‘t tried it, but I‘m willing to bet that at least one of these would claim that my primary phone number "is not a mobile phone number" (but I use it on a phone), "is not registered in my name" (it is, and how do you claim to know?), or "is a VoIP number, which is insecure and therefore not allowed".
Phone numbers are neither good user identifiers nor viable authentication factors.
We do not verify any of your personal information. We neither have access to that nor store any of it on our system. Our PhoneCheck product simply returns a true or false. Is your phone number tied to this SIM Card. This is information the MNO already has, they know your phone number and your SIM Card. The request is made over a cellular data connection from your device to the MNO
What's the difference between these three tiers of authentication, then? And what makes it different from SMS-OTP (leaving aside SS7 security concerns and focusing on SIM swapping, which I believe is responsible for the majority of successful attacks so far)?
This pricing is outrageous!
It's actually comparable to SMS OTP delivery in most countries. (Only the US and a few other "shared cost" countries offer inbound SMS delivery for sub-cent amounts; in the EU and other "sender pays" countries, mid-single cent amounts are the norm.)
That still doesn't make using a phone number a good authentication or identification value, though.
No, it's not. If you use Twilio, maybe, but there are many other options today, one of them being SignalWire [0]. Another being Plivo [1].
Note that I wrote "most countries other than the US".
Your first reference seems to be US only; the second one lists around 2-10 cent per message to most non-US destinations.
Since this is based on what phone networks charge these service providers and other networks for inbound SMS, anything much cheaper than that is usually using unreliable SIM farms or even more dubious means of message delivery (like hijacked Android smartphones on unlimited messaging plans used without the owner's explicit consent).
Viewed globally, cheap and reliable outbound SMS are a US-specific anomaly.
For thouse countries, typically with lower standards of living, their pricing will be even more prohibitive! There are tricks like callbacks, etc. to deal with expensive texting and many services use those already!
Let's not get into the debate about standards of living in the EU vs. the US, but doesn't all of this outline my original point, i.e. 3-9 cents per authentication being pretty on par with what companies seem to already be willing to pay for two-factor authentication (via SMS-OTP) globally?
In other words, it's an abusive copycat pricing model (if others are thieves, we should be, too). Except there's a lot more infrastructure and personnel behind a text message, so, tru.ID are bigger thieves! Also, the vast difference is that tru.ID requieres an app and SMS does not, so, you should not compare apples to oranges! If you really want your customers to install yet another app, then good luck! In fact, their app is a bit finicky as I installed it and starts with a Java error and then a endless spinner on a blank screen! Not to mention, they have 2 QR codes next to each other for download on their web pages, way too close to each other, and not sure why they don't have a simple device-based redirect with a single QR code, or use another abusive service to do this trivial job if they are not up to the challenge themselves.
Despite what the title suggests, this is not using the SIM and does not involve any kind of cryptographic authentication.
I'd prefer using something like a U2F key that you already have to make your ssh more secure.
What is actually happening here?
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?
One thing that it wasn't clear to me is, the check only verifies that there is an active SIM card, but how is that tie to a person? With one-time-password via SMS, we are not only verifying that the phone number is active but also a specific person (with the registered phone number in their account) have access to the phone. In the first case it is enough to use any phone number as long as it is active.
No, the check url created from the request is made by the mobile network operator assigned to that phone number.
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.
It's very hard to follow the way this builds up a script as it goes, it's unclear what benefit putting it all in one script has, it's really a bunch of scripts.
Also the link at the end for more details, goes to https://developer.tru.id/docs/phone-check/guide which is a 404.
I recently wrote this tutorial to add an extra factor of authentication when logging in to an SSH server, using tru.ID's PhoneCheck, which uses your SIM card and an active data connection to the mobile network operator. Let me know what you think?
From a security perspective, it seems you're only confirming that whoever is trying to log in has access to the phone number - not a specific SIM card. So right away it doesn't appear to offer any benefits over other MFA options out there, and is certainly less secure than some of them.
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.
What are some of the reasons to use tru.ID over sending an sms?
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?
If you were, for example building a mobile application. tru.ID's PhoneCheck is superior to SMS in several ways. The first is, it provides a seamless UX. The user only has to enter their phone number (or your backend may already have this stored?). Then all they see is a couple seconds loading followed by a success or failure.
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.
> It's also taking away the possibilities of the user entering numbers incorrectly (TOTP for example).
Awfully weak.
> 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.
Which countries are these?
> 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.
What if the user is using a VPN?
Sorry, answering to your other questions. We are ever increasing coverage, but currently have quite a number of countries in Europe, most of India covered, Canada is covered. the US is in progress.
Can someone explain how PhoneCheck is able to verify the phone number with the mobile provider using a "mobile data session"?
Some mobile operators can add the phone number or some other user identifier as an HTTP header via a transparent proxy on all requests passing through their network.
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).
Huh... so I guess it's entirely reliant on the mobile operator adding this header then, and it's literally just checking whether the phone number in the header matches?
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)...
Sorry, that was imprecise – as far as I know it's not actually all HTTP requests, but rather only those on a list of URLs that the operator has a contractual agreement with. (I'd like to believe that this does not include advertisement/tracking purposes, or that the identifier is at least hashed for those...)
Regarding an API to bypass Wi-Fi: I think at least on iOS, such a thing does not exist, and on Android I'd be extremely annoyed as well if an app were to possibly incur data and/or roaming charges for this. (I'm not sure whether there is an Android API to send only a specific request over mobile data without impacting other, already existing connections.)
> Sorry, that was imprecise – as far as I know it's not actually all HTTP requests, but rather only those on a list of URLs that the operator has a contractual agreement with. (I'd like to believe that this does not include advertisement/tracking purposes, or that the identifier is at least hashed for those...)
Ah, that makes more sense.
> Regarding an API to bypass Wi-Fi: I think at least on iOS, such a thing does not exist, and on Android I'd be extremely annoyed as well if an app were to possibly incur data and/or roaming charges for this. (I'm not sure whether there is an Android API to send only a specific request over mobile data without impacting other, already existing connections.)
I believe the Andorid ConnectivityManager API allows this. I didn't realize iOS didn't have something similar, although there are probably good reasons not to want apps to be able to do this.
The phone number is used to create the check url. This check url is returned from the mobile network operator that phone number and SIM card belong to.
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.
> 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.
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.