Security of Preferences Data

(George Reese) #1

How and where are preferences stored? Are values of type password treated differently?

(Todd Wackford) #2


I do not believe passwords are stored any differently than a string or a number. It is suggested that you use a 3-step OAuth 2.0 method if possible.


(George Reese) #3

The issue at hand is that I can’t control what kind of authentication is in use with third-party systems. In the case of a Tesla, the Tesla API uses the user name and password of the car owner. IMHO, SmartThings should take this into account. It’s obviously common enough that there’s a “password” type.

(Todd Wackford) #4


Are you passing the info over a secure port? If not, storing it securely would not be my main concern, it would be the open air hand-shake. Maybe our ST friend @ben_edwards can share some additional insight to the topic, Ben?


(George Reese) #5

How sensitive data is stored is every bit as important as how it is transmitted.

(Luke) #6

The transmission of all data from the mobile apps (or any API request, really) to our servers is forced to occur over SSL, and we highly encourage SmartApp developers making HTTP calls from within SmartApps to use SSL when available from the target server. While we do highly prefer token-based authentication, we recognize that some services may force us to use passwords, so we automatically store preferences of type “password” in our database using 256-bit AES encryption.

(George Reese) #7

Thanks! Perfect! The only thing I’d love to hear more is that the encryption keys are unique to each tenant :slight_smile:

(Luke) #8

I can’t discuss exactly how to derive the encryption keys, obviously, but they are definitely unique per SmartApp installation, and we took steps to ensure that it would be as difficult as possible for an attacker to recover them.

(George Reese) #9

That answer is good enough and I understand why you can’t give more. I definitely appreciate the thought you guys have put into the issue.