Security concerns using webCore


I just found webCoRE and it looks amazing.
A very nice job you guys did. After reading through the whole install process and how to start using webCoRE I wonder a bit about security of the whole system. Especially because I have to manage all my Pistons on an online accessible website. And I guess a lot of data is sent back and forth from Smartthings to the webcore instance?. Maybe I’m just wrong and have no idea how the data transfer works. Maybe someone could tell me a bit more about how secure it is to use webCoRE. I would really like to use the amazing features of it. But don’t really want that too much “sensitive” data from my home is sent. Is there a chance to setup the webCoRE web UI on an internal server at home as well?
Thanks for your help


@ady624 will explain 1000x better than I can but I’ll have a go…

He couldn’t possibly be more pedantic about security and privacy.

Pistons are built on the web, yes, but when you save them they are sent to your ST account and run in the ST cloud with no coms going via the webCoRE servers. Logging etc. is also stored in the piston file in the ST cloud.

Piston backups use the device ID’s not the names and are encyripted in such a way that only the original instance can view it.

Andy has zero access to your pistons, he can see a list of backup codes but can’t open them.

When reading a piston on the web interface, it’s via HTTPS.

Think of webCoRE a bit like old CoRE. Everything runs on the ST cloud as before, just the editing is done online but using ST for the unencrypted storage.


All the source code for the web interface is published and current on @ady624’s GitHub… if you’re (very) technically minded, it’s possible to setup your own interface on a private server, but pistons would still run on ST.

Source code being available also makes it publicly open for independent scrutiny, and I know of a couple of highly skilled users that have done exactly that.


@RobinWinbourne thanks for your reply


I will try and explain in some detail how this whole thing works. And I may update this post several times to add more details (long story).

All apps and devices in ST are described by an internal GUID-looking ID and a label. webCoRE has access to the devices you give it access to and to its own apps (pistons) only. ALL ST-world IDs get hashed using MD5 in the SmartApp - the UI only receives these hashed IDs which are useless to anyone not knowing the original values - they cannot be “decoded”, you need to rehash all device IDs and compare to the hash to figure out which device it represents. So even if someone gained access to a whole list, that is useless. A cache of hashed IDs and labels is locally stored by the browser in a SHA encrypted form. The webCoRE UI is 100% static javascript code and the webCoRE server is only used to download the html, css, and js files. The webCoRE server maintains statistics though, stats generated by the smart app, not the UI (UI uses google analytics). The smart app itself will (if allwed by a checkbox in the setup process) report to a webCoRE server with the following info:

*hashed ID of your ST account ID
*hashed ID of your ST location ID
*hashed ID of your webCoRE installed app
*number of active pistons
*number of paused pistons
*app version
*endpoint for piston triggering (email) - the password/token is not provided and a piston ID is required for such triggers to work - piston IDs are never stored on the server

Other than that, webCoRE does not store anything else on purpose.

Dashboard registration
This one needs a webCoRE server to temporarily store secure info that allows a dashboard to connect to ST. The endpoint URL is passed to a webCoRE server that stores it into a temporary file and produces a 4 digit code. When you enter that code into your dahsboard, the file is read and given to the UI and then immediately deleted. Files are also deleted if they are older than 3 minutes. This is the most sensitive information that is temporarily shared with a server and most endpoints require a password/token that is NEVER shared with anything. You need to enter a password when registering a dashboard, so even knowing the endpoint is useless… webCoRE servers nor the UI ever get to store the access password. Once a password is entered, a revokalble token is generated that can be use until it expires (by default each month). The UI will locally store the token. The webCoRE servers never have access to it.

webCoRE presence
The webCoRE iOS app is manually reviewed by Apple at each release. Place names and locations are never shared with any webCoRE servers. They reside in the settings variable of the parent app state in the ST cloud. Once a sensor setup, the list of places and a device ID are provided to the mobile app, along with the ST endpoint. The mobile app reports location to ST directly, no webCoRE server is involved in any way or ever sees anything remotely close to a coordinate of any sort. I don’t want that kind of data, too sensitive to touch :wink:

The github contains a dist folder wilhich is pretty much a copy of the dashboard code in minified form (for load speed purposes). You can visit for the latest raw code. There is no active page on the server side, no php, no asp, no anything. The server contains php and node.js code but that is not involved in day-to-day business - the php is involved in storing/deleting the temporary registration code. Node.js is involved in fuel streams and media streams.

Let me know if you have any other questions, I will be happy to answer.


With regards to bin codes, they are stored on a server and there are two types of them: public and private. Each user account gets its own location for their private codes - the public ones are all in one place (they’re … public)

For fun, here is a piston:

Here is the public bin data for w7mn, anyone who has JS knowledge and a little bit of hacking skills should be able to eventually decode it using the webCoRE source code:


And this is the private backup data for the same exact piston:


If anyone please wants to try and decode them, please let me know if you managed :smiley: The first one should be easy.


Hey I think that you meant to link to not


You are right, thank you. Corrected it.