Re: secure uitextfield is not secure
Re: secure uitextfield is not secure
- Subject: Re: secure uitextfield is not secure
- From: Luther Baker <email@hidden>
- Date: Wed, 05 Mar 2014 16:05:09 -0600
Yep - cool. I'm not too dismayed and take it as it comes but I'm just
seriously surprised. It seems like a very obvious use case.
Google Mail does email differently and I think they justify it by _selling_
you a different way to look at your email. I have a hard to rationalizing
this in a similar fashion.
> Because (in my own case) I'm incapable of typing a password correctly
using the on-screen keyboard unless I can see when I've pressed the wrong
key.
:) true. But I don't think this really justifies the decision. My daughter
dropped the iPad on her toe but I don't think that warrants rubber bumpers
on the device :)
Just say it out loud a few times ...
*passwords appear in plaintext as you type them ..*
*passwords appear in plaintext as you type them ..*
*passwords appear in plaintext as you type them ..*
*passwords appear in plaintext as you type them ..*
I guess this would be a good idea for hermits :)
> The only way to find out is to file a radar and see what comes out in iOS
8.
How very sad ... there should really be no way I could influence Apple in
this regard. IE: this isn't some elaborate, hard to define bug. This better
not be an accident that requires energy from someone as insignificant as me
.... to ask that secure text fields not echo their contents in Plaintext.
I guess its no big deal when you think of the naive device use case - where
someone could simply watch your fingers type on the virtual keyboard ...
but demos are often on mirrored devices or sometimes use hardware keyboards
or are fired up the simulator and displayed on the big screen as the team
watches in earnest to see the week's progress.
Again, I'm OK with it. I like writing custom controls. Just find it
interesting ... there has to be _some_ reason we haven't uncovered yet :)
Wanted to see if anyone had an elegant solution or if I'd missed something
in the API.
On Wed, Mar 5, 2014 at 2:52 PM, Fritz Anderson <email@hidden>wrote:
> 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