As you know, a system is only as secure as its weakest component. (Yes, everything is fundamentally broken and insecure, but that's no excuse for writing more crap software.) As a browser, it's impossible to secure all parts of the system (and that's not your job), but it's not okay to be the weakest component and not care about this. By virtue of providing a clear listing of all passwords and neither warning about this nor giving the user a choice, Chrome clearly is the weakest part in this.
Passwords added that way require confirmation for access, do not require entering the keychain password, and the application adding the password is auto-whitelisted (which overrides confirmation for access) -- which matches what I see on Chrome passwords.
This means that the default way of creating internet passwords in the Keychain provides only weak security (sigh, Apple), because the creating application can always access the password. (Same applies to Safari, only it doesn't provide a nice list of passwords as far as I can tell.)
-----
I agree that trying to add access control inside Chrome is nonsense – Chrome can access the passwords and you'll (probably) always be able to trick it into revealing things. But that's not the only thing you can do – it's relatively easy to fix the bad default behavior and disallow access for Chrome unless the user (via Keychain prompt) explicitly allows it.
When storing a new password, offer to always require the keychain password for access.
If the user chooses this option, use the lower-level API to create the entry (or use the default function and modify / add modified / delete old – there's code for that in the chrome repo) and use an ACL that has (1) an empty (but not NULL!) trusted application list, (2) the $blah_REQUIRE_PASSPHRASE bit in the prompt selector set. As a result, Chrome will not be able to access the password without the user explicitly allowing it.
If the user always chooses the secure option when saving passwords, no one can access them without entering the keychain password or significantly mucking with the system. If that breaks, it's not your fault.
That's a fundamentally different situation – it's hard to fail to protect passwords that you cannot access(^1)!
(^1) at least not without other parts failing first
-----
From the source, it seems Chrome adds password using `SecKeychainAddInternetPassword` (see http://developer.apple.com/library/mac/documentation/Securit... ).
Passwords added that way require confirmation for access, do not require entering the keychain password, and the application adding the password is auto-whitelisted (which overrides confirmation for access) -- which matches what I see on Chrome passwords.
This means that the default way of creating internet passwords in the Keychain provides only weak security (sigh, Apple), because the creating application can always access the password. (Same applies to Safari, only it doesn't provide a nice list of passwords as far as I can tell.)
-----
I agree that trying to add access control inside Chrome is nonsense – Chrome can access the passwords and you'll (probably) always be able to trick it into revealing things. But that's not the only thing you can do – it's relatively easy to fix the bad default behavior and disallow access for Chrome unless the user (via Keychain prompt) explicitly allows it.
When storing a new password, offer to always require the keychain password for access.
If the user chooses this option, use the lower-level API to create the entry (or use the default function and modify / add modified / delete old – there's code for that in the chrome repo) and use an ACL that has (1) an empty (but not NULL!) trusted application list, (2) the $blah_REQUIRE_PASSPHRASE bit in the prompt selector set. As a result, Chrome will not be able to access the password without the user explicitly allowing it.
If the user always chooses the secure option when saving passwords, no one can access them without entering the keychain password or significantly mucking with the system. If that breaks, it's not your fault.
That's a fundamentally different situation – it's hard to fail to protect passwords that you cannot access(^1)!
(^1) at least not without other parts failing first