Live data from Hacker News

Chrome's insane password security strategy

blog.elliottkember.com

161–170 of 315 posts

Re: Chrome's insane password security strategy

#161
post #156

Earlier quoted context omitted.

Did you test your assertion? Go to amazon right now and try to change your password without having to enter your password first.

My browser fills in that password for me. My guess is that would be the same for most people.

Your browser fills in the "current password" when you try to change your password on amazon.com? How'd you manage that? I have my password saved for amazon, and I don't have to type it to log in, but it doesn't get filled in automatically on the "change password" form (because that'd be stupid).

Re: Chrome's insane password security strategy

#162

Earlier quoted context omitted.

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 prob…

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..

Re: Chrome's insane password security strategy

#163
post #149

Earlier quoted context omitted.

If chrome ever removes that setting, I will make chromereveal.com with one-click idiot-proof password dumping tool, and step-by step instructions. So hiding that button will not make it harder for your friends. Just logout and give them guest access...geez.

So you log out of your computer every time you give your computer to your wife?

To be fair I don't know of any passwords my wife can't know about. But I know that's barely an argument :-)

Re: Chrome's insane password security strategy

#164

Earlier quoted context omitted.

Hey Justin, I'm the author. I appreciate your sentiments, but I feel like they may be out of touch with the way real people are using computers in the wild. My suggestion is to seriously re-evaluate this approach in light of the actual use-case of how people perceive these passwords. It appears as though many, many users don't expect these passwords to be visible. This is an important thing to take into consideration…

I appreciate how this appears to a novice, but we've literally spent years evaluating it and have quite a bit of data to inform our position. And while you're certainly well intentioned, what you're proposing is that that we make users less safe than they are today by providing them a false sense of security and encouraging dangerous behavior. That's just not how we approach security on Chrome.

So,the Google response is - "a) You're stupid and don't understand. b) If a techie had access to your PC for half an hour he can get your passwords anyway, so letting an amateur get it in 5 seconds is OK, c) We're Google. We don't do evil. And you're stupid.

Re: Chrome's insane password security strategy

#165

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.…

Have to say Justin - your' doing an excellent impression of that Don Mattrick chap at M$. In case your memory is as bad as your ability to listen to what your products users are telling you; Don was the chap who when prompted on the new xbox DRM answered

"if people want to play a games console thats not connected to the internet we already have a product for them - it's called the xbox360"

Worth noting that he no longer works for M$.

Re: Chrome's insane password security strategy

#166

Earlier quoted context omitted.

Soft boundaries within the user account do nothing to protect you from exactly those scenarios either. Your protection is to lock your OS user account.

Hey Justin, I'm the author. I appreciate your sentiments, but I feel like they may be out of touch with the way real people are using computers in the wild. My suggestion is to seriously re-evaluate this approach in light of the actual use-case of how people perceive these passwords. It appears as though many, many users don't expect these passwords to be visible. This is an important thing to take into consideration…

Something for consideration, Chrome...it's not JUST security against badguys, it's also security against family members (aka, 13 year old son or daughter) who want to know what your password is so that they can do things online that you don't want them to do. You just can't make it EASY for people to SEE passwords. Sure, hacker badguys and even 13 year olds may get access to this information, but why make it easier for them to access? Or make it impossible for users NOT to import their passwords?

I'm glad I have never clicked "save my password" on any browser.

Re: Chrome's insane password security strategy

#167

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.…

Yes, I can't believe people trusted those little gold locks on their diaries when they were teenagers. Didn't they know that someone malicious could just force that with a modicum of strength?

Hiding passwords doesn't protect against someone malicious; it's enough of a speedbump to mean you don't need to be vigilant over all of your computers every second of every day.

Say you have a party with your friends, and are playing music through your laptop. What if you want to use the bathroom? Do you have to lock your PC? Is leaving the room "risky behaviour"?

Re: Chrome's insane password security strategy

#168

Earlier quoted context omitted.

Am I sure? Well I was tripping balls on acid at the time so no /sarcasm

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.

Re: Chrome's insane password security strategy

#169

Earlier quoted context omitted.

fwiw Pidgin takes this same approach for the same reasons. https://developer.pidgin.im/wiki/PlainTextPasswords "locking" the passwords would require intermittent master-pass entry like `sudo`, this would come off as an inconvenience to many users. I think people here miss the fact that many users, even if they say they want more security, are unwilling to give up convenience and will switch platforms (i.e. browsers)…

However, Pidgin “would encourage integration with keyrings” [0]. At least on OS X Chrome uses the integrated keychain and as Elusive mentioned [1] it apparently does encrypt passwords on Windows too. So, I think Pidgin’s situation is a bit different and if they would have keychain integration they may solve this differently than Chrome does right now. [0]: https://developer.pidgin.im/wiki/PlainTextPasswords#Isthatth.…

On OS X Chrome pulls the passwords out of the keychain and then makes them completely accessibly in plaintext through the settings/passwords page. I have no idea why it does this.

Re: Chrome's insane password security strategy

#170

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.…

You say you do not wish to lull users into a false sense of security. So why not clearly tell people each time Chrome saves a password that the saved password will be visible in plaintext by visiting chrome://settings/passwords ?

Otherwise you are lulling people into a false sense of security.

E.g., to view passwords in my coworker's Keychain, I have to at least enter their account password to show the plaintext. To view their web passwords (which probably overlap significantly with their Keychain) all I have to do is open Chrome. I often use my coworkers computers for minutes at a time, and they use mine.

This flaw actually makes it possible to read their passwords — something not possible using other methods within seconds or minutes as they step out of the room.

Post reply on HN