Find my iDevices!

Hello bschollnick2,

The issue with the DeviceID error is fixed with 1.52...

Thanks.

Version 1.52 of Find My iDevices! is being released.

https://dl.dropbox.com/u/241415/Find%20 ... 0v1.52.zip

Changes since v1.51:

* Addressed an issue with the Sanity checking of iDevices with Apple's server.

I'm having trouble installing 1.52 of Find My iDevices. When I double click on the file that's in the "Add to Plugin Directory" it causes Indigo to stop all my plugins and it seems to shut down the server. Then a window pops up and asks me to select my database cause it can't find it or it's corrupted. I select my database and everything boots up as normal, but there doesn't seem to be any changes and it still says Find My iDevices is version 1.51. I also tried manually copying the file to the plugins folder and restarted the server, but no change on version number.

For the folder in the "Add to IWS Plugin Directory" I copied it without any issues, not sure if this will cause problems cause it's running a 1.51 plugin with a 1.52 folder.

I'll rebuild v1.52 again tonight. For some reason, it appears that the IndigoBundle has been damaged. (It shouldn't be a folder...)

The updated archive is here.... It looks fine on my Lion system, but under Mt. Lion, it didn't... Strange...

https://dl.dropbox.com/u/241415/Find%20 ... 0v1.52.zip
- Benjamin

I'll rebuild v1.52 again tonight. For some reason, it appears that the IndigoBundle has been damaged. (It shouldn't be a folder...)

The updated archive is here.... It looks fine on my Lion system, but under Mt. Lion, it didn't... Strange...

https://dl.dropbox.com/u/241415/Find%20 ... 0v1.52.zip
- Benjamin

I download this link above that I quoted and it works, but when I double clicked on it it said "Install and Enable Find My iDevice 1.51". Is that a typo? Looking in the setting it still says 1.51 too.

I'll rebuild v1.52 again tonight. For some reason, it appears that the IndigoBundle has been damaged. (It shouldn't be a folder...)

The updated archive is here.... It looks fine on my Lion system, but under Mt. Lion, it didn't... Strange...

https://dl.dropbox.com/u/241415/Find%20 ... 0v1.52.zip
- Benjamin

I download this link above that I quoted and it works, but when I double clicked on it it said "Install and Enable Find My iDevice 1.51". Is that a typo? Looking in the setting it still says 1.51 too.

Yes, it's a typo. It's identical to v1.51.... I forgot to increment the Version ID in the plugin plist...

Is there a setting or something to hide our passwords or make it appear as asterisks in the Event Log & Device Settings? This seems like a potentially serious security issue, which could result in our Macs, iPhones, iPads, & iPod Touches being remotely wiped. Our Apple IDs are linked to credit cards on iTunes as well.

Is there a setting or something to hide our passwords or make it appear as asterisks in the Event Log & Device Settings? This seems like a potentially serious security issue, which could result in our Macs, iPhones, iPads, & iPod Touches being remotely wiped. Our Apple IDs are linked to credit cards on iTunes as well.

I agree, but Indigo does not yet support a "Password text field", so I have no way to modify the preference pane to hide the password field.

I have already requested a feature like that as a feature enhancement, but I do not have a time frame from Matt or Jay...

- Benjamin

[jay (support)]

I should point out that the plugin is completely in control of what gets posted into the Event Log so if it's being inserted there the developer can just NOT put it there.

It is true that we don't have a password field type in the API - but it would be pointless since the data isn't stored encrypted so anyone can just open the plugin's preferences file to see the password. We need to figure out some way to encrypt the password (we can't just one-way hash it since the plugin will undoubtedly need to get to the "real" password to pass off to another service). So it's a much more tricky proposition.

The developer can do it themselves of course - when the plugin gets the config dialog when the user clicks the save button, they could encrypt the password themselves and store the encrypted version rather than the unencrypted version. So it wouldn't be stored in the clear and when the dialog is opened for editing they could just not show it or show whatever they want. So really the only time the password would show up is when the user types it into the text field and before they click the save button.

I should point out that the plugin is completely in control of what gets posted into the Event Log so if it's being inserted there the developer can just NOT put it there.

The developer can do it themselves of course - when the plugin gets the config dialog when the user clicks the save button, they could encrypt the password themselves and store the encrypted version rather than the unencrypted version. So it wouldn't be stored in the clear and when the dialog is opened for editing they could just not show it or show whatever they want. So really the only time the password would show up is when the user types it into the text field and before they click the save button.

The only time the username / password is placed into the log, is if Debugging is turned on for Find My iDevice. And it's configured to do that, so that the owner can see if there is an typo....

The password could be hashed and stored. But the issue is that the decoding algorithm of the hash is also in the plain text python code. It would obscure the password for no real benefit, since anyone could get the decrypting algorithm. In addition, the password would still have to be plain text in the editing dialog. If the encryption and decryption code can easily be examined, and the password has to be seen in plain text, then there's nothing that will stop someone from being able to see the username password by simply opening the preferences for the plugin or device.

Now, I guess I could put a button into the Apple ID login device to "Enter or Edit your password", but off the top of my head I don't recall Indigo offering the ability to display a Text Edit box from a button....

My real concern is that Indigo needs to have a better password widget, then just using a plain text field. I can't believe that my plugins are the only ones that have a username / password field. The real solution would be for Indigo to offer a hashed text field that encrypts and decrypts the data as needed. The encryption key wouldn't be visible in the plugin code, and the "visible" characters could be a hash marker, dot, whatever. We can't do that as it is now. Pushing this to the developers just is security theatre. I pointed this out in the early Alpha's, and I realize it's more work on the SDK... But everyone that has a plugin that uses an username / password combination has this issue.

If you have a better suggestion, than please outline it more than, the developer needs to encrypt the data.

Having the encryption and decryption code in the plugin means that it is not a strong encryption and can be easily foiled.
The only work around to that I see would be to ship compiled python byte code, and even then, that's not encrypted. Just obfuscated.

[matt (support)]

Our point is it isn't just a matter of making the UI widget show •••• instead of the actual password, since that doesn't encrypt the password itself. Given our ToDo list, we won't be able to implement this anytime in the near future (our ToDo list of high-priority items is very long at the moment). So I'm not saying this is needed or important, just saying it isn't going to be in Indigo in the short term.

Your plugin can probably handle this by accessing the OS X keychain for storing the password. Take a look at this as an example.

As a side note on terminology, when we refer to hash, we mean a 1-way hash function that can be used to validate if a manually user-entered password matches but cannot be used to retrieve the original password. What plugins need is 2-way encryption and decryption technique, most likely by access to the Keychain API.

[jay (support)]

My real concern is that Indigo needs to have a better password widget, then just using a plain text field.

If that's your primary concern then you're worrying about the wrong thing. The chances of someone standing over your shoulder surreptitiously watching you type your password is pretty small...

As an aside, the person wouldn't have to be standing over your shoulder... it can be seen as plain text and not hidden or obscured as **** if you configure the plugin. The chances of someone knowing indigo, knowing the plugin, and being able to get access to your computer are probably just as slim...

[jay (support)]

Only if you show the cleartext password when you edit device/plugin config - the developer can, for instance, store the password a separate place than in the standard config properties and remove it from those properties upon save. So the next time the dialog is opened the password field is blank. Not ideal of course but possible.

Our point is it isn't just a matter of making the UI widget show •••• instead of the actual password, since that doesn't encrypt the password itself. Given our ToDo list, we won't be able to implement this anytime in the near future (our ToDo list of high-priority items is very long at the moment). So I'm not saying this is needed or important, just saying it isn't going to be in Indigo in the short term.

Your plugin can probably handle this by accessing the OS X keychain for storing the password. Take a look at this as an example.

As a side note on terminology, when we refer to hash, we mean a 1-way hash function that can be used to validate if a manually user-entered password matches but cannot be used to retrieve the original password. What plugins need is 2-way encryption and decryption technique, most likely by access to the Keychain API.

Using the keychain is a possibility. But we once again start making this much more complex....

Any changes made in the Device Records, are recording in either the preference file or Device database, right? So since the username / password data is a separate device, your suggesting that I don't store the username / password data in there. Well, then it means the user has to modify the username / password via going directly into the Keychain utility to modify the username / password....

That's even worse than having the users have to modify the original security script.

I don't disagree that this is a security concern. But what's the changes of someone harvesting this information from Indigo?

The issue is, I don't see any reasonable way for me to be confident in a more secure configuration, that is still user friendly.

Using the keychain to store the information is a possibility, but I don't have a UI that interfaces with the keychain. And I don't see a reasonable way to create one in Indigo, since the data that I need to secure will be written to the database or preference file(s).

I encourage you to show us a proof of concept. You say it's possible to make a secure storage, where this won't be a problem.. Then please give us a small demonstration, since it's not obvious to do it in a user friendly manner. There are other plugin authors dealing with this same issue as well, all of us would benefit from it.

I have no problems with updating the plugin, but I simply do not see a reasonably user friendly method to do this... And saying that the Developer needs to solve this seems like your pointing fingers, especially when the tools aren't here for us to solve this in a useful manner.

I'm not the Indigo expert, I'm just a power user, that happens to write plugins. And some reasonably popular ones too. I'm not perfect, and chances are, I'm totally wrong here...

The only time the username / password is placed into the log, is if Debugging is turned on for Find My iDevice. And it's configured to do that, so that the owner can see if there is an typo....

Debugging is not enabled in my plugin and I'm seeing my password in the event log. The password is showing up in plain text besides the AltMobileMePassword field name. I'm using version 1.52 that has the version typo 1.51.

[matt (support)]

Any changes made in the Device Records, are recording in either the preference file or Device database, right? So since the username / password data is a separate device, your suggesting that I don't store the username / password data in there.

You can, when the UI closes, blank out that device property (or plugin preference). It should be that simple -- just read the value, store that value in the Keychain API, and then put an empty string (or string like "••••••") back in its place. You'll want to define one of these two methods to catch the UI closing:

Code: Select all

def closedPrefsConfigUi(self, valuesDict, userCancelled):
def closedDeviceConfigUi(self, valuesDict, userCancelled, typeId, devId):

Well, then it means the user has to modify the username / password via going directly into the Keychain utility to modify the username / password....

Nope. See above.

I don't disagree that this is a security concern. But what's the changes of someone harvesting this information from Indigo?

You aren't understanding how this works. Your plugin will HAVE to have access to the plain text password at some point in the code. There is no getting around that, since your plugin needs to pass that password off to Apple to authenticate. Therefore, the possibility exists that someone could hack your plugin .py source files to capture the passwords. It doesn't matter how/where the passwords are stored -- they could be stored as plain text in XML, stored by Indigo in some encrypted manner, or stored by the Keychain API. No matter what, at some point the password is going to be retrieved in an unencrypted state by your plugin so it can be handed to Apple. There are ways to make this more secure/less possible, but as long as your plugin requires access to the password to authenticate with Apple, there exists the possibility someone could hack/harvest it.

How concerned would I personally be about this possibility? Not very given the amount of effort involved and since my Mac is locked-down and not accessed by untrusted parties.

Using the keychain to store the information is a possibility, but I don't have a UI that interfaces with the keychain. And I don't see a reasonable way to create one in Indigo, since the data that I need to secure will be written to the database or preference file(s).

See above.

I encourage you to show us a proof of concept.

I don't have time to create sample code for this at the moment. Hopefully the tips above will help you.

There are other plugin authors dealing with this same issue as well, all of us would benefit from it.

I admit it is an issue and it is on our list to look into in a future version, but to be honest I haven't heard many requests for this. As I stated above -- our high priority ToDo list is very long at the moment.

And saying that the Developer needs to solve this seems like your pointing fingers, especially when the tools aren't here for us to solve this in a useful manner.

I think the tools are there. I'm saying if this is a critical issue for you, then try the suggestions I've made. I don't know if they will work since I haven't tried them, but I don't know of a reason why it wouldn't.