Re: secure uitextfield is not secure
Re: secure uitextfield is not secure
- Subject: Re: secure uitextfield is not secure
- From: Fritz Anderson <email@hidden>
- Date: Wed, 05 Mar 2014 14:52:32 -0600
On 5 Mar 2014, at 1:17 PM, Luther Baker <email@hidden> wrote:
> I'm generally a big fan of Cocoa Touch - but why does the "secure" option
> on a UITextField still display the character you are typing?
Touch keyboards offer almost no user feedback compared to physical ones. The keys on the iPhone keyboard are, to my thinking, too small to operate reliably. My hands are on the clumsy side of normal, and my error rate on the iPhone is about 10–20%. Left blind, there’s no way I could ever enter a correct password.
> And, is there any way I can turn this off?
I’d be surprised. iOS meets the (low-level, but nontrivial) security standards of a number of governments, and if I owned UITextInputField, the fewer hooks into password security, the better.
At least, I don’t see any such hook in the API. File a radar.
> Its generally hard to get non-employee AD credentials created or to stand
> up DEV Active Directory services ... so everywhere I've ever worked, folks
> like me are always entering their real AD creds in the app during
> development. This is embarrassing when you are pairing and even worse, was
> in a demo today and the leader is asking everyone "not to look" while they
> entered their AD credentials in front of a whole host of people.
At an institution with HIPAA/FERPA/national-security exposure, exposing live credentials to development, much less demos, is a felony waiting to happen. I’m trying to swear off of impugning others’ professionalism (and I have no reason to impugn yours), but if software development is part of the company mission, it’s the admin’s job to support that mission.
My long-run strategy would be to escalate the matter on my management chain. If there is a privacy/security organization, let them know the risks of the current situation in the most gruesome terms you can muster.
> I guess one could write something to work around this ...
People have tried to implement text field look-alikes (or heavily hooked text fields) that sort-of do what you want, but it’s easier said than done. It’s close to a from-scratch proposition. And, Apple is always going to provide a better, more-secure password (or even plain-text) field than you can build for yourself. There’s more to security than screen appearance.
I understand what you’re saying, and I sympathize, but I don’t _think_ Apple is going to make it a priority to help you. Apple will argue that it can’t assume the user’s responsibility to keep live assets off projection screens, and to look over his shoulder before entering a password.
The only way to find out is to file a radar and see what comes out in iOS 8. In the mean time, yeah, you’ll have to use the delegate methods to hot-swap bullets for typed characters.
> but does anyone
> know if that is really necessary - and what would have motivated Apple to
> implement textField.secureTextEntry this way ... or not provide a textField.
> *really*SecureTextEntry option which would mask ALL the characters. Maybe
> an option that doesn't even show how many # the user is actually typing.
> I'm surely not counting 14+ characters anymore.
Anything that encourages people to adopt passwords short enough to survive a 15% error rate is not secure at all.
— F
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden