Keychain access management and MacFixIt
Posted by Pierre Igot in: MacintoshSeptember 10th, 2003 • 9:14 pm
It had to happen… I’ve just written an item about the fact that I did not renew my MacFixIt Pro subscription because I didn’t feel I was getting my money’s worth… and today, I find an item on the site (“Troubleshooting .Mac Backup 2.0 Beta”, dated September 9) that will remove a significant Mac OS X annoyance for me!
My problem is not with the Backup 2.0 application. I’ve downloaded it, but haven’t tried it yet. But apparently the beta application has some problems with user name / password authentication, and a MacFixIt reader notes that, by default, new password items added to the Mac OS X keychain are set to “confirm before allowing access”. Using the Keychain Access utility (included in Mac OS X’s Utilities folder), however, you can change a password item’s settings to “always allow access to this item”.
What difference will it make? Well, in my case, each time I had to restart my computer (after a system UPDATE or a power outage), Mac OS X would ask me to confirm that I wanted to allow access again for each and every password item in my keychain. I have 18 different email accounts in Mail, and each of them has its own password item in the keychain. Safari has a password item in the keychain for the Forms AutoFill feature. Etc. That makes quite a few confirmation dialogs that I had to dismiss one by one by clicking on the “Always Allow” button before I could start using my Mac OS X work environment again.
I’d always wondered why I had to confirm it, since the confirmation process didn’t require that I enter my keychain password again anyway. It seemed a bit silly to me. Now, thanks to MacFixIt, I know. It’s because the default behavior for password items in the keychain is to ask for confirmation (but not ask for the keychain password). By changing the setting for each password item to “Always allow access to this item”, I should be able to eliminate all these unnecessary dialogs. (I still don’t really understand the purpose of the confirmation dialog, but that’s probably just me.)
So there you go… A valuable piece of information from MacFixIt, for a change! Of course, the information happens to come from a MacFixIt reader, not from MacFixIt themselves… which has always been part of the problem. How do you justify charging for access to information provided by readers, and not compensating the contributing readers for it?
This doesn’t really change my opinion of the web site, however. For example, their first item for September 9 is a very old tip about improving the AirPort reception of the Titanium PowerBook by removing the battery and pressing on the side of the battery compartment. This is ancient information that has been mentioned all over the place in the past couple of years, and on top of it, as far as I can tell, it doesn’t really work. (I’ve tried it on a couple of TiBooks, including my own, to no avail. AirPort reception is still poor. This kind of posting is simply not very professional.
September 10th, 2003 at Sep 10, 03 | 11:58 pm
I don’t think your analysis about the keychain is correct. You don’t have to acknowledge access to the password in question because of the restart but (potential quirks in OSX aside) because the application wanting to use that password was updated.
I think this is an important security feature of the keychain. This should prevent malicious software from being able to pose as Mail.app, say, and steal your passwords. Even with malicious software, the current solution will warn you that a different/changed program wants to access your passwords.
I wouldn’t easily give up this security feature by granting access to any application. If you do, writing a program that extracts your passwords and mails them back to me, say, should become an easy exercise.
And the good news is: According to some remark on some rumor mill (AppleInsider forums, I think), X.3 seems to have the option to select ‘upgrade all passwords to new application version’ instead of allowing access to every single one separately. That’s probably just what you want – a definitely better than relaxing the security of your keychain.
September 11th, 2003 at Sep 11, 03 | 12:19 am
Mmm, I think we’re dealing with OS X quirks here… Because, although I am not 100% sure, I remember quite clearly that Safari asked me to allow access again just the other day, and the application has not been modified in a while (1.0, last modified on 24/06/03).
The other thing that makes me think we have quirks here is that, for many password items in the keychain, including all my email account passwords, I had 5 or 6 duplicate entries for the same application. For example, for my main email account, I had 6 times the exact same entry “/Applications/Mail”. Although I suppose that it might just correspond to the several application updates you are referring to.
I don’t think the confirmation dialog is very clear about why it is asking for confirmation. It just says, “The application XXX wants to access your keychain. Are you sure” blah blah blah.
I see what you mean about not always allowing access for ANY app. I shall change my settings back then. But the next time I get a confirmation dialog and it is NOT, as far as I know, because of an updated application, I’ll write again :).
Thanks for the clarification. The thing it boils down to, however, is, once again, insufficiently clear human interface.
September 11th, 2003 at Sep 11, 03 | 11:33 pm
I think you have to confirm after every security update too. The last one was august 14.
September 12th, 2003 at Sep 12, 03 | 12:56 am
I see. Even if the security update doesn’t change the Mail application? Sounds like overkill to me.
Thanks for the tip.
September 12th, 2003 at Sep 12, 03 | 3:07 am
A disclaimer first: While I hope that I’m right with the following it may not be 100% correct due to my lack of complete technical understanding.
You seem to need to re-confirm access to the keychain by an application if that application has changed. Any update to the underlying system may change any application’s binary as it runs update_prebinding after the installation to update the references to some functions that may have changed.
So if some library is changed, many applications may change with it.
In a way this makes sense, as an application may become untrustworthy if some of the libraries it uses are updated. (Although I consider this a mostly theoretical problem as the end user will find it hard to find these things out).
At least this give a sort-of consistent explanation of the phenomena while being in-line with what I’ve read about how the system works.
Now for my four hours of sleep…
September 12th, 2003 at Sep 12, 03 | 5:47 am
I think I understand what you are saying, and it sounds reasonable to me.
My main issue here would be rather that the user interface for keychain access is far from clear about all this. If the confirmation is requested because of a change in the application that would justify some degree of caution, then the confirmation dialog itself shoud say so, and should tell the user to only confirm access if he’s confident that whatever was updated in the application does not threaten the safety of his information.
OTOH, if the confirmation is requested for a brand new application (newly installed and launched for the first time), then the warning should be to the effect that this is a new application and that the user should be aware that, by giving access to an existing password to this new application, he’s taking a bit of a chance. He should be confident that the application will not do anything suspicious with his password information.
I guess that’s what my post was about from the beginning. I just didn’t phrase it clearly enough. But your clarification of the technical side of things made the need for me to clarify my own comments more apparent :).
Thanks again — and get some sleep. We all need some :).