Here we have a response from a security head that it's silly to try to be secure if the person has physical access, or at least the Chrome team can't trust anyone else's app.
What if you leave your desk for the bathroom and forget to lock it? Or put chrome on a flash drive? Or have settings stored in a non-default location? Or heaven forbid a clever virus manages to get on and all it does is try to look at passwords?
Leave your desk and forget to lock it? Uh, then anyone that sits down keeps your user sessions. Unless you've configured things to prompt for passwords everywhere (like Vista UAC) then they have access to plaintexts you would.
Users aren't going to want to type in a password every time they open their browser. Non-sandboxed OSes can't really enforce any security there. And users hate re-entering passwords, this is why they are saving passwords in the first place.
You're arguing "yeah, but just because I logged in as root doesn't mean I want to be able to run root commands".
His response is correct.
In fact, almost any of your applications could already be doing this, since it's not sandboxed. Game over. Might as well remove it. Users hate being logged out anyway.
edit: I'm quite serious. incognito mode is "privacy theater". by the same logic, it should be removed.
It should be on by default — like Safari where it uses your keychain password when attempting to display a plain text stored password. Chrome and Firefox could easily do this too (they do use the Keychain to fetch passwords anyway.)
Note: Your ISP and the NSA can be logging from their end to, without access to your machine.
If I leave my desk to go to the bathroom for a few minutes then I take my chances with any malicious actors with access to my hardware, sure, we can call that "game over".
But that scenario doesn't make much sense in reality - if someone is that close and has such a malicious intent, why don't they simply hit me with a 5 dollar wrench[0]?
Whoever happens to be feeling malicious in my office ought to have to act out their malice deliberately - and not simply to be able to click a single button to retrieve all my personal passwords.
That's not "browsing passwords". That's clear, malicious, intent. It's like someone in your room looking at the bottom of your underwear drawer for secret items. Chrome is in no way popping passwords up in front of friendly unsuspecting visitors.
Do you not lock your house at all because the worst-case scenario is that the burglar is a master lock-picker (and you can't afford the ultra-expensive takes-30-minutes-and-powertools-to-break locks)?
Using the worse-case scenario to guide all of your decisions makes more sense when the threat/attack is coming form the Internet, where the likelihood of the attacker being skilled significantly increases.
I agree that there's some malicious intent. But the fact is that I would personally feel less guilty about doing this on my coworkers' computers than I would modifying the DOM after the password had been auto-filled.
I think this applies to a lot of people who argue for adding a master password unlock to view stored passwords in plain text.
Look, this ain't some high brow crypto discussion. It's a complaint that passwords show up in plaintext on the screen. We're trained all the time to not look when people type them in, they're covered with dots on forms, and we don't leave them lying around for anyone to see.
Sure some people do, but not everyone can be saved from themselves. But it sure as heck feels wrong, and this is by and large an interface problem, not a security problem.
Finally, someone else noted that the passwords actually not actually saved as plaintext, removing the real fear that the passwords can be gotten if the hard disk is merely read elsewhere. So it's not even a security risk, so long as no one makes an add-on that can grab those passwords in plaintext, which would be darn near insane.
(Am I the only one who thought key rings and such existed to mask the password so no one but the authorizing runtime ever saw the password as plaintext? (As in an app points to the key store and then another trusted program handles the actual password transaction so the first app never has to know it.) I can't be the only person who thought there was something more clever at work, I hope? Chances are I'm just too trusting.)
[1] http://msdn.microsoft.com/en-us/library/aa380261%28v=vs.85%2...
My personal suggestion would be for an optional user-provided password. I would be surprised if most people who wanted extra Chrome security would mind typing in a password once after starting it.
That's not how protected storage works on Windows. It's just a simple crypto API. You give Windows some data, it encrypts it with a (user/machine/process) specific key and returns it. It's up to Chrome to store it. So, any bad software would already need to target Chrome's settings files, so hard-coded (or install generated) entropy adds nothing.
There is the Windows Credential storage which is system wide (I think IE uses that), but Chrome does not, to my knowledge. (I've got a hundred entries in Chrome, and only a few certs and passwords in credstore.)
> would mind typing in a password
This is an entirely different suggestion and that sounds like a decent feature but not really. If you want a password manager like PasswordSafe that stores passwords "safely" (and does auto-relock, moves around in RAM to avoid any "ghosting" effects, etc.) then use a dedicated program. Adding it to Chrome adds complexity for little additional security (if your workstation is unlocked, it's almost definitely game over).
And the original article is talking about non-technical friendly culture of leaving stuff around unlocked. Even with a master password, Chrome is left open all the time anyways. So it's a doubly dubious feature. You'd need to add auto-relocking, etc. etc.
If Chrome does all this, one of the Chrome members should implement a lightweight, benign exe that undoes it all in one quick move, shows you passwords, then deletes itself. So you can just hit like new incognito window, https://url.thing/chromepass and immediately undo it all, just to remind people how silly it is.
Edit: Remember that most security threats are remote, and Chrome has been doing a fantastic job on the actual security model. Cert pinning, for instance, prevents vastly more attacks than this complicated password thing would do. Wikipedia says Chrome (and new Safari) are the only current browsers to support TLS > 1.0 (needed to prevent some attacks).
I'm glad the Chrome team is moving with a real threat model, rather than hand-wavy stuff.
The attack is by colleauges, members of family, etc, not by hardened black hats.
As readily available as tools like John the Ripper and its various clones are, the average user (parents, schoolmates, stalkers) probably won't think or be able to operate such a tool. These are the kinds of attackers who will, when asked for a master password, either start guessing or just give up. Hence:
Well, in a lot of places with say teenager culture or work groups, if you leave your computer open you know people will read your facebook and may even send messages as you largely for fun.
It is a different damage level of security failure for someone to get hold of the password and be able to log in and stalk them at any time in the future.
If you sit down at my unlocked session of Gmail, yes, you can read my mail or send email. But you can't get my Gmail password--which would allow you to log into my account later from your computer.
If I'm using Safari, you have to look in the OS X Keychain Access software, which hides passwords by default. If you check the box for "show password", you have to enter my OS X password before it will show it to you. You can't get it.
If I'm using Chrome, you can just go to the saved password interface and write down what you see. Stalking achieved.
I don't know the details of the OS X keychain. If they indeed validate programmatic access to the keychain by authenticating the code executing (that is, verifying Chrome by Google is accessing the same data stored), then sure, it's possible to do somewhat better.
But if the browser prepopulates fields and they are inspectable, that defeats the purpose, yet again.