Your what if scenarios are essentially game over. "Heaven forbid a virus" - uh, if an attacker is running arbitrary code in your security context, you've lost. Full stop.
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".
I think your point is valid with respect to experienced, technologically-proficient attackers. But as Berners-Lee points out:
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.
Oh, I'm not logged in as root, which is why it bothers me. Heck, I don't even have root to my computer at work (which is almost never more than a very mild inconvenience).
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.)
On your last point, Chrome uses the default Windows keyring implementation with no extra password (*pOptionalEntropy [1]), so any Windows application can grab passwords stored in Chrome.
What would you suggest Chrome provide as pOptionalEntropy? Please be specific, and note that I don't want to provide a password every time I start Chrome.
Your requirement conflicts with the requirement that passwords stored in Chrome are not discoverable by other programs. Hard-coded optional entropy will just be pulled out of the executable and these programs will still exist; randomly-generated new entropy for each installation of Chrome will have to be stored somewhere if it can't come from the user, and it can be pulled out of there and these programs will still exist. The only advantage that non-user-generated optional entropy will get you is that programs that do not specifically target Chrome passwords, and instead just dump the entire protected storage, will no longer be able to get Chrome passwords.
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.
> do not specifically target Chrome passwords, and instead just dump the entire protected storage, will no longer be able to get Chrome passwords.
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.
Sorry, it appears you are correct about the protected storage. I was basing my understanding on a work discussion we were having, where we appear to have been wrong. Thanks for the correction.
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.
It's not a single click. They have to go into Settings, find the passwords section, open that up, find the password they want, and click show password for that entry.
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.
> That's not "browsing passwords". That's clear, malicious, intent.
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.
Every time a person gains physical access, the worst-case scenario is that it's someone skilled at such things. The reality is that the number of people with such skills is rather small when compared to the general population. What are the chances that someone with momentary access will be an ultra-skilled black hat?
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.
Your scenarios do not envision stalking--an attacker who wishes to access your accounts from another computer at another time, without your knowledge.
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.
My threat model is any untusted subject accessing my computer. What's why I lock it even to walk to the other side of the room. This requires any attack to open laptop, remove epoxy on RAM, then quickly switch my RAM out and read keys.
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.
Then why have incognito mode at all? Anyone with access to the computer could install something to observe the browser as it navigates around 'privately'.
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.
If you're being monitored (by software), then it's already game-over from multiple angles, and your browsing history of porn is the least of your worries (logging encryption passwords, etc). On the other hand, using Incognito Mode means that there are no logs until you're being monitored. This means that if your laptop is confiscated (e.g. at the border) there are no logs.
Note: Your ISP and the NSA can be logging from their end to, without access to your machine.
Not completely. Incognito mode is still useful so that when your boss sits next to you, and you start typing words in the browser/search bar, it doesn't offer "interesting" autocompletion based on browsing history.
I think that's exactly the parent's point. Incognito mode is useful despite being essentially "security theatre". The same way that requiring a master password to view stored passwords is useful.
Yes, I agree that master passwords are badly implemented in Firefox.
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.)
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.