Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome's insane password security strategy

blog.elliottkember.com

Post reply on HN
Print view View original

61–70 of 315 posts

Re: Chrome's insane password security strategy

#61

Post by rpsw »

voltagex_ wrote: post #35
victorhooi wrote: post #21

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://dev…

Even encrypting the password store on-disk? What's Keepass doing?

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.

Re: Chrome's insane password security strategy

#62

Post by panacea »

Schlaefer wrote: post #57
masklinn wrote: post #41

Earlier quoted context omitted.

It's especially insane on OSX which already has an OS-wide and ~secure (more secure than this anyway) password manager: Keychain.

Note that Chrome is using keychain and that you can dump the complete keychain data with all passwords decrypted via terminal anyway. You don't need any third party software ala Chrome installed. E.g.: security find-internet-password -g -s news.ycombinator.com Klick allow and that's it. The master password question for showing individual passwords in the Keychain.app does not protect your passwords. As others said: d…

>The master password question for showing individual passwords in the Keychain.app does not protect your passwords.

That's insane too then! as it suggests/teaches that keychain passwords are master password protected.

Re: Chrome's insane password security strategy

#63

Post by stephenr »

grey-area wrote: post #53
stephenr wrote: post #9

Earlier quoted context omitted.

A mistake..? So they accidentally wrote code to copy your credentials and create a new keychain item which Chrome has permanent access to?

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.

Re: Chrome's insane password security strategy

#64

Post by stephenr »

garethadams wrote: post #39
weiran wrote: post #28

Earlier quoted context omitted.

They're not stored in plaintext, they're stored in the Keychain. The point here is Chrome provides essentially unauthenticated access to the Keychain. For reference, here's what Safari prompts you with when you try to view your saved passwords: http://imgur.com/k2gIqtM

"Unauthenticated" except for the time you told Keychain to "Always allow" requests from Chrome. However I'll admit that there's a big difference between what I expected Chrome to be using those passwords for (logging me into websites) and how it's ended up (making those visible to anyone looking at the settings page).

Chrome creates it's own keychain entries and sets them as "always allow from chrome" regardless of what the user does.

This is a problem entirely caused by Google

Re: Chrome's insane password security strategy

#65

Post by panacea »

awjr wrote: post #56

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.

..and if it's this trivial to look at a password, why bother with [••••••• ] when auto-filling password fields. It's misleading.

Re: Chrome's insane password security strategy

#66

Post by masklinn »

Schlaefer wrote: post #57
masklinn wrote: post #41

Earlier quoted context omitted.

It's especially insane on OSX which already has an OS-wide and ~secure (more secure than this anyway) password manager: Keychain.

Note that Chrome is using keychain and that you can dump the complete keychain data with all passwords decrypted via terminal anyway. You don't need any third party software ala Chrome installed. E.g.: security find-internet-password -g -s news.ycombinator.com Klick allow and that's it. The master password question for showing individual passwords in the Keychain.app does not protect your passwords. As others said: d…

> Note that Chrome is using keychain

I note that it's misusing keychain: if it's given (temporary) access to a password it will copy it to a permanent access entry.

> and that you can dump the complete keychain data with all passwords decrypted via terminal anyway.

Interestingly annoying, thanks.

Re: Chrome's insane password security strategy

#67

Post by Schlaefer »

panacea wrote: post #62
Schlaefer wrote: post #57

Earlier quoted context omitted.

Note that Chrome is using keychain and that you can dump the complete keychain data with all passwords decrypted via terminal anyway. You don't need any third party software ala Chrome installed. E.g.: security find-internet-password -g -s news.ycombinator.com Klick allow and that's it. The master password question for showing individual passwords in the Keychain.app does not protect your passwords. As others said: d…

>The master password question for showing individual passwords in the Keychain.app does not protect your passwords. That's insane too then! as it suggests/teaches that keychain passwords are master password protected.

Yes and no. If you're in the Keychain.app a user expects security question for revealing passwords.

On the other hand: if you in a third party app you just click "allow" and the app can use that password. Let's read that again: an arbitrary third party app … has access … to a password … by just clicking a button. You have probably done this many times (if you're using a Mac), but without thinking much about it (convenience).

Obviously there must be a way so that everyone can write a little app, request and access a password with a single mouse click and then show it in plain text.

(Always under the assumption that the keychain is already unlocked.)

Re: Chrome's insane password security strategy

#68

Post by masklinn »

Schlaefer wrote: post #67
panacea wrote: post #62

Earlier quoted context omitted.

>The master password question for showing individual passwords in the Keychain.app does not protect your passwords. That's insane too then! as it suggests/teaches that keychain passwords are master password protected.

Yes and no. If you're in the Keychain.app a user expects security question for revealing passwords. On the other hand: if you in a third party app you just click "allow" and the app can use that password. Let's read that again: an arbitrary third party app … has access … to a password … by just clicking a button. You have probably done this many times (if you're using a Mac), but without thinking much about it (conve…

> On the other hand: if you in a third party app you just click "allow" and the app can use that password. Let's read that again: an arbitrary third party app … has access … to a password … by just clicking a button.

It's possible to require the master password for each password release, though that is not the default and — in 10.6 — it seems there is no way to enable this globally, it has to be set individually per password as far as I can see.

Re: Chrome's insane password security strategy

#69

Post by masklinn »

rorrr2 wrote: post #55
MLR wrote: post #36

Earlier quoted context omitted.

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.

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.

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

Re: Chrome's insane password security strategy

#70

Post by Schlaefer »

masklinn wrote: post #66
Schlaefer wrote: post #57

Earlier quoted context omitted.

Note that Chrome is using keychain and that you can dump the complete keychain data with all passwords decrypted via terminal anyway. You don't need any third party software ala Chrome installed. E.g.: security find-internet-password -g -s news.ycombinator.com Klick allow and that's it. The master password question for showing individual passwords in the Keychain.app does not protect your passwords. As others said: d…

> Note that Chrome is using keychain I note that it's mis using keychain: if it's given (temporary) access to a password it will copy it to a permanent access entry. > and that you can dump the complete keychain data with all passwords decrypted via terminal anyway. Interestingly annoying, thanks.

I can't replicate that behavior. If I choose "Always Allow" Chrome is added to the allowed applications (see Keychain.app in the Access Control tab). If I allow it temporary there're no changes or new/copied password items in the keychain.
Post reply on HN