Closed babel91 closed 4 years ago
I'd be glad to get some more details around your concern. The only protocol used by the app is https, thus all data in transit to and from the VOC API is encrypted. The Homey Volvo On Call app uses the same basic authentication that the Volvo On Call iOS/Android app use.
So, the issue is volvos programming?
The Volvo On Call API is based on basic authentication, https://en.wikipedia.org/wiki/Basic_access_authentication. If you trace the communication you would see the base64 encoded user and password data in an HTTP header field called Authorization. As Wikipedia page says "... no confidentiality protection for the transmitted credentials. They are merely encoded with Base64 in transit, but not encrypted or hashed in any way. Therefore, Basic Authentication is typically used in conjunction with HTTPS to provide confidentiality." This is the case here, HTTPS protocol is always used which results in encrypted communication end to end and nothing is transferred in plain text.
// Device DATA
let devices = await Homey.devices.getDevices();
Object.values(devices).forEach(device => { console.log(device.name + " Id: " + device.id); });
console.log('***');
UsedDev = ('Put device id here');
FullDev = await Homey.devices.getDevice ({id:UsedDev});
var DevArray1 = (Object.values(FullDev));
var DevArray2 = (Object.values(DevArray1[14]));
var DevArray3 = (Object.values(DevArray2[0]));
var DevTemp = (DevArray3[0]);
DevArray1.find(function(value, index) { console.log('Visited index ', index, ' with value ', value); });
console.log('***');
var do_tell_Array = (DevArray3[5] + ' ' + DevArray1[6] + ' ' + DevArray3[0]+ ' ' + DevArray3[7]);
console.log(do_tell_Array);
return false
// Put in the device id of your volvo and run this script, in the bottom of the console i found my id and password.
Den sön 6 okt. 2019 kl 13:21 skrev ricott notifications@github.com:
The Volvo On Call API is based on basic authentication, https://en.wikipedia.org/wiki/Basic_access_authentication. If you trace the communication you would see the base64 encoded user and password data in an HTTP header field called Authorization. As Wikipedia page says "... no confidentiality protection for the transmitted credentials. They are merely encoded with Base64 in transit, but not encrypted or hashed in any way. Therefore, Basic Authentication is typically used in conjunction with HTTPS to provide confidentiality." This is the case here, HTTPS protocol is always used which results in encrypted communication end to end and nothing is transferred in plain text.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ricott/homey-com.volvocars/issues/3?email_source=notifications&email_token=ANM2CXKEW2Q2MMIBBL2UYLDQNHC4BA5CNFSM4I5ZE3E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOHWBI#issuecomment-538737413, or mute the thread https://github.com/notifications/unsubscribe-auth/ANM2CXOSD2NVLGC2JUTY5ODQNHC4BANCNFSM4I5ZE3EQ .
So let me try and again describe what I'm guessing your concern is :)
Your concern is that within the app settings the username and password are stored in cleartext. Something that is possible to access after you have authenticated to your Homey from your local network and use CLI to deploy code to it?
I have used the template suggested by Athom for storing app settings, https://apps.developer.athom.com/tutorial-Drivers-Pairing-System%20Views-Credentials%20Login.html. With that said I of course, want to provide an app that is as secure as possible. Ideally Homey shouldn't allow one app to read another app's settings, they should have separate namespaces. (Assuming this is the problem you are highlighting)
I'm not sure how we can find a key to use for encrypt/decrypt that won't be accessible when you deploy another app on your Homey?
Exactly, but with your explenation im not sure if this really is a problem, because the network and the homey is encrypted in it self? Btw thank you for awsome respons time!
I'd rather store it encrypted if it makes sense and is possible. Checking in the developer slack channel if someone is doing this.
Sounds good to me! I will do some reserch to, and let you know if i find something usefull!
Den sön 6 okt. 2019 22:33ricott notifications@github.com skrev:
I'd rather store it encrypted if it makes sense and is possible. Checking in the developer slack channel if someone is doing this.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ricott/homey-com.volvocars/issues/3?email_source=notifications&email_token=ANM2CXIFYPC7YRITXTBB5A3QNJDRRA5CNFSM4I5ZE3E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOTMXI#issuecomment-538785373, or mute the thread https://github.com/notifications/unsubscribe-auth/ANM2CXKQZFGFU2QBEHDZHDLQNJDRRANCNFSM4I5ZE3EQ .
Solution implemented using encryption key stored in an environment variable, which is not accessible in GitHub or through the Homey API. The feature comes in version 1.0.3 which will be released after Athom approves it (usually in a few days).
Sounds like a good solution!Btw, the fastest answers and solution ever :D
Now the release is out, please let me know what you see using your script
I used my script again, sorry for long delay, have been working a long way from home, But the username and password is still stored without encryption.
Sorry for the long turnaround time, I was on vacation. I finally managed to reproduce the problem and it seems we weren't looking at the same place. You found email and password as part of the data object associated with the device. I was under the impression they were only temporarily stored there since I wipe them later and store them at another place. When I now managed to find what you found then I checked it up and it turns out the data object is immutable (not possible to change) as per Homey's documentation. So me unsetting them didn't help obviously.
I have now new code in place that doesn't pass the credentials from the driver to the device using the data object but instead another object that is possible to wipe later. The downside is that you need to remove the device and add it again for this to happen. Since the data object is immutable it is not possible to change at all for current devices. Will issue a new minor release in coming days.
Sends user and password without encryption.