Secure text field

Did I miss a way to make a text field "secure" (ie a password box?) within a ConfigUI?
Just wondered if it was in the "secret documentation place" ;p

If not, could that maybe be added as a future feature?....

[jay (support)]

Yes we've had that request before. But as I pointed out then, adding a password field isn't really useful unless the data can be stored securely.

We have it on the request list but its not super high at this point.

I'd argue for the usefulness at this point.

I'd say that the onus for the storage of the data is on the developer. I don't *have* to use pluginPrefs to store the value in the clear (it could be cleared out and subsequently stored in the keychain, or hashed before storage).

In my use case, I'm allowing the user to configure a password that'll be used to remotely view cameras. Sure, someone who's fairly familiar with the workings of Indigo could find out what that password is (if it were put in pluginPrefs), but the casual user "clicking through" won't be able to see it.

What I'll actually end up doing, to stop my friends who'll be beta testing for me being able to view my cameras (!), is clearing the field on validate and storing it in a non-UI element. This will, IMHO, lead to a bad user experience as there'll be no way to tell if a password is set or not.

If it were secured, I could *actually* MD5 hash the password on validate, and save it in that format. When the user authenticates with their client, I'll hash that password before transmitting it (there's no SSL here), and validate against the hash...

Anywho - if we could move it up a little, it's of value

-A

I'd have to agree with Alistair here. Any developer worth their salt knows that ••••••••'s in a password field don't inherently indicate any kind of encryption or security. The real value here is user experience. Fwiw, please consider this my +1 for that particular feature.

On a related note: Jay, do you have any preferred methodology of tracking feature requests? I'm really getting into plugin dev and want to make sure I'm not unnecessarily repeating something that's already been said.

[matt (support)]

What I'll actually end up doing, to stop my friends who'll be beta testing for me being able to view my cameras (!), is clearing the field on validate and storing it in a non-UI element. This will, IMHO, lead to a bad user experience as there'll be no way to tell if a password is set or not.

I think this brings up the good solution though. How about:

1) On validate retrieve the password from the ConfigUI (say from key uiPassword).

2) Hash or encrypt the password and save it in the pluginProps under a new property key hashPassword.

3) Presuming the original uiPassword has a len() > 0, write out into the uiPassword the static string ••••••••.

4) Add a conditional to step 1 that causes it to skip the hash and stuff in hashPassword if the uiPassword matches the static •••••• string (or if it contains characters that are only •).

The only thing this doesn't do is show the masked • characters as the user types the password. But other than that (which I think is a minor problem), it should be a good technique and easy to implement on validate.

[jay (support)]

Guys - security through obscurity isn't a particularly valid method of security. Matt's suggestion seems reasonable if you really think someone is going to get access to your Mac and snoop around opening up dialogs looking for passwords.

We track feature requests internally but don't have any mechanism to make that information public.

Jay.. while I completely agree with your point, my reason for wanting to use a password field has nothing to do with security. To me it is simply a matter of a smooth and predictable user experience. Every website or application that has ever required me to enter a password has done so utilizing a password field. My knowledge of Interface Builder (and OS X UI elements in general) is in its infancy, at best, but it doesn't appear to be much more than specifying that the textfield be of the class 'NSSecureTextField'. Either way, just my 2¢...