Re: secure uitextfield is not secure
I believe it's because of the virtual on-screen keyboard - this way you can verify whether the character you typed has uppercase or not, since the virtual keyboard has no "Caps Lock" LED on it, or just because the iPhone screen keyboard keys are so small, it's easy to make a typo when entering your password. I do wish they (Apple) would make it so that if you're using a wireless (bluetooth) keyboard, that it would - in fact - hide the on-screen character(s) in a secure TextField. But this behavior has been around since at least when they called it iPhone OS, I believe... I could be wrong. HTH! On Mar 5, 2014, at 1:17 PM, Luther Baker 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? > > And, is there any way I can turn this off? > > 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. > > I guess one could write something to work around this ... 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. > > -Luther > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/wsquires%40satx.rr.com > > This email sent to wsqui...@satx.rr.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
On 05 Mar 2014, at 23:57, Quincey Morris wrote: > Incidentally, having a “fully obscured” custom text field won’t help you in > the demo scenario, because the audience can still see the key images pop up > on the keyboard as you type. Are you proposing removing that feedback too? > (And how will you do that?) Unless you’re recording, the key caps popping up is less of an issue. They pop up in different places, so an audience member’s or shoulder-surfer’s eyes have to follow the cap as it’s popping up and read it that moment. At the usual typing speed, by the time my eyes have jumped to the key cap, it has closed already. On the other hand, in the text field it is obvious where the next character will pop up, and they show up in the proper reading order, so it is so easy to read a password I often do it accidentally. >> 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 > > I agree with the earlier post which said (more or less) that if it’s your job > to demo stuff, then it’s also your (your company’s) responsibility to provide > a non-secure demo platform, or a non-secure account. Definitely. If data is confidential enough to protect by password access, you should be using a demo server with dummy data. That’s better for a demo anyway. If you can run that demo server locally, you’re insulated from network issues during your demo like other users eating up all the bandwidth or Wifi interference. If, for some reason that is not an option (why?), having single-use accounts or accounts with pseudo-random single-usepasswords is probably the best. That way, even if someone sees the password onscreen, it has already changed by the time an audience member might enter it. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
On 05 Mar 2014, at 23:17, Alex Kac wrote: > Perhaps a good bug report is that the user’s screen works the same way it > does now, but if its mirrored - then the mirrored screen keeps he password > hidden. That would be a good use case. That’s a very presenter-specific use case. I have quite a lot of fun at conferences/concerts whispering peoples’ passwords back to them from the seat behind them as I accidentally shoulder-surf them. For a mobile device, this is the wrong solution. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
Hey -- this is all good stuff! I'm definitely a bit less cynical about this topic now. Thanks for the virtual turn-around! On Wed, Mar 5, 2014 at 5:41 PM, Kyle Sluder wrote: > On Wed, Mar 5, 2014, at 02:57 PM, Quincey Morris wrote: > > I agree with the earlier post which said (more or less) that if it's your > > job to demo stuff, then it's also your (your company's) responsibility to > > provide a non-secure demo platform, or a non-secure account. > > Take Luther's app out of the equation. > > Due to plenty of circumstances beyond the control of the user (timeouts, > etc.), it may be necessary to reauthorize to some service during the > course of presenting data via AirPlay. There is *no way* to securely use > passwords in combination with AirPlay. > > This is a design problem that falls under the same umbrella as "bad > defaults". The user can optionally cancel whatever password prompt has > appeared (and keep canceling if the software in question persists in its > demand), disconnect from AirPlay, enter the password, reconnect to > AirPlay, and return to the place they left off. > > But that's cumbersome. Instead, the software encourages the user to > enter their password live and on the air. > > As I opined in an earlier thread, when AirPlay is engaged > UISecureTextField should disable echo of the last character. Thanks > Quincey for reminding me that the balloon keycaps should also be > disabled. > > --Kyle Sluder > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
On Wed, Mar 5, 2014, at 02:57 PM, Quincey Morris wrote: > I agree with the earlier post which said (more or less) that if it’s your > job to demo stuff, then it’s also your (your company’s) responsibility to > provide a non-secure demo platform, or a non-secure account. Take Luther's app out of the equation. Due to plenty of circumstances beyond the control of the user (timeouts, etc.), it may be necessary to reauthorize to some service during the course of presenting data via AirPlay. There is *no way* to securely use passwords in combination with AirPlay. This is a design problem that falls under the same umbrella as "bad defaults". The user can optionally cancel whatever password prompt has appeared (and keep canceling if the software in question persists in its demand), disconnect from AirPlay, enter the password, reconnect to AirPlay, and return to the place they left off. But that's cumbersome. Instead, the software encourages the user to enter their password live and on the air. As I opined in an earlier thread, when AirPlay is engaged UISecureTextField should disable echo of the last character. Thanks Quincey for reminding me that the balloon keycaps should also be disabled. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
On Mar 5, 2014, at 14:05 , Luther Baker wrote: > 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 to emphasize: I wasn’t making a witticism. It’s a genuine problem — especially given that in some cases entering multiple incorrect attempts will get you locked out of an account. Showing the password in plain text while it’s being typed *isn’t* a flaw from my point of view. Incidentally, having a “fully obscured” custom text field won’t help you in the demo scenario, because the audience can still see the key images pop up on the keyboard as you type. Are you proposing removing that feedback too? (And how will you do that?) > 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 I agree with the earlier post which said (more or less) that if it’s your job to demo stuff, then it’s also your (your company’s) responsibility to provide a non-secure demo platform, or a non-secure account. Your position is a bit inconsistent here. You can’t express disappointment in Apple’s lack of assiduity, and simultaneously say it’s too much trouble for you to take elementary steps to avoid exposing your keystrokes (e.g. pasting in the password, or disconnecting your device from the public display while you log in, or providing test credentials, etc). ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
On Mar 5, 2014, at 3:05 PM, Luther Baker wrote: >> 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. Filing a bug *is* how you influence Apple. Or, buy a few million shares. Or become a head of engineering. I mean seriously, if everyone had the same amount of influence, then iOS would be Android. > 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. Perhaps a good bug report is that the user’s screen works the same way it does now, but if its mirrored - then the mirrored screen keeps he password hidden. That would be a good use case. > > 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. The good reason was already provided - MOST people cannot enter a password on a soft keyboard without seeing the character they just pressed. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
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 wrote: > On 5 Mar 2014, at 1:17 PM, Luther Baker 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
Re: secure uitextfield is not secure
On 5 Mar 2014, at 1:17 PM, Luther Baker 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
Maybe using a custom font containing nothing but bullets for the secure UITextField? I don't know if that would work or not. - Eric Google Voice: (508) 656-0622 Twitter: eric_dolecki XBoxLive: edolecki PSN: eric_dolecki On Wed, Mar 5, 2014 at 2:43 PM, Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > On Mar 5, 2014, at 11:17 , Luther Baker 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? > > 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. Seriously. > > While there does seem to be good reason for some direct solution in the > scenario you describe, one alternative is to use a password manager to > copy/paste in the password instead of typing it. (Of course, you need to > unlock the password manager privately first.) > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/edolecki%40gmail.com > > This email sent to edole...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: secure uitextfield is not secure
On Mar 5, 2014, at 11:17 , Luther Baker 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? 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. Seriously. While there does seem to be good reason for some direct solution in the scenario you describe, one alternative is to use a password manager to copy/paste in the password instead of typing it. (Of course, you need to unlock the password manager privately first.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
secure uitextfield is not secure
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? And, is there any way I can turn this off? 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. I guess one could write something to work around this ... 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. -Luther ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
