api access is insecure - use sip

[carchrae]

first; i want to say thank you to @michaelkourlas for developing and maintaining this app. and i also believe you have been as responsible as you could be by making this code open source. and above all, please know that i very much appreciate your totally free contribution to the world! you spent time to fix something for everyone. kudos to you!

however, entering an api key to a third party for voip.ms is a terribly insecure thing to do. because the api doesn't have granular access, it could be terribly misused. while i would like to believe that you are not evil (and i don't think you are), how you practice security should be paranoid. using the api someone could record your calls, create new phone numbers, and on and on.

i see two options here, and i think only 1) is practical.

1) you add sufficient disclaimers and warnings about the risks of the access you are requesting and how you are mitigating against their api key becoming public (for all i know it is unhashed in a database - but maybe it is stored locally on my phone, and again, how secure is the storage). perhaps you do some of this, but i don't think any non-developers really understand the access that is being requested. at that point, you should probably point out the more secure alternatives.

2) convert the app to SIP SMS. unless voip.ms produce a granular API for SMS (per DID), this is the best/right thing to do, but it is probably not practical as it likely a huge change to the app. but maybe i am wrong, and it would not be too bad to use SIP instead of the voip.ms API. furthermore, since there are already apps that do this it may not be worthwhile to make yet another app. it is not clear to me if these alternatives are terrible - your app is great as it is very focused in its use - i'd love it if i didn't feel uneasy about the api access.

[carchrae]

my conversation w/ voip.ms support on the alternatives to full api access.

12:20:49 PM [Tom Carchrae] i am using the sms android app, but don't want the api to have full access to all dids/etc. aside from creating a whole new voip.ms account, can i have a restricted api for a subaccount? it doesn't appear that reseller supports the api. 12:21:06 PM [Fred] Hello Tim, good afternoon. 12:21:37 PM [Tom Carchrae] hi. i'm pretty sure the answer to my question is no, but i thought i would ask 12:22:41 PM [Fred] Well, there are other options to receive and send SMS currently, for security matter we don't recommend to use that app since it is through API 12:22:54 PM [Fred] However, what you ask is not possible at the moment. 12:23:13 PM [Tom Carchrae] yeah, it seems super dubious to give full api access to an android developer 12:23:19 PM [Fred] Indeed. 12:23:22 PM [Tom Carchrae] that said, he seems legit, but you never know! 12:23:33 PM [Fred] That's optional and responsibility of the customer 12:23:43 PM [Fred] Correct. 12:23:52 PM [Fred] You can try app like Zoiper, Bria, which support SMS. 12:24:01 PM [Tom Carchrae] yes, this is via SIP SMS? 12:24:04 PM [Fred] But you can use any other app that support SIP/IAX Protocols and also SMS 12:24:10 PM [Fred] Yes via sip sms 12:24:11 PM [Tom Carchrae] that sounds like the right way to do it. not via the api 12:24:17 PM [Fred] Correct. 12:24:38 PM [Fred] that was kind of a workaround when we didn't support the SMS through SIÑ 12:24:39 PM [Tom Carchrae] ok, thank you for confirming my thoughts/fears. :D and what the right way to do it is 12:24:49 PM [Fred] SIP* 12:25:05 PM [Fred] You are very welcome Tom. 12:25:18 PM [Tom Carchrae] thanks very much. 12:25:21 PM [Fred] May I assist you with anything else? 12:25:34 PM [Tom Carchrae] btw, do you mind if i post this chat log in the developers github issues? 12:25:51 PM [Fred] No problem Sir. 12:26:06 PM [Tom Carchrae] thanks. maybe it will save you having to have this conversation again. 12:26:19 PM [Fred] Sounds good! 12:26:25 PM [Tom Carchrae] thanks. and bye for now. 12:26:31 PM [Fred] Thank you for chatting with us today. By clicking the ≡ icon you'll be able to END and request a transcript of this chat and provide feedback on the level of service provided. Additionally, you can send any feedback to our email address fe........ms . Have a nice day!

[michaelkourlas]

It's unlikely this app will support SIP SMS, in part because it's a lot of work, but mostly because SIP isn't as fully featured as the API. For example, I don't think you can retrieve old messages using SIP. Nor can you delete messages from the VoIP.ms SMS Message Centre.

For reference, your API password doesn't leave the device (except when accessing VoIP.ms) though it could probably be stored more securely; right now it is stored unencrypted in the application's preferences. I think Android allows apps to provision "accounts" in a secure way -- I'll create an issue to look into that.

The correct solution here is for VoIP.ms to properly support OAuth or a similar authentication solution for their API which will allow the kind of granular control that you want. Until they do that, there's not a whole lot I can do.

Incidentally, I find it interesting that VoIP.ms doesn't recommend the use of my app for security reasons, given that one of their VPs contacted me last year about creating a version of my app for iOS!

[michaelkourlas]

If you're paranoid, I suggest using the F-Droid version of the app, which they build themselves using the source I provide.

But if you want FCM support (and therefore push notifications), I'm afraid you're stuck trusting me...

[carchrae]

thanks @michaelkourlas for the explanations.

i agree that it would be great if voip.ms provided a better api/auth mechanism that was restricted to this use. even an SMS api key per DID with a restricted set of api paths would be better. i cannot imagine there are many different api calls for SMS (get messages, send message, set callbackurl...) to create a restricted api (even if is simple and not full oauth/scopes). (LATER: 5 calls https://github.com/michaelkourlas/voipms-sms-client/search?q=rest.php&unscoped_q=rest.php )

i did check the code after and saw that you were storing the key in applicationContext rather than fetching it remotely. of course, i don't know for certain (aside than what you say) that it isn't passed off to api calls, eg what code sets the callbackUrl (presumably to support push) (LATER: i checked, and you are executing them locally - obviously would take me a longer time to verify it isn't being sent, but nothing obvious)

Incidentally, I find it interesting that VoIP.ms doesn't recommend the use of my app for security reasons, given that one of their VPs contacted me last year about creating a version of my app for iOS!

yes, that is peculiar. however, i did ask the support person in the context of security, so i don't think they could, in a clear conscience, say that this was a secure choice. perhaps some good comes from this and they might work with you to tighten up the security.

that it is still a free service on voip.ms and that you are also presumably working on this as a hobby project, sadly may mean voip.ms business folks might not make it a priority to fix (since no $$$) and instead they put the priority on the pure SIP approach as that is a standard (unlike their api) even if SIP SMS appears to have fewer features. who knows though - i am not a mind reader/psychic.

i do understand voip.ms SMS has "beta" all over it (to the point now that it seems like gmail's beta) but it really is the one missing link in being able to go all voip (since convincing everyone to ditch SMS didn't work). perhaps voip/SIP SMS is still nascent and it isn't clear what the best way to do this is, hence voip.ms is still figuring out what to do. i would like to hope they at least throw you a bit of money for all your work (or at least some credit) since you do make their customers happier.

[carchrae]

btw, although this isn't strictly the api, but is the code for the callback handler/push notifier available? i see that it is running on google app engine. i suspect if i am in paranoid mode that it has issues as well ... and hence the fdroid fork. is the callback merely a trigger/hook that makes the app fetch (correct flow) or does it send a payload containing the message (i hope not!).

thank you for taking the time to respond and converse.

[michaelkourlas]

Yes, the source of the cloud function is available here: https://github.com/michaelkourlas/voipms-sms-firebase

The F-Droid version of the application isn't a fork; it's maintained by me in a separate branch. F-Droid applications can't include any closed-source libraries, so all the Firebase stuff had to be removed.