Continuing the discussion from SmartTiles Dashboard 5.4.2 - July 13 (www.SmartTiles.click):
Hi John,
@625alex may add details in his own words, but I’m providing first-line support while “Version 6” of SmartTiles is under development (no release date announced), so here’s a start to help put this in perspective.
Version 5’s source code also open for a while and was reviewed by various Community Members, so they can chip in as well, and, the fundamental OAuth security model utilized is a fundamental piece of the SmartThings Platform.
First of all, there’s no value to me replicating the official SmartThings Documentation of the architecture involved (“Web Services SmartApps”). In order for you to fully understand the security model, I must first point to the Documentation and assume that you have read it and can refer back to as necessary: http://docs.smartthings.com/en/latest/smartapp-web-services-developers-guide/index.html
Next, in general, your summation of the access rights granted to third-party services via Web Services SmartApps is essentially correct, thought there are some subtle differences that may apply in certain exception situations. Regardless, in the general case, it is important to acknowledge that access granted via the OAuth process to a SmartApp is a similar risk level for every third-party that you authorize, including, but not limited to, such examples as IFTTT, Amazon Echo / Alexa, The Ubi, SmartRules, Sharp Tools, Simple Rule Builder, InitialState, ThingLayer, etc, etc!
I list those examples not to deflect from the level of exposure you describe, but to emphasize that this is absolutely the intended, customary, typical, and standard method of granting third-party applications to access your Devices. The granularity of access is at the individual Device Instance level (i.e., if you grant access to some of your Switches, but not Locks, the third party application cannot subscribe to Events, read Attribute or run Commands against those Locks or non-authorized Switches. Unfortunately, the granularity is no finer than that: If you grant access to a Lock, it is full access to all the Events, Attributes and Commands (e.g., currently there is no option in SmartThings to grant “read-only” access to a Device Instance – you could create Virtual/Shadow Devices to get around this limitation, however). All this is described in the Documentation, though perhaps with more or less detail.
“Officially” published Third-Party services (via the method above, OAuth Web Services SmartApps) do have their SmartApps Only go through a review process (by SmartThings) before being published, which does not significantly increase trustworthiness of the service, though, because SmartThings still has no control of the actual Third-Party service. SmartThings could certify, for example, that the particular Web Services SmartApp does, in fact, only access Devices for “read-only” purposes, but that would be appropriate for a limited set of third-party services, obviously. The ones I list, IFTTT, Alexa, etc., need “control” permission, but even in the cases of published integrations, SmartThings is not able to audit the service itself to confirm their functionality, security, and data retention policies.
The behavior of Third-Party services can be monitored to some extent via the Event log entries that are triggered by the SmartApp. If a Lock is mysteriously unlocked, for example, SmartThings does, I believe, consistently trace which SmartApp triggered that action. If you did not expect IFTTT or SmartTiles to run an unlock command, at least there will be an audit trail. NB: Events have flags which determine their visibility; I don’t think Events can be hidden entirely though. This paragraph needs verification for accuracy.
So how big should your concern be?
Well… firstly, any and all Third-Party services will always have less access to your account, location, hub, and devices than SmartThings themselves. So we already must put significant faith in a cloud-based company to have strong security systems, policies, and procedures in place and constantly vigilantly contained. SmartThings publishes their data sharing policies as well as related Terms of Use on their web pages. I can tell you for a fact, however, that SmartThings own platform has some significant security flaws which they have not published and refuse to publish, and hopefully are in the process of remediation. Whether or not they should be more transparent regarding these vulnerabilities is a discussion for a different topic, as that is completely outside the control and scope of SmartTiles.
Secondly, all Third-Party services using the Web Services SmartApp OAuth authorization process are limited by the specific Devices that you authorize using the authorization web page and/or the Preferences configuration pages for the SmartApp in the SmartThings mobile App. The latter is the case for all SmartApps, actually, and is the fundamental access control method. If has some trust doubts regarding a particular SmartApp, or a particular third-party service, then by default it has access to none of your Devices, except those you expressly grant (it will only have access to some very few Location Scope functions, such as location.mode, and routines – I consider this to be a small leak that SmartThings should close, but again, not “our” problem – SmartThings has been notified of this specific concern by myself, in fact, and they have not offered to remediate). Regardless, at the Device Instance level, for such services that you do not fully trust, you would simply not select (and therefore, not grant access to) any particularly critical devices such as your Locks or Cameras.
What (else) can be done?
The above section is the baseline starting point for considering the risk of each Third-Party Service. In other words, they have no more access than you grant them, but once granted specific access with fairly broad granularity, you have little choice but to trust each such Service.
Large companies such as Amazon (and IFTTT?) are inherently highly trustworthy (at least as far as their intentions are concerned, and to the extent that they follow their published security and privacy policies). If your Amazon Account uses a weak password (your fault) or if it is compromised by hackers (their fault), then, indeed, the access methods and/or access credentials only to the particular authorized Web Services SmartApp are potentially compromised. Perhaps a reasonable, but loose, analogy here is if you use of the same login and password on multiple banking websites; or slightly more accurately, if you choose use your Facebook or Google+ OAuth credentials to login to various websites … a fairly common practice. Just like in the latter case, you can revoke access to those extra websites by using the application security settings inside Facebook and Google (etc.) – just as you can uninstall any Web Services SmartApp for any particular Third-Party service at any time and thus immediately disable it’s access – i.e., your SmartThings account user id (email) and password have never been shared with the Third-Party service.
To put this in perspective, over 5000 SmartThings Accounts have installed the Amazon Echo Web Service SmartApp, and over 10,000 have installed IFTTT. Perhaps many of these users have carefully avoided authorizing some Devices they consider critical (e.g., Locks); but I would not be surprised if many users have authorized every single one of their Devices. InitialState is a service that will store your event data “forever” for a fee, but you must put your trust in their privacy policy and security systems…
For Community and other small Developer based Third-Party services (SmartTiles, SmartRules, etc., etc.), there are far fewer installs, so far, and thus, hopefully less of a target for hackers; but, absolutely, these entities are less likely to have stringent security policies and architectures in place. Use of these services is, undeniably, at your own risk. As mentioned above, SmartThings may take a role here by accepting some of the associated Web Services SmartApps for review and publication, but they are never going to claim that the user faces “no significant unknown level of risk” from these services which are outside control of the SmartThings Cloud and Platform (subject only to the authorization granularity repeatedly mentioned).
So what about SmartTiles Specifically?
You mention this:
For SmartTiles versions currently released (i.e., below the unreleased Version 6), “we” actually have no access to your authorized Devices because we never, ever, store the generated “access token” (ref: http://docs.smartthings.com/en/latest/smartapp-web-services-developers-guide/tutorial-part2.html#appendix-just-the-urls-please). SmartTiles presents you with the URL for your Dashboard(s) and automatically includes the convenient URL based Access Token, should you choose the convenience of automatic login by book marking this full URL. That URL is never transmitted cleartext due to the use of HTTPS/SSL, but it is, indeed, not the most secure option, as it may be retrievable from your bookmarks, browser history, and certain types of proxies and server logs. If you remove the Access Token from the URL, then the SmartThings Platform will prompt you for your SmartThings Account Login and Password for the duration of the session (just like logging into the API/IDE or mobile App). Without an independent security audit, we cannot prove to you that we don’t store this token, but folks that have the Version 5.x source code can verify whether this token is transmitted anywhere at anytime (it’s not, really!).
The relevant SmartTiles.click FAQ for the above paragraph is at this URL: www.smarttiles.click/info/security
As for future versions of SmartTiles…; well, it is too soon for too many details, and may never reveal everything…
We will publish a data privacy and security policy at least as required per applicable legal jurisdiction. This policy will also, necessarily, explicitly disclaim our liability except as legally prohibited, of course. In other words, it will pretty much match SmartThings’s own policy, and for all intents it actually should be the same!
We are moving to more service-oriented architecture where the Web Services Access Token and certain device event history data and control paths, etc., will inevitably be stored outside of the SmartThings Cloud and on SmartTiles own or leased Clouds. Because the design is not finalized, and pending internal decisions, we may never reveal the particular cloud vendor(s) used. The one(s) under consideration are very prominent and have very well reputed security architectures in place, including strong end-to-end encryption of all data, and multiple user authentication options (i.e., you can authenticate using your Google or GitHub login, for example, if you wish to avoid creating yet another login and password to maintain – by this method, we receive a revocable authentication token, and never an actual login id and password).
For the case that a non-isolated security breach is suspected or detected, we are planning to maintain the ability to instantly revoke access to the Web Services SmartApp for all users. This is a bit of a nuclear option as it would fully disable all Dashboard installations indefinitely, but this is an example of the type of security precaution that is considered important to restrict and instantly arrest the damage that could be caused in extreme scenarios.
Finally, just like SmartThings themselves and all vendors and services that hold critical data and provide a path to access or control your Devices, at some point in time and periodically thereafter, SmartTiles can submit the platform for independent audit (i.e., full review of the platform, cloud vendor choices, source code, etc., under non-disclosure agreement), with the results published after remediation. Between audits, “white hat” hackers will be encouraged to gently probe the platform for vulnerabilities on a “black-box” basis.
The process described in preceding paragraph should really be industry standard for all the various “Third-Parties”; but I think it is reasonable for most people to “trust” external services with access to their SmartThings Devices even without this most stringent level of audit / verification. If, in your words, you “can think of no greater threat than granting access to third parties”, then you may decide, for yourself, on a case by case basis, which, if any, third-party services to use. On average, we expect SmartTiles to be more trustworthy than others, but we can’t be expected to expend significantly more effort than other typical and popular third-party services (i.e., IFTTT, etc., etc.) to prove this to you.
! …