This is my whole quote. I never said you shouldn’t discuss security issues, in fact, I was asking for a proper place to do it.
Publicly discussing them is the worst place, but not discussing them at all is even worse.
The author of the book is a professional security researcher and have published several books on the subject. I’m pretty sure he’s familiar with industry recommendations with respect to reporting security vulnerabilities. In fact the author commends SmartThings for cooperating with researchers who discovered SSL Certificate Validation Vulnerability in December 2014.
Pardon me, but I believe I quoted you in the proper context. You’ve already repeated twice in this thread that “Yes, I do believe that discussing known vulnerabilities in the open is the worst place to do it.” That’s a full sentence and there’s no ambiguity about it.
I would agree that discussing unknown vulnerabilities should not take place in public. But trying to hide or restrict access to information that’s already been published does not make sense and actually does a disservice to the community.
The book focuses on two known vulnerabilities:
- Single-factor authentication
- Clear-text password reset link
BTW, the first one was actually brought up on this Forum 9 month ago (!) by none other than @slagle, before he got on SmartThings payroll and assumed the role of Community moderator.
You can “revoke” a token by deleting the smart app for that token - no more access. Unless I am deeply mistaken, of course.
1 Like
That’s exactly the sort of information that SmartThings should confirm and highly publicize for the benefit of the security of their Customers (i.e., so they can self-mitigate the risk).
I think I mentioned that earlier… It’s not ideal, but it should work. Clearly the app is no longer running.
1 Like
Also, a proven method is to keep track of the authorized tokens within the smartApp state and then allow the user to revoke a token within the smartApp UI.
Then in the smartApp check the request token against the internal list of revoked tokens, if there, don’t run the smartApp response, respond with token revoked.
Perhaps this should be a standard feature mandatory required for publication of OAuth SmartApps (verified in the submission review process), until a better way is implemented in the platform.
1 Like
Verified. Even easier than deleting the SmartApp. Go into oauth settings. Click generate new (either client id or secret)
Then try using the endpoint that you got before, using the old one… you’ll get this:
{“error”:true,“type”:“AccessDenied”,“message”:“This request is not authorized by the specified access token”}
So, there you go. Revoked.
This is not a Consumer level solution.
True - but the nuclear option (un-installing the smart app) would certainly work, and presumably the consumer installed the app and opened the access hole in the first place.
Information in the book is up to date to the best of my knowledge and is definitely not “hyperbolic” or “inflammatory”.
First, the lack of two-factor authentication is not a figment of my imagination and I’ll quote our former fellow community member @slagle here (hopefully not out of context):
Second, irrevocable access tokens with 50 years expiration term are real, as has been discussed here and elsewhere. Third, the clear-text password reset link has not been patched, as far as I understand. And lastly, the SMS loophole has not been closed either and the fact that you can achieve similar results by other technical means does not make it less important.
None of these issues are the “show stoppers” and as the author notes, SmartThings security is in many ways better than most other consumer-grade IoT services. That’s why I believe it’s inappropriate to compare this discussion to “yelling ‘fire’ in a crowded theater”, as @pstuart called it or try to hide this information from public view.
This only works for self-published apps and requires IDE knowledge. Uninstalling the app is the only available option, but not a practical one for the apps with dozens of linked devices, like SmartTiles for example. That’s why @625alex implemented token revocation at the application level, for which he deserves applause. 
However, SmartTiles (along with other similar apps) suffer from another security vulnerability by instructing the user to use URI that includes access_token in the query string. This practice is specifically not recommended by RFC-6750.
Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the “Authorization” request header field or the HTTP request entity-body.
Combined with 50 years longevity of access tokens, this poses a threat that by gaining unauthorized access to one of ST servers, the intruder can harvest live tokens by simply scanning the web server access logs.
Again, I’m not trying to scare anyone or discourage people from using SmartTiles or other web service apps, but it does not hurt to be aware of this issue and take appropriate measures.
SmartTiles does highlight this particular slight vulnerability on its website FAQ and, as I have recommended several times, provides suggestions for self-mitigation of the risk (e.g., delete the token part of the URL and you will be prompted for id and password upon use). Depending on user demand, this could be made the default behavior if @625alex agreed on the relative risk level, and, frankly, could make it an option in the SmartApp installation process, and make the change in a few days, unlike SmartThings who we know take weeks, months, or longer to address similar scale concerns.
This was an interesting video. Although it was shot in 2013, does this this z-wave security vulnerability still exist?