So perhaps let me at least make my original point in a bit different way: do not use App Settings or Device Settings for sensitive user info.
If you f.i. use a DC diagnostic flowcard and then send me a log for some help, i will see those settings.
N.b. I will not see the Store data from other app’s devices, so i think it’s still a much better way of storing sensitive data then the settings. Less change of accidentally exposing the data.
But if you want to know if it’s “impossible” for other Athom Store Apps to read that, check with Athom.
I would change that to: Never store user info unencrypted.
(And perhaps replace user info with anything)
Thanks all. I have emailed Atom support to see if I can get a recommended approach from them.
Agreed (with userdata or at least personal/sensitive data)!
If you use a generic (for all users the same) key, a user can find that key can than use it to decrypt any user data.
If you use a random generator key, you have the same base issue: where do you store that key savely?
Or am i missing something?
How would you hide your encryption key?
Isnt it possible that Athom creates a PKI keypair? At least for the secret data in env.json that would be a solution I think.
Athom hides their private key in their core code, and the public key is used to encrypt env.json before publishing (uploading) any app via homey-cli.
Then again in the running app Homey core takes care of decrypting env.json on the fly within the apps memory.
Im not an expert on this, but would something like that maybe solve the security of credentials in env.json?
If i understand the “issues” with the new Early2023, this also will not be a solution to hide developer-secrets, right?
Athom’s core can also be read out (by a very skilled person), right?
Probably. But obfuscation from the homey core would be way better then when each app has to do it by itself.
Maybe Athom will encrypt the backups. We don’t know.
I’m currently only hashing the user data and put it in the settings. Maybe we will get a secure-storage from athom someday.
Exactly, all we can do is speculate right now, I’d rather have Athom telling us how they designed this (or will, or not and you shouldn’t store sensitive information on homey all together)
I hope @Jonathan_Draper will get an answer and shares it here.
I use app settings for storing user credentials in some apps, too.
But from outside it’s not possible to access this data (WebAPI).
And if a user installs an app with scope for the whole Homey (local WebAPI), then he can read his own data. So far that’s not a problem. The user should know about the rights he gives an app.
Is that already a security risk?
If apps are sending these data out, they are breaking the personal boundary in my eyes as long as these apps are not telling the user they are collecting personal data and the user accepts.
That’s definitely breaking a boundary, but I feel every developer has an obligation to store user information that should not be shared outside the app in a safe way. And that the information is useless when retrieved in any other way than the purpose of the app.
In the past, the app settings have been the best way to store such information. Nearly every app with API access offered such a settings page.
Then Athom removed app settings access in WebApp and setting up the credentials in pairing dialog became the best way.
For soem apps I already store the credentials in device store. But only for devices holding its own credential setting like SQL client (a device is a DB access) or Blink (the account device represents the Blink account with credentials)…
But if I have an app with only a central credential setting, it makes no sense to use device store.
So I would prefer a app store possibility (like device store) that is accessible only inside the app.
Very interesting discussion.
Just one thought… Can we be sure that data in the Device setting and store is automatically erased when the Device is deleted by the user? (Tried to clean up the Device store myself on onDeleted(), but that isn’t possible)
I think so. The device itself is only a set of settings and capability values. When a device is deleted, then it’s this data what need to be removed to remove the device. There is nothing else persistent - if you don’t write device depending data to /userdata/.