I just did a little digging just by visiting some sites I've saved passwords for (in Safari) using Chrome.
Chrome (on OS X at least) doesn't seem to actually store them in plaintext per-se, but what it does do is equally creepy.
When you visit a site (i used twitter.com for my test) Chrome will attempt to access any Keychain items matching that location - you should get the stanrdard Keychain Access dialog prompting you to Allow, Deny or Allow Always.
If you click deny, obviously it can't read the keychain entry.
But if you click either Allow, or Allow Always the same thing happens: Chrome creates a NEW Keychain entry with the same credentials, location etc, and set to always allow chrome to access it.
What a fucking surprise Google just does what the fuck they want with no regard for what the user has indicated they want.
I'll wait for the Google apologists to tell me it's either a) nothing to worry about or b) a harmless mistake.
I realize this story is off the front page by now, but I have some immediately recent observations to add that indicate this duplicating activity is probably a bug.
tl;dr - This duplication activity is a bug. Chrome also likes to remember incorrect passwords in these duplicate entries, thwarting attempts at usability on many of the AD-credentialed sites I visit. I have not tested this stuff with non-HTTP, non-AD authentication, but I would expect similar behavior. I've provided Google with details.
I'm a Mac developer for my company. I use a Mac running OS X. I use Chrome as my default browser. The company network has Windows servers and our network credentials are handled by Active Directory. For this test, I closed Chrome and deleted the passwords (there were three listed) and reopened Chrome.
I open TFS in a new tab, I'm prompted for my AD credentials. I enter them, log in successfully, and Chrome asks if I it should save this password for my. I answer 'Yes.' I look back at the keychain and bam there are two entries.
When I changed my AD password on Monday, Chrome needed the new password. I enter it in the prompt, but Chrome changes the password in only one of these keychain entries. Deleting the incorrect password entry while Chrome is running did no good - it was recreated by Chrome with the wrong password. Then on subsequent starts, I don't know which password Chrome is trying to use, I click 'login' without typing a password[1] and it fails. So I continually have to type my password anyway, unless I visit the keychain and remove the offending password.
[1] The prompts for AD credentials annoy me; I'm presented with the login prompt every time I open this page; can't the browser just submit the password and only prompt me if it fails?
Er, are you sure? I just tried this with Facebook and what you describe did not happen.
The access control tab in the keychain entry had Safari as the only listed application. When I then visited the site in Chrome, it asked for permission to access the keychain. When I clicked "Allow" it worked, but Chrome was not added to the "Always allow access by these applications" list and re-prompted when I refreshed the page. When I then clicked on "Always Allow", it added Chrome to the application access list, and I'm no longer prompted for access to the keychain.
At no point was an additional entry added to the keychain.
I did notice that when Safari offered to remember the password, with an additional option to make it so that only Safari could access that password. Is it possible that you clicked on that and Chrome had to create a new entry?
Edit: I tried getting that option again to test setting it, deleting the facebook entry in the keychain and then logging in again in Safari. It no longer asks me if I want only Safari to have access to that...not sure why it won't.
Let me rephrase: on a default, clean Chrome install on 10.8.4, you are wrong. If you can't find some exculpatory evidence, I'm going to assume user error, perhaps in how you have your keychain set up.
Meanwhile I see no bug on https://code.google.com/p/chromium/issues/list filed today on the topic, and you obviously don't use Chrome as your primary browser, so I'm not going to worry about you. Cheers.
What possible Keychain setting could make Chrome copy a users password into a new keychain item, with a DIFFERENT NAME and give itself full access?
I can just as easily claim you have a weird keychain/chrome setting: no one else has disputed my claim about what it does, others have even acknowledged seeing the same behaviour.
This probably is a mistake, far from harmless, but wouldn't it be better to point it out to the Chrome team and try to get it fixed. Have you logged a bug?
They're importing Safari data, so I'd expect them to copy the credentials to a new item to avoid conflicting with Safari managing that data, and creating a new keychain item with permanent access would be the correct response for 'Always Allow', so isn't it possible that's a mistake that they don't correctly respond to the Allow button? I agree storing the credentials outside keychain is not desirable, but again probably that has to do with cross-platform requirements rather than malice on the part of Google.
Have you reported the bug and asked the Chrome team about it?
In contrast to adwords defaulting to automatic payments and auto-bidding, or tracking users across the web universally over all the google services, or pushing people to use G+ everywhere, this wouldn't really benefit Google would it? I'm sure Google do lots of evil things, but I can't see any upside to them in this, and lots of downside.
Did you not read what I said? I never imported any bookmarks. I just opened Chrome, typed "twitter.com" and hit enter.
It prompted for access to the single keychain entry for twitter.com and then created it's own copy after I hit "allow".
No, it does not make any sense to create a copy, even if I was importing from Safari. If it's going to use the system keychain, it should use it in a sensible manner.
I noticed this a while ago. Google is being "evil" here in the sense that it doesn't want to use Apple's security tools (keychain access) and wants to use its own authentication methods.
The correct (apple-canon) behavior is to ask for the password every time a user wants to access her keychain (until the end of the session). This doesn't suit google which has its own security paradigm of sign-in-once-access-until-signout. This is why it creates a copy of your passwords to do whatever it pleases with..
Indeed, that doesn't point to a mistake when the right thing is 1. get the result from the query; 2. do nothing else because if the user choose "always allow" the OS itself will give Chrome permanent access.
Chrome (on OS X at least) doesn't seem to actually store them in plaintext per-se, but what it does do is equally creepy.
When you visit a site (i used twitter.com for my test) Chrome will attempt to access any Keychain items matching that location - you should get the stanrdard Keychain Access dialog prompting you to Allow, Deny or Allow Always.
If you click deny, obviously it can't read the keychain entry. But if you click either Allow, or Allow Always the same thing happens: Chrome creates a NEW Keychain entry with the same credentials, location etc, and set to always allow chrome to access it.
What a fucking surprise Google just does what the fuck they want with no regard for what the user has indicated they want.
I'll wait for the Google apologists to tell me it's either a) nothing to worry about or b) a harmless mistake.