Chrome's insane password security strategy • Hacker News Board

Re: Chrome's insane password security strategy

#311

Post by greyman » Fri, Aug 09, 2013, 12:28 PM UTC

euyyn wrote: post #226

whyoh wrote: post #216

Earlier quoted context omitted.

>EVEN with a master password, they'd be accessible in other ways by anyone using his computer Maybe (there are simple but very effective prevention methods against keyloggers etc.), but the main point is: it's not all black and white. There are varying levels of security (and varying levels of "hacker skills"). Passwords encrypted with a master password are at least a couple of levels safer than those displayed in pl…

If they're autofilled, which is the very reason to store them, then it doesn't matter how deep you store them. The browser will dig it for you automatically.

But only after the password store was decrypted after providing the master password, or not? And that is good enough for me. If I let someone to use my computer, of course I will close the browser before. So he can use my computer, launch the browser, but will not be able to access my passwords, since he doesn't know the master password.

Re: Chrome's insane password security strategy

#312

Post by Throwadev » Fri, Aug 09, 2013, 4:27 PM UTC

boklm0 wrote: post #310

Throwadev wrote: post #122

Earlier quoted context omitted.

Right, I'm not arguing against any of that. The point is if it's going to be that insecure, Chrome should make more of an effort to make it clear. They could do this by displaying a warning alongside the prompt to save a password. Also, just because some people will be able to access the passwords with physical access doesn't mean it's not worth doing basic/unsecure locking. I'd rather use a system where people need…

"The point is if it's going to be that insecure, Chrome should make more of an effort to make it clear" And what's a better way to make it clear than actually showing the passwords ?

A better way (than showing the passwords) to make it clear that storing the passwords is insecure was in the very next sentence after the snippet you quoted.

Read this: https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Then tell me what's better:

- Asking users to store password, and having a menu hidden in the guts of Chrome's settings that most users will never look at.

OR

- Asking users to store password, and prompting them at the same time that doing so is insecure.

Keeping in mind that the vast majority of users of this software are average, non-techies.

Re: Chrome's insane password security strategy

#313

Post by niemand » Sat, Aug 10, 2013, 12:04 AM UTC

justinschuh wrote: post #77

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

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

Re: Chrome's insane password security strategy

#314

Post by tmslnz » Sun, Aug 11, 2013, 7:44 PM UTC

elliottkember wrote: post #81

justinschuh wrote: post #79

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…

No one in here has ever even thought of reading the plain text password(s?) of their gf, friend, nemesis or what, when they left their computer on and left the room.

Yet that may be a good use case for a master password…

Re: Chrome's insane password security strategy

#315

Post by barrkel » Tue, Aug 13, 2013, 7:27 PM UTC

justinschuh wrote: post #77

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

I use a master password with Firefox; part of the reason I don't use Chrome is because it doesn't have a similar feature.

But this shows it's even worse than I thought. Security in depth. Encrypt the hard drive, encrypt the home directory, encrypt the browser password storage. You're basically advocating shallow security.