22 ms·

Chrome's insane password security strategy

106 points by elliottkember 13y ago

stephenr 13y ago
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.
- grey-area 13y ago
  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? https://code.google.com/p/chromium/ https://code.google.com/p/chromium/ or Tools > Report an issue...
  - stephenr 13y ago
    A mistake..? So they accidentally wrote code to copy your credentials and create a new keychain item which Chrome has permanent access to?
    - masklinn 13y ago
      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.
    - grey-area 13y ago
      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.
      - stephenr 13y ago
        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.
        aboustayyef 13y ago
        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..
  - aidos 13y ago
    I'm not so sure. You have to deliberately write that code.
- magicalist 13y ago
  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.
  - stephenr 13y ago
    Am I sure? Well I was tripping balls on acid at the time so no /sarcasm
    - magicalist 13y ago
      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 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.
      - stephenr 13y ago
        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.
- delinka 13y ago
  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?
est 13y ago
has op used any other browser before? They all store pwd in the same way
- elliottkember 13y ago
  "That’s just how password management works", right?
- deleted 13y ago
  [deleted]
- masklinn 13y ago
  > They all store pwd in the same way No. 1. Safari stores its passwords in Keychain (OSX's built-in password manager), in which a master password (the account's password) is required to get cleartexts. Safari itself does not give direct access to the passwords list. 2. Firefox has a master password option.
- gojomo 13y ago
  Firefox does it better, allowing you to set a 'master password'. A fresh launch of the browser can't autofill fields until the master password is provided. The settings page for saved passwords won't show them in plaintext unless the master password is provided again. It's not very onerous and it prevents quick, casual swiping of passwords. (Sophisticated attackers could navigate to a fresh login prompt and use DOM-manipulation... but that's also more time-consuming and doable by far fewer people.)
danielsamuels 13y ago
Weird, I have all of my passwords saved in Chrome, but going to chrome://settings/passwords shows 2 empty lists. I wonder if it's because I encrypted my sync data or something.
gpachov 13y ago
Added to my long list of reasons why I am not switching to Chrome.
- kirab 13y ago
  Same is true for Firefox btw :-)
  - mariusmg 13y ago
    Do you have the "master password" thingie in Chrome ? Anyway...this is what happens when you optimize for "usability" over security. Microsoft used to get a lot of flak over this.
nightcracker 13y ago
No, no, no, no, NO! What do you think "store password" means, when you click it? If you can fire up your browser and log in without ever typing in a password how could you EVER assume your passwords are stored in anything but plaintext? I'm sorry, this article just shows stupidity of the user rather than "Chrome’s insane password security strategy".
- elliottkember 13y ago
  Logging in without typing a password is quite different from making your password visible in plain text. I take it you're a developer.
  - makomk 13y ago
    Your password is available in plain text either way. Not displaying it just give users the illusion that someone can't run off with it, whilst making their lives harder if they need to log in somewhere else.
  - nightcracker 13y ago
    No it is not. Without taking any secret information from the user not available/stored in the system itself there is no way to store a password on a system that is not trivially retrievable by someone who has access to the computer.
    - throwaway2048 13y ago
      the OSX keychain encrypts passwords with your login password, and can be set to unload keys/passwords after a timeout, it is very much not stored as plain text.
    - AlisdairO 13y ago
      Why would a non-technical user know that? Even if they could work it out if prompted to think about it, there's nothing to suggest to them that they ought to.
- voltagex_ 13y ago
0x0 13y ago
I did "Reset Safari..." once, and it wiped all my Chrome passwords. Guess they're all stored in the Keychain! But the wording on both Safari's and Chrome's end isn't helpful. "Reset Safari" shouldn't mean "Reset your Keychain", and "Do you want Google Chrome to save you password" should probably be reworded to "Do you want to save your password in the OS X Keychain". :(
panacea 13y ago
To those saying this isn't insane... you are wrong. I can open anyone's chrome browser and access their passwords without a master password? That's plain fucked up. (I realise I could visit sites and use password reset, but this is so frictionless as to be insane)
- victorhooi 13y ago
  Well, the assumption is, if you cared at all about security, you would actually have a login password, and bother locking your computer? Or you might not just let random people sit down at your laptop and start using it without you being there?
  - interpol_p 13y ago
    That is not a good assumption. People care about their security and also care about the convenience of being able to let a friend or co-worker use their computer for seconds or minutes at a time without all their passwords being easily discovered. If I debug some code on a friend's machine he would not expect me to be able to open his Keychain and read his passwords. I would need a master password for that. Chrome should do what Safari does — ask for a master password before unmasking other passwords. It would prevent a scenario where one can look up another's passwords inconspicuously and without trace in seconds.
    - victorhooi 13y ago
      Err, I think that's a bit of a strawman fallacy. If you leave your computer unlocked in a public area, that's asking for trouble - which is the example I was referring to. However, in your example, you cited giving your machine to a friend to debug code - in that case, you either trust your friend, or you don't. If you don't trust your friend, why are you giving them your machine then. It's like asking your friend to collect your letterbox mail - do you trust them enough to not open and read your mail? If you don't, then why are you entrusting them to collect your mail?
      - 13y ago
gbin 13y ago
On KDE chrome asks me my kwallet password (local keychain) every time ... Maybe this "complication" is too much for a stsndard MacOS user ?
- masklinn 13y ago
  The "complication" is the standard behavior of safari and indeed of the entire OS as far as credential storage goes. So I'll go on a limb there and say that no, it's not.
kirab 13y ago
I’d rather have them show the passwords with a "show" button so the browser doesn’t give the user an idea of a fake security, because the other option would be a pseudo encryption. Most people would think it’s safe while actually someone with a little bit of knowledge could download a tool or even a browser extension which would just dump all stored passwords..
- interpol_p 13y ago
  In that case Chrome should clearly tell users that their passwords will be readable at chrome://settings/passwords when it saves a password. Otherwise it's a false sense of security, right?
cliveowen 13y ago
This is hardly news but I found it very useful from time to time. Sure, asking for the master password would be the secure way to go but it would also be a pain in the ass. Your account should be protected by a password and you should log out when you're not around your computer. If you fail to do so it's your fault and no one else's.
runn1ng 13y ago
Shock! Firefox is insafe too! Call the presses, write the blogs! Go to any page where browser (Chrome or Firefox) pre-fills password. Click on the password, click on "inspect element", change the type of the form input from "password" to, say, "pasword". You just broke the internet security.
- rorrr2 13y ago
  Firefox does have a master password.
  - MLR 13y ago
    I really, really wish there was some way to set it so it wouldn't access your cookies or something unless you put in the master password. Always seemed like a bit of a flaw that while you can't log in to other sites or view the passwords, you could still access any sites you were already logged in to.
    - rorrr2 13y ago
      Well, websites control their cookies, so it's up to them to determine how secure they want to be. They can even encrypt them if they wanted to.
      - masklinn 13y ago
        No, browsers control their cookies. MLR's point is the ability to password-protect cookies reading and sending, to prevent third-parties from being able to use your account on site you're already logged in
  - runn1ng 13y ago
    Oh. That is, actually, pretty nice.
- garethadams 13y ago
  For completeness (I assume the answer is yes, but since you weren't clear): Does FireFox have a corresponding settings page with the list of all of the pages it knows a password for?
aa0 13y ago
Given that the input password type auto filled by browsers offers no security, I propose a new standard input type called passwordhash. <input type='passwordhash' hash='sha256' salt='26:$:9' editable='false'> The actual password would have to be backed in RAM if the field is set to editable. But if it isn't, upon editing it would clear the current input. Having hashes stored instead of actual passwords is of course not a total solution because someone savvy enough could use those same hashes to login to your services - but it definitely is better than plaintext - and will help stop novices from jacking your passwords. This of course requires both web dev and browser acceptance, I believe it's the future way to go With the salt option, a website could use a different salt for changing your password or for doing certain 'secure' actions. This would prevent wholesale catastrophe when an account is hijacked, effectively a salt-based level system. Thoughts?
- Tinned_Tuna 13y ago
  If we're up for changing the standard, why not go with something that's significantly better than pass the hash, like some form of public-key crypto? Having <input type='challenge' algo='xxx' challenge='reallylongrandomchallengetoken'> would work better than yours, I think? There's also nothing stopping the user using a "password", where that password is fed through a KDF and then used to generate the relevant private key (all done client side) -- but this is only as strong as the password used, so a really savvy user would just generate the private-key really well, and store that in a similar way to the way SSH keys are stored (i.e. passphrase). Non-savvy users can generate it a-fresh every time. But aren't we just re-implementing client-side SSL certifications?
- throwaway2048 13y ago
  in this scheme the hash effectively becomes your password, how is this helping anything ?
  - aa0 13y ago
    Did you read my whole post? With the salt attribute, a level based system can be implemented -- effectively a different hash would be required for more critical user-actions. That is, you'd need to re-type your password in the website to perform certain actions - but it would be the same password - just a different salt.
victorhooi 13y ago
tl;dr - You're holding it wrong. Seriously, is the HN audience really that non-technical these days? Lol. I don't know what the clown who wrote that post is thinking, or the person that submitted it was, but seriously, how the heck did you think password storage works? It's like when everybody got up in arms about Pidgin storing passwords in cleartext. Heck, they even made a page explaining the rationale: https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords I encourage the author as well as the submitted to read that. Anything you did to obscure it would just give you a false sense of security.
- voltagex_ 13y ago
  Even encrypting the password store on-disk? What's Keepass doing?
  - rpsw 13y ago
    That would be the first approach mentioned in the Wiki article: Store a password(s) behind a password In KeePass, a passphrase or a key file act as the encryption key.
- stephenr 13y ago
  I don't know what you're thinking. Storing multiple encrypted passwords behind a single "master" password (in the case of Windows and OSX its usually the OS level User password) is a common way to provide convenience and security for users.
  - victorhooi 13y ago
    Well, that's what a login password and a lockscreen are for. I mean, these things are secure and well-tested - I'm not sure why people aren't using them? Do you somehow think that your OS is more insecure? I don't think you've exactly explained what exactly you're trying to protect against. Is it casual attacker who happen to chance upon an unattended computer? Well, in that case, either your computer is locked, or it's pretty much game over. There is no additional security you can get by just obfuscating it.
martinml 13y ago
Chrome delegates the protection to the OS[1], which I think is a good idea from the user experience perspective. The case of "somebody used my computer and saw all my passwords" is solved by setting a password in your OS and locking your session when you're not there. The problem here would be if some malware were to steal your passwords when logged on, but then not even a dozen of master passwords can save you (just install a keylogger and wait!). [1] http://superuser.com/a/146744/7482 http://superuser.com/a/146744/7482
nisdec 13y ago
At least on Windows, Chrome uses a provided API function which makes the encrypted data only decipherable by the Windows user account used to encrypt the password. So essentially, your master password is your Windows account password. As a result, once you are logged into Windows using your account this data is decipherable by Chrome.
- interpol_p 13y ago
  Right but that's really not going to help in most situations. You've never handed your laptop to a friend to quickly check something on the web? It would be insulting if you were to explicitly logout whenever someone wants to use your computer for a few seconds / minutes. This flaw makes it easy to view passwords in seconds, and makes it easy to do so in an inconspicuous manner. It's a user interface failing more than a security issue.
MrKurtz 13y ago
The master password is that of your OS profile.
sstarr 13y ago
I had never given much thought to the implications of saving my passwords in Chrome so thanks for pointing this out. Now I'd like to remove my saved passwords but visiting chrome://settings/passwords and removing them one at a time will take forever; can anyone tell me how to remove them in bulk?
- michielvoo 13y ago
  Select the first, scroll down, hold shift and select the last, click the delete button of any row and all will be deleted. Don't forget to turn of the option to save passwords, and optionally install a password manager extension (I use 1Password).
  - sstarr 13y ago
    Thanks, the UI doesn't make it very clear that you can select rows so I missed that. I use 1Password religiously but until now I'd been lazily saving passwords in Chrome as well to avoid the hassle of entering my master password. I feel slightly ashamed that I just assumed Chrome stored them "securely" and didn't give it any more thought.
awjr 13y ago
Showed this to the team I work with. Never seen so many jaws hit the floor. This is really bad. Passwords should never be viewable through a browser settings page. If you forget a password for a site, then the site provides a mechanism for password recovery/reset.
- panacea 13y ago
  ..and if it's this trivial to look at a password, why bother with [••••••• ] when auto-filling password fields. It's misleading.
  - 0x0 13y ago
    I think that part is super useful. Sometimes I need to pull up a saved password for some common internal site, and this way I can do that comfortably even with friends or colleagues hanging over my shoulder!
    - panacea 13y ago
      Yeah, I get that... it's more of a UX failure (in light of this post) in that it suggests your password is ••••• when it's really *, but I guess that was factored into the UX considerations.
mcnemesis 13y ago
IMO if a user opts in for auto-fill, they admit that anyone having access to the browser can sign into any of their "protected" accounts. And thus, for a browser to store passwords and auto-fill them in (as plain text) is not the real problem. The problem with what Chrome is doing is that it not only allows anyone to access your "protected" resources (if they have physical access to your browser), but that they can easily peek at, and possibly export those password for use elsewhere (say on entirely different machines / apps) without you knowing or detecting this - since by then, they don't need physical access to your browser. This IMO is the BIG FLAW!
nddrylliog 13y ago
Why is this submission dead? Any ideas?
- elliottkember 13y ago
  I don't know. It went from #4 to #58 in ten minutes.
justinschuh 13y ago
I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater. Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants. We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.
- niemand 13y ago
  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. ----- From the source, it seems Chrome adds password using `SecKeychainAddInternetPassword` (see http://developer.apple.com/library/mac/documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecKeychainAddInternetPassword 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
jmotion 13y ago
This has got to be a case of them being completely out of touch with the average user. I've been using web browsers for over 10 years and assumed a browser wouldn't make it this easy to find passwords. After reading this I quickly checked and saw over 50 accounts listed all with the passwords in plain text next to them. I guarantee each and every one of my friends that don't work in IT don't know about this - I could ask them all if I could quickly borrow there laptop to check a soccer score and find out the majority of there passwords. What needs to be done is make people more aware of what's happening when they save a password - and perhaps a quick pop up in the bottom right coming up notifying them which passwords are saved and if they want to clear them before lending out, or leaving it unattended.
DavideNL 13y ago
I've reported this bug on Sep 21, 2011 !! https://code.google.com/p/chromium/issues/detail?id=97510&q=reporter%3Adavidstaron%40gmail.com&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified https://code.google.com/p/chromium/issues/detail?id=97510&q=...
magoon 13y ago
I honestly can't believe people on this board are arguing to have Chrome remove the button to show these passwords, the passwords you knowingly saved into your computer and are obviously available to anybody you "lend" your signed-in computer to. Have your own sense of security and take some responsibility. You make your own decisions for sake of convenience, now you need to accept the ramifications.
dybskiy 13y ago
Seems like a great strategy to promote Chrome OS's multiple accounts feature and get people to sign-in with their own accounts.

106 points by elliottkember 13y ago

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.

grey-area 13y ago
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? https://code.google.com/p/chromium/ https://code.google.com/p/chromium/ or Tools > Report an issue...
- stephenr 13y ago
  A mistake..? So they accidentally wrote code to copy your credentials and create a new keychain item which Chrome has permanent access to?
  - masklinn 13y ago
    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.
  - grey-area 13y ago
    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.
    - stephenr 13y ago
      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.
      - aboustayyef 13y ago
        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..
- aidos 13y ago
  I'm not so sure. You have to deliberately write that code.
magicalist 13y ago
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.
- stephenr 13y ago
  Am I sure? Well I was tripping balls on acid at the time so no /sarcasm
  - magicalist 13y ago
    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 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.
    - stephenr 13y ago
      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.
delinka 13y ago
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?

est 13y ago

has op used any other browser before? They all store pwd in the same way

elliottkember 13y ago
"That’s just how password management works", right?
deleted 13y ago
[deleted]
masklinn 13y ago
> They all store pwd in the same way No. 1. Safari stores its passwords in Keychain (OSX's built-in password manager), in which a master password (the account's password) is required to get cleartexts. Safari itself does not give direct access to the passwords list. 2. Firefox has a master password option.
gojomo 13y ago
Firefox does it better, allowing you to set a 'master password'. A fresh launch of the browser can't autofill fields until the master password is provided. The settings page for saved passwords won't show them in plaintext unless the master password is provided again. It's not very onerous and it prevents quick, casual swiping of passwords. (Sophisticated attackers could navigate to a fresh login prompt and use DOM-manipulation... but that's also more time-consuming and doable by far fewer people.)

danielsamuels 13y ago

Weird, I have all of my passwords saved in Chrome, but going to chrome://settings/passwords shows 2 empty lists. I wonder if it's because I encrypted my sync data or something.

gpachov 13y ago

Added to my long list of reasons why I am not switching to Chrome.

kirab 13y ago
Same is true for Firefox btw :-)
- mariusmg 13y ago
  Do you have the "master password" thingie in Chrome ? Anyway...this is what happens when you optimize for "usability" over security. Microsoft used to get a lot of flak over this.

nightcracker 13y ago

No, no, no, no, NO! What do you think "store password" means, when you click it? If you can fire up your browser and log in without ever typing in a password how could you EVER assume your passwords are stored in anything but plaintext? I'm sorry, this article just shows stupidity of the user rather than "Chrome’s insane password security strategy".

elliottkember 13y ago
Logging in without typing a password is quite different from making your password visible in plain text. I take it you're a developer.
- makomk 13y ago
  Your password is available in plain text either way. Not displaying it just give users the illusion that someone can't run off with it, whilst making their lives harder if they need to log in somewhere else.
- nightcracker 13y ago
  No it is not. Without taking any secret information from the user not available/stored in the system itself there is no way to store a password on a system that is not trivially retrievable by someone who has access to the computer.
  - throwaway2048 13y ago
    the OSX keychain encrypts passwords with your login password, and can be set to unload keys/passwords after a timeout, it is very much not stored as plain text.
  - AlisdairO 13y ago
    Why would a non-technical user know that? Even if they could work it out if prompted to think about it, there's nothing to suggest to them that they ought to.
voltagex_ 13y ago

0x0 13y ago

I did "Reset Safari..." once, and it wiped all my Chrome passwords. Guess they're all stored in the Keychain! But the wording on both Safari's and Chrome's end isn't helpful. "Reset Safari" shouldn't mean "Reset your Keychain", and "Do you want Google Chrome to save you password" should probably be reworded to "Do you want to save your password in the OS X Keychain". :(

panacea 13y ago

To those saying this isn't insane... you are wrong. I can open anyone's chrome browser and access their passwords without a master password? That's plain fucked up. (I realise I could visit sites and use password reset, but this is so frictionless as to be insane)

victorhooi 13y ago
Well, the assumption is, if you cared at all about security, you would actually have a login password, and bother locking your computer? Or you might not just let random people sit down at your laptop and start using it without you being there?
- interpol_p 13y ago
  That is not a good assumption. People care about their security and also care about the convenience of being able to let a friend or co-worker use their computer for seconds or minutes at a time without all their passwords being easily discovered. If I debug some code on a friend's machine he would not expect me to be able to open his Keychain and read his passwords. I would need a master password for that. Chrome should do what Safari does — ask for a master password before unmasking other passwords. It would prevent a scenario where one can look up another's passwords inconspicuously and without trace in seconds.
  - victorhooi 13y ago
    Err, I think that's a bit of a strawman fallacy. If you leave your computer unlocked in a public area, that's asking for trouble - which is the example I was referring to. However, in your example, you cited giving your machine to a friend to debug code - in that case, you either trust your friend, or you don't. If you don't trust your friend, why are you giving them your machine then. It's like asking your friend to collect your letterbox mail - do you trust them enough to not open and read your mail? If you don't, then why are you entrusting them to collect your mail?
    - 13y ago

gbin 13y ago

On KDE chrome asks me my kwallet password (local keychain) every time ... Maybe this "complication" is too much for a stsndard MacOS user ?

masklinn 13y ago
The "complication" is the standard behavior of safari and indeed of the entire OS as far as credential storage goes. So I'll go on a limb there and say that no, it's not.

kirab 13y ago

I’d rather have them show the passwords with a "show" button so the browser doesn’t give the user an idea of a fake security, because the other option would be a pseudo encryption. Most people would think it’s safe while actually someone with a little bit of knowledge could download a tool or even a browser extension which would just dump all stored passwords..

interpol_p 13y ago
In that case Chrome should clearly tell users that their passwords will be readable at chrome://settings/passwords when it saves a password. Otherwise it's a false sense of security, right?

cliveowen 13y ago

This is hardly news but I found it very useful from time to time. Sure, asking for the master password would be the secure way to go but it would also be a pain in the ass. Your account should be protected by a password and you should log out when you're not around your computer. If you fail to do so it's your fault and no one else's.

runn1ng 13y ago

Shock! Firefox is insafe too! Call the presses, write the blogs! Go to any page where browser (Chrome or Firefox) pre-fills password. Click on the password, click on "inspect element", change the type of the form input from "password" to, say, "pasword". You just broke the internet security.

rorrr2 13y ago
Firefox does have a master password.
- MLR 13y ago
  I really, really wish there was some way to set it so it wouldn't access your cookies or something unless you put in the master password. Always seemed like a bit of a flaw that while you can't log in to other sites or view the passwords, you could still access any sites you were already logged in to.
  - rorrr2 13y ago
    Well, websites control their cookies, so it's up to them to determine how secure they want to be. They can even encrypt them if they wanted to.
    - masklinn 13y ago
      No, browsers control their cookies. MLR's point is the ability to password-protect cookies reading and sending, to prevent third-parties from being able to use your account on site you're already logged in
- runn1ng 13y ago
  Oh. That is, actually, pretty nice.
garethadams 13y ago
For completeness (I assume the answer is yes, but since you weren't clear): Does FireFox have a corresponding settings page with the list of all of the pages it knows a password for?

aa0 13y ago

Given that the input password type auto filled by browsers offers no security, I propose a new standard input type called passwordhash. <input type='passwordhash' hash='sha256' salt='26:$:9' editable='false'> The actual password would have to be backed in RAM if the field is set to editable. But if it isn't, upon editing it would clear the current input. Having hashes stored instead of actual passwords is of course not a total solution because someone savvy enough could use those same hashes to login to your services - but it definitely is better than plaintext - and will help stop novices from jacking your passwords. This of course requires both web dev and browser acceptance, I believe it's the future way to go With the salt option, a website could use a different salt for changing your password or for doing certain 'secure' actions. This would prevent wholesale catastrophe when an account is hijacked, effectively a salt-based level system. Thoughts?

Tinned_Tuna 13y ago
If we're up for changing the standard, why not go with something that's significantly better than pass the hash, like some form of public-key crypto? Having <input type='challenge' algo='xxx' challenge='reallylongrandomchallengetoken'> would work better than yours, I think? There's also nothing stopping the user using a "password", where that password is fed through a KDF and then used to generate the relevant private key (all done client side) -- but this is only as strong as the password used, so a really savvy user would just generate the private-key really well, and store that in a similar way to the way SSH keys are stored (i.e. passphrase). Non-savvy users can generate it a-fresh every time. But aren't we just re-implementing client-side SSL certifications?
throwaway2048 13y ago
in this scheme the hash effectively becomes your password, how is this helping anything ?
- aa0 13y ago
  Did you read my whole post? With the salt attribute, a level based system can be implemented -- effectively a different hash would be required for more critical user-actions. That is, you'd need to re-type your password in the website to perform certain actions - but it would be the same password - just a different salt.

victorhooi 13y ago

tl;dr - You're holding it wrong. Seriously, is the HN audience really that non-technical these days? Lol. I don't know what the clown who wrote that post is thinking, or the person that submitted it was, but seriously, how the heck did you think password storage works? It's like when everybody got up in arms about Pidgin storing passwords in cleartext. Heck, they even made a page explaining the rationale: https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords I encourage the author as well as the submitted to read that. Anything you did to obscure it would just give you a false sense of security.

voltagex_ 13y ago
Even encrypting the password store on-disk? What's Keepass doing?
- rpsw 13y ago
  That would be the first approach mentioned in the Wiki article: Store a password(s) behind a password In KeePass, a passphrase or a key file act as the encryption key.
stephenr 13y ago
I don't know what you're thinking. Storing multiple encrypted passwords behind a single "master" password (in the case of Windows and OSX its usually the OS level User password) is a common way to provide convenience and security for users.
- victorhooi 13y ago
  Well, that's what a login password and a lockscreen are for. I mean, these things are secure and well-tested - I'm not sure why people aren't using them? Do you somehow think that your OS is more insecure? I don't think you've exactly explained what exactly you're trying to protect against. Is it casual attacker who happen to chance upon an unattended computer? Well, in that case, either your computer is locked, or it's pretty much game over. There is no additional security you can get by just obfuscating it.

martinml 13y ago

Chrome delegates the protection to the OS[1], which I think is a good idea from the user experience perspective. The case of "somebody used my computer and saw all my passwords" is solved by setting a password in your OS and locking your session when you're not there. The problem here would be if some malware were to steal your passwords when logged on, but then not even a dozen of master passwords can save you (just install a keylogger and wait!). [1] http://superuser.com/a/146744/7482 http://superuser.com/a/146744/7482

nisdec 13y ago

At least on Windows, Chrome uses a provided API function which makes the encrypted data only decipherable by the Windows user account used to encrypt the password. So essentially, your master password is your Windows account password. As a result, once you are logged into Windows using your account this data is decipherable by Chrome.

interpol_p 13y ago
Right but that's really not going to help in most situations. You've never handed your laptop to a friend to quickly check something on the web? It would be insulting if you were to explicitly logout whenever someone wants to use your computer for a few seconds / minutes. This flaw makes it easy to view passwords in seconds, and makes it easy to do so in an inconspicuous manner. It's a user interface failing more than a security issue.

MrKurtz 13y ago

The master password is that of your OS profile.

sstarr 13y ago

I had never given much thought to the implications of saving my passwords in Chrome so thanks for pointing this out. Now I'd like to remove my saved passwords but visiting chrome://settings/passwords and removing them one at a time will take forever; can anyone tell me how to remove them in bulk?

michielvoo 13y ago
Select the first, scroll down, hold shift and select the last, click the delete button of any row and all will be deleted. Don't forget to turn of the option to save passwords, and optionally install a password manager extension (I use 1Password).
- sstarr 13y ago
  Thanks, the UI doesn't make it very clear that you can select rows so I missed that. I use 1Password religiously but until now I'd been lazily saving passwords in Chrome as well to avoid the hassle of entering my master password. I feel slightly ashamed that I just assumed Chrome stored them "securely" and didn't give it any more thought.

awjr 13y ago

Showed this to the team I work with. Never seen so many jaws hit the floor. This is really bad. Passwords should never be viewable through a browser settings page. If you forget a password for a site, then the site provides a mechanism for password recovery/reset.

panacea 13y ago
..and if it's this trivial to look at a password, why bother with [••••••• ] when auto-filling password fields. It's misleading.
- 0x0 13y ago
  I think that part is super useful. Sometimes I need to pull up a saved password for some common internal site, and this way I can do that comfortably even with friends or colleagues hanging over my shoulder!
  - panacea 13y ago
    Yeah, I get that... it's more of a UX failure (in light of this post) in that it suggests your password is ••••• when it's really *, but I guess that was factored into the UX considerations.

mcnemesis 13y ago

IMO if a user opts in for auto-fill, they admit that anyone having access to the browser can sign into any of their "protected" accounts. And thus, for a browser to store passwords and auto-fill them in (as plain text) is not the real problem. The problem with what Chrome is doing is that it not only allows anyone to access your "protected" resources (if they have physical access to your browser), but that they can easily peek at, and possibly export those password for use elsewhere (say on entirely different machines / apps) without you knowing or detecting this - since by then, they don't need physical access to your browser. This IMO is the BIG FLAW!

nddrylliog 13y ago

Why is this submission dead? Any ideas?

elliottkember 13y ago
I don't know. It went from #4 to #58 in ten minutes.

justinschuh 13y ago

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater. Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants. We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

niemand 13y ago
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. ----- From the source, it seems Chrome adds password using `SecKeychainAddInternetPassword` (see http://developer.apple.com/library/mac/documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecKeychainAddInternetPassword 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

jmotion 13y ago

This has got to be a case of them being completely out of touch with the average user. I've been using web browsers for over 10 years and assumed a browser wouldn't make it this easy to find passwords. After reading this I quickly checked and saw over 50 accounts listed all with the passwords in plain text next to them. I guarantee each and every one of my friends that don't work in IT don't know about this - I could ask them all if I could quickly borrow there laptop to check a soccer score and find out the majority of there passwords. What needs to be done is make people more aware of what's happening when they save a password - and perhaps a quick pop up in the bottom right coming up notifying them which passwords are saved and if they want to clear them before lending out, or leaving it unattended.

DavideNL 13y ago

I've reported this bug on Sep 21, 2011 !! https://code.google.com/p/chromium/issues/detail?id=97510&q=reporter%3Adavidstaron%40gmail.com&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified https://code.google.com/p/chromium/issues/detail?id=97510&q=...

magoon 13y ago

I honestly can't believe people on this board are arguing to have Chrome remove the button to show these passwords, the passwords you knowingly saved into your computer and are obviously available to anybody you "lend" your signed-in computer to. Have your own sense of security and take some responsibility. You make your own decisions for sake of convenience, now you need to accept the ramifications.

dybskiy 13y ago

Seems like a great strategy to promote Chrome OS's multiple accounts feature and get people to sign-in with their own accounts.