I use the OS X Keychain, but I have the password for my keychain set to a different one than my login password. As such, when I start up one of my Macs, I see a dialog asking me to enter the password to unlock my keychain.
But I’ve often felt that this dialog is not very clear, and does not inspire trust. It mentions one of a number of different system services, none of which the average user has ever heard of. Here’s the dialog I saw after I booted my MacBook Pro today:
What is CallHistoryPluginHelper? Even I don’t know. Sometimes I see different services requesting the password, such as accountsd, or some other “d” (for daemon, or background process). I don’t know why today I saw a different process ask for the password.
The problem with this is that the dialog does not inspire trust. How do I know that it is really the system level keychain that is asking for this password? Couldn’t a third-party app toss up a similar dialog, and get me to enter my keychain password?
When it’s the Keychain Access app itself asking for the password, this dialog is different, but not by much:
Or if a different app requests access to the keychain, that app’s icon displays in the dialog:
But just after I saw the above dialog (I locked my keychain to get Mail to ask for it) I also saw this:
I don’t think that com.apple.internetaccounts.xpc is a very user-friendly name.
Apple should think about changing this dialog to make it more understandable. It’s quite an important dialog: if you do give away you keychain password to some random app, you can give away the keys to all your online accounts.
Agreed!
Agreed!
Well said!
Well said!
Ok..I agree BUT but how would this solve the potential issue?
I never thought that malware might impersonate the OS to ask for the Keychain password in this way but it could. The typically user should never see this dialog as signing in takes care of this and any request later should be suspect. In your case it will happen every time by nature your set-up.
Anyway…back to maleware…how would an average user know if any such dialog is real no matter what it looks like? I call this my “mom test” and I can say if asked my Mom would enter her password if asked.
It’s funny but as I think about it the cryptic text makes the dialog MORE not less believable. If I were a malware author I would want to make a VERY easy to understand dialog to ensure I got as many passwords as possible. The last thing I would do is throw up something like “com.apple.internetaccounts.xpc wants to use your keychain” to move a typical user to give away the store.
Maybe Apple should consider only allowing you to unlock the Keychain from the App? In this way ANY requests such as this would be bogus and while it takes more effort to open the Keychain app it would prevent fishing like this. I would say that for the average user this would be a VERY rare occurrence indeed to the need to lock and unlock from the app might be a hassle it’s impact wouldn’t be great.
Jeff, there are several solutions Apple could and should have gleaned from the Windows malware debacle to help them design this better than they did. First off, Apple has completely dropped the ball by turning Keychain and the whole concept of a system-wide secure store into a ‘red-headed stepchild’ joke (I’m a red-head, so I can totally say that. 😉 Such a service needs to be maintained, and Apple has left Keychain to whither. I mean, merely looking at how incomprehensible Keychain Access is versus a tool like 1Password et al proves this point. And it –IS– such an important service! Pretty bad. So #1 is Apple needs to focus on security and commit to actually making this something the user KNOWS about and uses. Storing credit card numbers in Safari is a hacker’s dream, SecEng’s nightmare. Apple is better than what it has given users here.
Second, by making the service something users know about and use, Apple then should spend the resources to prove TRUSTWORTHINESS with the user. As part of the user creation process (or some “Security Wizard” thereby) the user should pick a picture or pictures of Trust…when that dialog pops, it should display a picture of SOMETHING, and if it doesn’t show what you expect, there should be an easy way to eject to safety. Nothing about the current dialog even considers this. (Using pictures is effective, IMHO, but there are other similar concepts.) A rogue app trying to facsimile the dialog would never be able to present a picture to match. (Oh yeah, Apple would also need to turn off screen capture JUST for that dialog, so it can’t be scanned.)
Finally, Apple needs to stop with the “only a mother could love” naming of system processes. It used to be a joke among Mac people how undecipherable Windows executable and dll names were. And here we are. That dialog should not display such gobble-dee-gook to a user. Just laziness on Apple’s part. Every component of OS X should be labeled, have a description, and a be explainable to the layperson. If it wants a password, the least Apple can do is be accommodating to explain why. The current mess is a reflection of arrogance and hubris. That dialog should have a disclosure triangle on it that will open and let the user read what is going on…if they feel uncomfortable, “ejection” should be an option. (“Ejection”, like for a fighter pilot.) I can’t even get good documentation about what HALF of the running processes are and do NOW from Apple’s website; that’s absurd. Apple used to publish Bible-sized epic tomes of how MacOS worked, deeply describing the various components. Only laziness and greed can explain such shortcuts now ($180B in the bank).
Sure…some users can’t be bothered to read. Some have gotten so used to clicking to dismiss any and all dialogs before they read them, that it would be pointless for them. But that’s on them. Up to that point, though, Apple should be thinking of user security and helping user above all. Apple can and should do much better here, and there is a great user-benefitting opportunity for them to do so.
Ok..I agree BUT but how would this solve the potential issue?
I never thought that malware might impersonate the OS to ask for the Keychain password in this way but it could. The typically user should never see this dialog as signing in takes care of this and any request later should be suspect. In your case it will happen every time by nature your set-up.
Anyway…back to maleware…how would an average user know if any such dialog is real no matter what it looks like? I call this my “mom test” and I can say if asked my Mom would enter her password if asked.
It’s funny but as I think about it the cryptic text makes the dialog MORE not less believable. If I were a malware author I would want to make a VERY easy to understand dialog to ensure I got as many passwords as possible. The last thing I would do is throw up something like “com.apple.internetaccounts.xpc wants to use your keychain” to move a typical user to give away the store.
Maybe Apple should consider only allowing you to unlock the Keychain from the App? In this way ANY requests such as this would be bogus and while it takes more effort to open the Keychain app it would prevent fishing like this. I would say that for the average user this would be a VERY rare occurrence indeed to the need to lock and unlock from the app might be a hassle it’s impact wouldn’t be great.
Jeff, there are several solutions Apple could and should have gleaned from the Windows malware debacle to help them design this better than they did. First off, Apple has completely dropped the ball by turning Keychain and the whole concept of a system-wide secure store into a ‘red-headed stepchild’ joke (I’m a red-head, so I can totally say that. 😉 Such a service needs to be maintained, and Apple has left Keychain to whither. I mean, merely looking at how incomprehensible Keychain Access is versus a tool like 1Password et al proves this point. And it –IS– such an important service! Pretty bad. So #1 is Apple needs to focus on security and commit to actually making this something the user KNOWS about and uses. Storing credit card numbers in Safari is a hacker’s dream, SecEng’s nightmare. Apple is better than what it has given users here.
Second, by making the service something users know about and use, Apple then should spend the resources to prove TRUSTWORTHINESS with the user. As part of the user creation process (or some “Security Wizard” thereby) the user should pick a picture or pictures of Trust…when that dialog pops, it should display a picture of SOMETHING, and if it doesn’t show what you expect, there should be an easy way to eject to safety. Nothing about the current dialog even considers this. (Using pictures is effective, IMHO, but there are other similar concepts.) A rogue app trying to facsimile the dialog would never be able to present a picture to match. (Oh yeah, Apple would also need to turn off screen capture JUST for that dialog, so it can’t be scanned.)
Finally, Apple needs to stop with the “only a mother could love” naming of system processes. It used to be a joke among Mac people how undecipherable Windows executable and dll names were. And here we are. That dialog should not display such gobble-dee-gook to a user. Just laziness on Apple’s part. Every component of OS X should be labeled, have a description, and a be explainable to the layperson. If it wants a password, the least Apple can do is be accommodating to explain why. The current mess is a reflection of arrogance and hubris. That dialog should have a disclosure triangle on it that will open and let the user read what is going on…if they feel uncomfortable, “ejection” should be an option. (“Ejection”, like for a fighter pilot.) I can’t even get good documentation about what HALF of the running processes are and do NOW from Apple’s website; that’s absurd. Apple used to publish Bible-sized epic tomes of how MacOS worked, deeply describing the various components. Only laziness and greed can explain such shortcuts now ($180B in the bank).
Sure…some users can’t be bothered to read. Some have gotten so used to clicking to dismiss any and all dialogs before they read them, that it would be pointless for them. But that’s on them. Up to that point, though, Apple should be thinking of user security and helping user above all. Apple can and should do much better here, and there is a great user-benefitting opportunity for them to do so.
I have a similar issue with password requests on iOS. Sometimes, a background download from the iTunes Store will be triggered (I believe something to do with automatic downloads being switched on). I will be in a completely different app, and a generic input box will pop up requesting my Apple ID password. How easy would it be for a dodgy app to be written that mimicked this behaviour? Obviously, that was rhetorical…
I always hesitate to enter my password at that point. I have to check the app I’m currently in is at least a trustworthy one. This seems like a pretty big security loophole to me.
I don’t think that’s possible on iOS: apps can’t really run in the background. They can update data in the background, but I don’t think they can come to the front like that.
How come I get these password requests every so often then? Have you never seen these? I’ve spoken to a couple of friends who get them from time to time also.
I assume it is, as you say, automatic downloads or updates. I have them turned off, and I never see these password requests.
I don’t see them very often, but they can pop up in front of any app you are currently using. I believe it uses your Apple ID as identifying information, but it could be fairly possible to catch some people out, simply by bringing up an in-app dialog which said “iTunes Store – please re-enter your password” or something similar. People who are used to having to re-enter the password may be fooled to give their password information.
I know what @jowie74 is talking about, I’ve seen it happen. Worse, there must be some bugs involved that can make it start to happen annoyingly, ad infinitum it would seem.
What @jowie74 is getting is absolutely a current iOS vector risk: a questionable app could obfuscate its code and pop a facsimile dialog box, and 99% of users would just type in their Apple ID password. iOS’s dialog is even worse on the information than OS X’s.
I do not believe apps are privy, programmatically, to the Apple ID email address from within iOS, so that acts as a bit of a buffer. Then again, since most users only use one address it probably would not be difficult to guess the Apple ID if the app also at some point asked for an email address.
Yes… it’s not possible to access the user’s Apple ID information in the SDK, however there could be other methods that could be used to obtain that information. Both the iOS and OS X password boxes could be easily imitated by third party software.
I have a similar issue with password requests on iOS. Sometimes, a background download from the iTunes Store will be triggered (I believe something to do with automatic downloads being switched on). I will be in a completely different app, and a generic input box will pop up requesting my Apple ID password. How easy would it be for a dodgy app to be written that mimicked this behaviour? Obviously, that was rhetorical…
I always hesitate to enter my password at that point. I have to check the app I’m currently in is at least a trustworthy one. This seems like a pretty big security loophole to me.
I don’t think that’s possible on iOS: apps can’t really run in the background. They can update data in the background, but I don’t think they can come to the front like that.
How come I get these password requests every so often then? Have you never seen these? I’ve spoken to a couple of friends who get them from time to time also.
I assume it is, as you say, automatic downloads or updates. I have them turned off, and I never see these password requests.
I don’t see them very often, but they can pop up in front of any app you are currently using. I believe it uses your Apple ID as identifying information, but it could be fairly possible to catch some people out, simply by bringing up an in-app dialog which said “iTunes Store – please re-enter your password” or something similar. People who are used to having to re-enter the password may be fooled to give their password information.
I know what @jowie74 is talking about, I’ve seen it happen. Worse, there must be some bugs involved that can make it start to happen annoyingly, ad infinitum it would seem.
What @jowie74 is getting is absolutely a current iOS vector risk: a questionable app could obfuscate its code and pop a facsimile dialog box, and 99% of users would just type in their Apple ID password. iOS’s dialog is even worse on the information than OS X’s.
I do not believe apps are privy, programmatically, to the Apple ID email address from within iOS, so that acts as a bit of a buffer. Then again, since most users only use one address it probably would not be difficult to guess the Apple ID if the app also at some point asked for an email address.
Yes… it’s not possible to access the user’s Apple ID information in the SDK, however there could be other methods that could be used to obtain that information. Both the iOS and OS X password boxes could be easily imitated by third party software.
I get the com.apple.internetaccounts.xpc message every time I restart my server. The keychain it is asking after is not the login keychain for the server account, but an old keychain full of personal passwords. I don’t know why anything on the machine would be jonesing after some old personal password of mine, and I’d like to find out. So today I clicked on the “(?)” button to get detailed information about who was asking, what function it was trying to perform, and/or what password it wanted. Big surprise: clicking on this button was like clicking on my shirt button. It did absolutely nothing. That’s just wrong.
I get the com.apple.internetaccounts.xpc message every time I restart my server. The keychain it is asking after is not the login keychain for the server account, but an old keychain full of personal passwords. I don’t know why anything on the machine would be jonesing after some old personal password of mine, and I’d like to find out. So today I clicked on the “(?)” button to get detailed information about who was asking, what function it was trying to perform, and/or what password it wanted. Big surprise: clicking on this button was like clicking on my shirt button. It did absolutely nothing. That’s just wrong.