Thanks Arie. I will look into how I can do encryption then
Devices also have a Store for saving data. It might be that other apps cannot read that, im not sure.
You can create a device like AVD (it uses that store) and then check the device in HS to see if you can see the store value.
(Sorry, i cant do it, im on my phone)
@Jonathan_Draper in that kind of cases i have a env.json with a secret key. And then I encrypt the password with that key.
encrypt function Example here: com.synology/helpers.js at main · martijnpoppen/com.synology · GitHub
It’s been suggested by Athom that with the new Homey Pro all files belonging to an app will be readable by adventurous users.
As far as i know the env.json is not accessible
Yes, for now. But on the new Homey Pro 2023 it will be different, as written in the developer update.
The question how information in a env.json will be protected remains unanswered, not in the AMA nor on slack.:
I sent athom a message, lets hope they’ll explain that part
I hope they will answer you
This is what they wrote in the developer newsletter from October 12th:
The new Homey Pro can be fully backed up to a Mac or PC using USB. This means the entire operating system & userdata is saved.
Yes but you might expect they’ll provide a alternative for env vars right
Okay @Jonathan_Draper , i just checked:
I cannot seem to find a way to read the Store Values from devices from another App.
Meaning, you could just store the Username and Password, or a Random Generated Encryption Key, in A device’s Store.
Afaik, This can only be read by the App itself. Even the Webpi Playground cannot access this information as far as i can see (if i am wrong, please let me know).
I understand a User could open it’s own Homey and access the fields, but that’s not an issue right?
You asked about saving it’s username and password, i guess this is the savest way.
Now you talk about JWT, so i’ll asume you also have some other “secret” key (i know it can work without, but then the App-ID or whatever).
I don’t know where to save that, since, as you can read above, in a short while ,ever user can read your source code (ncluding the env.json).
But for storing a username and password from the user itself in a save way that other apps or remote access cannot read it, the Device Store seems to me like the fitting solution.
Thank you @Arie_J_Godschalk for your detailed reply. This is great. For the JWT I don’t think I will need to persist that since I can make an API call with the username and password to get a JWT back and just keep that in memory as far as I can tell. All the other calls then take the JWT and an app ID which is just public for all calls to this api
Thank you again for your help
To be honest, while @Arie_J_Godschalk method seems to be a solution it is also based on his assumptions and the fact he can see no method to retreive the stored information in from outside the app.
It’s not that I’m not trusting Arie’s knowledge but I would go for the facts and not assumptions so I suggest you have this method confirmed by Athom.
Indeed, it’s an assumption and if you can verify it, that would certainly be the smart thing to do!
Also, i just checked basic homey ways to check the access, i have not tried any real hacks or anythink and i am not very knowledgeable about node.js.
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?