And this is why I don't use Chrome, nor recommend it to anyone.
The dimwit Chrome developers continue their dumb insistence that penetrable security shouldn't exist.
"Bathroom doors shouldn't have locks; someone could just kick the door in and then where would you be!"
"Houses shouldn't have locks; you've got glass windows, don't you?! It's a false sense of security!"
"Prisons shouldn't have 20-foot walls; Home Depot has 21 foot ladders, don't they?! Lex Luthor escaped via helicopter! It's a false sense of security!"
"Bicycles shouldn't have locks; there are bolt cutters with five-foot handles, aren't there?! It's a false sense of security!"
Of course in the real world, where Chrome developers do not live, we use locks in all these cases. There's a combination of social signalling (this is mine; do not disturb it) as well as legal signalling (locked means an affirmative action must be taken to break the security, which is punishable; unlocked is not punishable) as well as a substantial amount of actual security (the reality is not everyone carries five-foot bolt cutters, even if some people do).
Maybe I can put it another way: Android, up through 4.2, only contemplated a single user per tablet. So if you gave your kids (or anyone) the tablet to play with, they had FULL and unrestricted access to your Gmail account, Google Play account, and so on. Someone, eventually, slapped some sense into the Android developers and now Android 4.3 has restricted profiles where you can let the kids play games without giving them access to your Google accounts.
That someone needs to get their slapping gloves and wander over to the Chrome development team...
I think it comes down to how the Chrome team is used to thinking about security. Most of Chrome's security work, such as the phishing blacklist and the process sandbox, aims to prevent attacks from malicious web pages. In those circumstances, "pretty good" security gets you nowhere. If there's a difficult but known way to break the sandbox and execute arbitrary code, it needs to be patched. Otherwise, the hole's obscurity won't prevent people from distributing exploit kits. A subtly broken sandbox is almost exactly as secure as no sandbox at all.
If you're accustomed to thinking of security in this all-or-nothing way, the Chrome team's argument makes sense. And the state of the Internet encourages this kind of thinking. In the real world there are plenty of gray areas to security, but online there's always a sufficiently advanced and determined attacker.
Not knowing why they did this, my guess is it's faster. When you go to site-that-requires-a-login.com Chrome can have the password box populated immediately instead of needing to ask Keychain for it.
> "Houses shouldn't have locks; you've got glass windows, don't you?! It's a false sense of security!"
Chrome's threat model [1] paints a different analogy. In their view—which I do think is reasonable—the OS is the house and Chrome is simply a room in the house. You don't put locks on all of the interior doors of your house to keep out burglars who might've bypassed your front door, do you?
Their threat model makes sense for many users, and it's flawed for many others. One valid criticism that I do support of Chrome's model of handling passwords is the obscurity of it all. Users as a whole should certainly have a much better idea of how their passwords are being handled.
> the OS is the house and Chrome is simply a room in the house. You don't put locks on all of the interior doors of your house to keep out burglars who might've bypassed your front door, do you?
Most single family homes do, in fact, have locks on interior doors. And they're built that way, as that's what most people want.
> "Bathroom doors shouldn't have locks; someone could just kick the door in and then where would you be!"
Nitpick:
Bathroom doors should have easy breakable locks (if any at all) because of danger of carbon monoxide poisoning; locked doors may be the only thing that stand between you and dragging out unconscious family member from danger.
I for one was always taught as a kid to not lock the bathroom when taking a bath.
right - I live in the US nowadays and nobody has them - but back in the UK they're all over the place - stay at someone's house and there's a good chance they have one
I've never heard of such a thing, let alone actually seen one in a bathroom. I've lived in the UK for all (bar a couple of years) of my life.
[edit] I found an academic paper that discusses the safety of these heaters - dated 1973. I'd guess that they've gradually disappeared thanks to better heating systems and improved safety regulations. The paper: http://hej.sagepub.com/content/32/4/120.abstract
The comment was referring to "gas fired bath water heaters", which appears to be a specific type of heater fitted in bathrooms for heating the bath water…hence the potential for increased CO risk in the bathroom.
My hot-water + heating system is gas-fired, but the boiler is in a utility closet vented to the outside.
We have central heating but the boiler runs with a heat pump driven by electricity.
You are of course right in pointing out that central heating often goes along with central water heating and that heating is often based on fossil fuels such as gas.
In Poland quite common 'till very recently; I still have one (just reminded me to buy a CO detctor). My two friends actually got poisoned by CO - one when taking a bath, the other when trying to rescue her - because the landlord didn't bother to maintain ventilation properly.
I've had one blow up in Poland. Ul. Winklera, Poznan. I'll never forget that. My s.o. was about to use the (common for three apartments) bath and the thing blasted its outer cover clear across the room. She ran into the hallway totally forgetting her state of dress or lack thereof. The neighbours, alerted by the explosion that something was up, all piled into the hallway and sure appreciated the view.
Fortunately she was only scared but otherwise ok. Quite the bang, I've had a healthy respect for old Junckers products that have gas lines fed into them since.
That is a very specific design for bathrooms. Modern houses tend to have a bathroom with strong ventilation that pushes air out from the house. As such, most bathrooms door tend to leave rather larger space at the bottom for air flow into the bathroom.
Every modern bathroom lock I've seen in the last decade or so can be opened from the outside with a coin. A quick Google suggests this is a legal requirement in public buildings, and simply a good idea in private homes.
I use Firefox, but it seems from the screenshots that Chrome has that minor barrier of clicking before they reveal the password.
The reality is, you mistake a browser with a house, when the OS is the house. Let's rail on every OS distribution that defaults to unencrypted drives! And every digital device that has not bio-metric and multi-factor authentication!
It's not THAT unusual, on entering a house through a locked door, to find your way blocked by another door that needs unlocking. (One or both of these doors might even have two locks.) And then inside this locked house there will quite probably be rooms with locks on their own doors. And inside some of those rooms, cupboards, with doors, with locks on 'em! And look inside enough of these lockable cupboards, and you might well find a safe. With a door with a lock on it...
So, I guess you don't carry the keys to your rooms and cupboards. Every time you want entry, you use a safe with significant entropy for OTP to the cupboard or room you want access, and the access is revoked 1 min after idle. Every time and everywhere. Ludicrous.
Or you could just disable password saving. This is one of the first things I do when I get a new browser or computer. I don't want the browser remembering my passwords.
It seems to me that the differential between those who know what a bookmarklet is and those who know that you can see everything in the settings menu is very small. So you're not talking about a huge effect here.
The purpose of a master password is not to provide perfect security or a false sense thereof. The purpose is to impede an unskilled attacker who has only momentary access (like the amount of time it takes to type chrome://settings/passwords on a temporarily unattended machine) and mitigate the severity of what can be done by an unskilled attacker in the event of such a short breach.
It might be proper security engineering practice, but it strikes me as being totally out-of-touch with regular humans and mere mortal users to insist that once any attacker has access for any duration, you're completely hosed anyway, so why not make it easy for them.
Yours is a fair enough argument, but I find the line you're drawing to be arbitrary. We can conceive of a continuum of security mechanisms, each with a given strength which can thwart attackers with a given skill level. For example, near one end of the continuum, minimizing the browser when I leave should thwart a computer-illiterate attacker. Somewhere between that end and your suggestion of a master password is Chrome's behavior, where the attacker must know that they can find your passwords in the browser settings. Near the other end might be biometric authentication, or even no option to save passwords at all.
A more sufficient version of your argument would attempt to show why the master password is an appropriate place to draw the line on this continuum, perhaps by arguing that it's an optimal balance between minimizing the valid user's frustration and thwarting some percentage of attackers.
The correct place to draw the line is a place where the user has every convenience they want, and an attacker does not have any additional convenience.
Revealing plaintext passwords does not convenience the user but it would convenience attackers (with low skill).
> Revealing plaintext passwords does not convenience the user
That bit is not true, with a caveat.
I have a ton of low-security username/password pairs stored in FF. I find I do need to look at the plaintext passwords now & again, because I want to open one of those sites on my phone, for example, and don't remember the password (I looked up my HN password just yesterday so I could sign in on my phone, actually). Sometimes I find I've saved multiple pairs for one site, and I need to review the passwords to figure out which is valid.
I've used the same feature in Thunderbird with IMAP and SMTP server passwords, when I have an email account I've been using for year w/o changing the password, and I realize I haven't saved it anywhere else.
All of these are not hampered by requiring a master password, of course... I'm in agreement with timbl on his reasons not to allow just anyone to view these by default.
This! The assumption that some uber-1337-hax0r is accessing the system who will install a rootkit just by looking at it is just not close to reality. It is on the other hand a very real situation that some weird friends, family members or co-workers have access to your system while you're not looking.
It's very hard to stop a determined attacker, but that's not what this is covering. As a developer sometime I peer program, and that might mean handing over the controls to a colleague. Now I trust my colleagues, but you never know what their personal lives might me.
If I had, say, saved my internet banking password (I don't, but let's entertain the possibility) they could easily access the password list and copy it, then close it without me ever knowing.
It's much like leaving an open safe under my desk. Even if it's a simple lock people won't open it to see what's there. If you know I have a stack of gold you might decide to break in, but you'll know it's wrong.
An unskilled attacker with no knowledge won't know where to go to get the passwords.
An unskilled attacker with instructions can type in a url to get a password dumper, and be in and out in 30 seconds plus memorization/transcription time.
A little brother using Chrome regularly won't know about keyloggers, how to write a clever bookmarklet, or even be allowed to be around when his big sister is typing in her password. But there's a good chance he does know about clicking that little icon, choosing "settings", and seeing all of his big sister's passwords when she's out on a date and forgot to lock her computer.
Locks on your front door knob are not there to keep out burglars. They're there to prevent opportunistic crime: someone who tries that doorknob out of curiosity and discovers a home full of stuff and no one around. There's a large middle ground between good guys, bad guys, and those who might, just might, be tempted to be bad when they find that suitcase full of money. That's what Google is missing here.
And in a condescending response[1], someone who is allegedly the Google head of Chrome security called the original author a "novice", claimed Google has "quite a bit of data" to back up their case (without describing the data, its source, or how it was evaluated), and suggested that a master password would make security worse by providing a false sense of security.
First, I would suggest that if Google really does have the data mentioned in the claim, release it. Second, a master password isn't going to make the computer safer from a determined black hat because physical access to the machine means game over, but THE MASTER PASSWORD IS NOT ABOUT PROTECTION FROM BLACK HATS.
When the colleague who hates you is standing by your unlocked computer when you're off to get coffee and suddenly realizes that he not only can read your email now, but at any time he wants to in the future, that's a problem — when your partner gets suspicious about your working long and you've forgotten to log out — when your little brother realizes he can post "funny" pictures to your Facebook page ... when, when, when ... there are so many areas where this could cause a lot of pain. For example, this is from a blog entry I wrote a decade ago about a young lady who was compromised because LiveJournal stored her username in the cookie and the conservative, religious parents found her blog[2]:
I know of a young lady who kept an online journal. Her
parents found it and started reading it and were
horrified to find out that she was suffering from --
brace yourself -- teen angst! Her parents don't
understand her, not enough boys like her, she's not very
popular, etc., etc. In reading through the journal,
there are no references to doing drugs, sex, or anything
else that one might expect a parent to worry about, but
this young lady's parents hit the roof. They forbid her
to keep an online journal and they grounded her
(naturally, I'm sure this cured the angst problem).
The parents had physical access to the computer and were smart enough to look at cookie data (these parents weren't technically sophisticated, I might add). Can you imagine what would have happened if the parents could then have read all of their daughter's passwords? Google telling users "this isn't really secure, so we're not going to do a damn thing to help you" doesn't help.
Google is optimizing against black hats but pretending that opportunistic crime doesn't exist. In physical security, opportunistic criminals tend not to be the brightest or think too deeply about what they're doing, but when the opportunity is there, they go for. Google is happy to give them that opportunity.
But you can always conceive of some would-be attacker with a given skill level. You conceived of a child who knows about Chrome settings but not about keyloggers, and thus concluded that there should be a master password in the browser.
But I could just as easily conceive of an attacker who knows how to read a computer screen but doesn't know how to use basic window management, and thus conclude that the browser window should always display all saved passwords as long as the user can minimize the browser.
Or toward the other end of the continuum, I could conceive of an attacker who knows how to install a keylogger but doesn't know how to lift and spoof fingerprints, and thus conclude that the browser should require a fingerprint scanner to recall saved passwords.
These arguments need to establish why the line should be drawn in that specific spot, rather than just mentioning the line and describing the types of attacks it can thwart.
>A little brother using Chrome regularly won't know about keyloggers, how to write a clever bookmarklet, or even be allowed to be around when his big sister is typing in her password. But there's a good chance he does know about clicking that little icon, choosing "settings", and seeing all of his big sister's passwords when she's out on a date and forgot to lock her computer.
Oh come on, writing a bookmarklet is not a fair comparison. A fair comparison is the little brother googling 'chrome passwords' and finding a link to chromereveal.com[1] That's a more interesting activity than wandering around settings.
You're confusing a browser password-keeper with a house lock, when the house is actually synonymous to the machine. Lock the machine. Should every OS come with only encrypted filesystems that you have to enter a password on every read? You know, so your brother doesn't find your sexts logs?
More and more of our data is being stored online. Many things that you might want to keep confidential is nonetheless behind a poorly designed "firewall" of passwords. That's the problem. Demanding that someone never forget a manual process (locking the machine) is adding a massive point of failure. This is bad.
What does that have to do with a browser and poor analogies? Neither protect important documents on disk, a shell open with root, an ssh open to your production, etc. I'm not condoning Chrome's actions, but I'd also demand not storing passwords in a browser at all, and do all sensitive browsing in incognito, so your sessions can't be lifted.
You're leaving out the time to download, run, then delete the software and any traces that the operation was done. Going to the browser's settings and viewing passwords in plain text requires no installation or execution of code and leaves no trace. It is not as difficult or time consuming. It's kind of back the bike lock analogy: just because someone can take a bolt cutter to it doesn't mean it is pointless to use one.
You're still fundamentally arguing that because a safeguard can be circumvented, there should be no safeguard. There's no question cracking a master password can be accomplished, or even "easily" if you want to insist that, but it is taking extra steps including introducing and running new code and a taking degree of effort that is above and beyond viewing something in plain text in settings. It also assumes foreknowledge of all these things.
And by the way, you also forgot deleting the dumper site from the browser's history, (and DNS/proxy records if they're being logged) using a system password to install the software if the system has that kind of security, and so on. But I digress, the point is not that a master password will keep a determined or informed interloper out, it is that it will "keep an honest person honest."
>You're still fundamentally arguing that because a safeguard can be circumvented, there should be no safeguard.
No. I'm still a bit undecided on whether a safeguard would be worth adding or not. What I'm arguing is that many of the people making points in favor of a safeguard are doing so on weak reasoning, where they overestimate the effectiveness of it against a casual, untrained attacker. No foreknowledge is needed to make a search, and if you find instructions then I very strongly disagree that running a program is harder than navigating settings.
> deleting the dumper site from the browser's history, (and DNS/proxy records if they're being logged) using a system password to install the software if the system has that kind of security
Oh come on. This is supposed to be a casual situation where you let someone use your computer. What kind of history-monitored remote-logging computer is going to have saved passwords and unauthorized access in the first place?
> keep an honest person honest
You already have to enter a page solely for editing passwords and hit specific show buttons per password. There is zero plausible deniability at this point. I think an 'honest' person will already be kept out, and any changes would only matter in marginal situations.
>No. I'm still a bit undecided on whether a safeguard would be worth adding or not.
So what exactly is the harm or downside? Firefox has it. Neither Safari or IE display passwords in this manner either.
>No foreknowledge is needed to make a search, and if you find instructions then I very strongly disagree that running a program is harder than navigating settings.
Making a search is how you would acquire the foreknowledge. I was talking about an unskilled user acting in moment of opportunity - not someone who has researched password cracking and has unfettered access. I would bet that an employer, or an IT department, or a jury would see a difference between downloading & installing software on a machine and just opening the settings on it.
>Oh come on. This is supposed to be a casual situation where you let someone use your computer. What kind of history-monitored remote-logging computer is going to have saved passwords and unauthorized access in the first place?
Look, this could be in the workplace when someone gets up from their desk to go to the bathroom or get a cup of coffee. Chrome is on every platform. Some systems require administrative privilege (and a system password) to install new software but none is required to open chrome and veiw settings. I use a DNS service at home to watch what sites my kids use. I would know (albeit after the fact) if they downloaded a pw dumper. Lots of companies use firewalls and the like too. I was speaking about covering one's tracks - in any setting not just the kind you imagine.
>> keep an honest person honest
It is a reference to an old locksmith saying, specifically: "Locks are on doors only to keep honest people honest."
I read Justin Schuh (head of Chrome Security) comments [0] and I was a bit taken aback. He seems to suggest that unless you get 100% security it is no point making it tough for an attacker to steal passwords. For example, if you are not 100% sure of your home being theft proof - please do not worry about locking up your doors! :)
The response is fairly shocking. I have always felt reassured that security gurus will argue about minutiae in encryption schemes just because someday someone may figure out a piece of mathemagic that bypasses it.
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?
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.)
It's similar to changing your ssh port: does it provide "real" security? No. Does it prevent the majority of automated attacks? Absolutely.
As a real world analogy, what about easily-climbable fences? Those are often a useful deterrent, and they make trespassing litigation more likely to succeed.
Automated attacks will rapidly adapt. There's zero barrier without some OS-provided sandbox mechanism. For instance, something that verifies the signer of the executable before providing a key. (That doesn't exist on Windows, for example.)
I read an article recently that suggested that automated attacks of ssh on non standard ports have already adapted, hence this already offers no extra security.
Are these supposed security experts completely ignorant about how Mac OSX Keychain works?
This is the basis of much of the argument in favor of Chrome's approach:
>In all cases, if you have access to the machine, all it takes is trivial software that's widely available to snoop on anyone else using the machine.
This has been repeated elsewhere including by the Chrome security engineer in so many words. Paraphrasing, "if you've got physical access to the machine, everything else is just theater, so we just go ahead and make that obvious."
But.... OSX requires the admin password before installing any software. That would seem to invalidate the above argument.
Or is there actually a way to bypass OSX Keychain.. and if so how "trivial" is it? Certainly nothing comes up in a quick google search. You'd think it'd be big news, that Apple's whole security framework is just "theater".
Hmm, maybe it's just the System and root Library folders that require authentication. But those would be what you'd need to access to install a keylogger or some such monitoring software, I'd guess.
Chrome already uses the OSX Keychain to store passwords. Firefox, on the other hand, stores them as plaintext unless you find and use the option to set a master password.
That's kind of beside the point. While Chrome may store passwords encrypted via Keychain, the problem is it readily displays them to the user via its UI without any re-authentication. Its creators think that any attempts to authenticate users beyond the system login are "theater".
Is this really true for OS X Keychain? Are its admin password prompts for actions like installing system components or displaying secrets in the UI just theater?
I suppose the issue here is that many of the people who might "compromise" one's browsing session don't fit the model of an evil attacker. They might be friendly pranksters, or unfriendly but not invested enough in the "attack" to go to much effort to perform it. Part of the reason it makes a difference, as noted, is most people's lack of technical knowledge, which might not be a good thing to rely on (though it will probably continue to exist for the foreseeable future), but even with the knowledge that alternatives exist, it feels more evil to go after them. In computer security, it's common to look down on security measures that are bypassable, even if they have some deterrent effect, because hackers wise up fast, and the false sense of security the measures tend to provide is actively harmful. But there's a difference between hackers and the general population...
The other comment in this thread about locking doors is a good analogy. The chance that locking my door (in a house with many ground-floor windows and no home security system) will deter an actual burglar is nil. But it could certainly deter some strange neighbor from sneaking in and perhaps stealing things.
on the other hand - justinschuh mentioned that they've "literally spent years evaluating it and have quite a bit of data to inform our position". Opinions formed off the top of our heads don't mean that much.
It seems that an undifferentiated threat model is being used. Within the scope of physical access to an unlocked device all attackers are considered to be ultimately sophisticated and absolutely untrustworthy.
This model is clearly lacking, and is not appropriate for software as widely deployed as Chrome.
I made this argument to the 1Password guys (Dave Teare, I think) when I ran into them at Macworld a few years ago. I was used to the Mac OS's keychain always asking for a password to see or edit its contents, even when it's unlocked and apps can get at their stuff in it at will. 1Password doesn't.
He made the same counter-argument, that if you handing over your computer over to someone you don't trust, 1Password should be locked — his locks after a short timeout and whenever he put his computer to sleep.
These arguments are way more eloquent than mine though.
Something I've found rather silly in this whole kerfluffle is a failure to recognize that a physical-access attacker can just as easily copy your Chrome/Firefox/whatever profile to a thumb drive, and he now has a full copy of all of your login cookies, many of which are going to permit bypass of 2FA.
I like the idea of there being a challenge in Chrome before my passwords are displayed, but its actual impact on actual security is pretty negligible.
I disagree. Maybe if anybody who would ever have physical access to your computer has the technical chops of the average HN commenter, it wouldn't do much for you. However, for somebody leaving their computer alone for a few minutes in a coffee shop or college library, this could definitely deter many opportunists.
I...just said that I favor Chrome having a challenge before displaying passwords. I also said that I agree with the Chrome team's position that it doesn't substantially improve security against a physical attacker. I'd like Chrome to have it, but I also know that having your passwords behind a master password doesn't actually result in your web-based accounts being secured against a physical attacker.
A challenge dialog is going to deter the "casual" snoop. I'm all for it as a defense-in-depth measure. My point is that you can encrypt your passwords all you want, but even in that case, physical access is game over because there are additional attack vectors that don't require a passphrase to breach.
And honestly, if I left my computer alone in a coffee shop or library, I'd be much more worried that someone would pick it up and walk off with it than that someone is going to look at my Chrome passwords. Good luck memorizing those 16-character randomly-generated phrases that I can't reliably remember after two months of repeated use.
> A challenge dialog is going to deter the "casual" snoop.
I think the "casual" snoop is far more likely than the determined attacker with physical access. Which is why the Chrome team's position on this is baffling.
There are so many cases where I hand my computer over to coworkers, friends, family. I trust them all not to explicitly circumvent the security of my machine, but I definitely don't trust some of them not to "casually snoop."
I know you said that, but I disagree that it has a negligible contribution to security based on the distribution of skill level of potential attackers.
You are definitely right about my leaving the computer alone example. That was pretty absurd.
News: If you have root on modern Linux distro, you can edit the sudoers file.
Requesting a password would provide a false sense of security. The passwords are stored in an easily obtainable format. If you are leaving your laptop around untrusted people, you're going to have problems.
Trying to draw a line around the secure point (having a workstation totally unlocked) sounds incorrect.
The passwords are stored in an easily obtainable format.
So, why not change THAT and store them encrypted with a master key?
If you are leaving your laptop around untrusted people, you're going to have problems.
True. But why make it even easier for someone unauthorized to retrieve your passwords?
Why is it only the browser developers who come up with that arguement? I've never read such a statement from any other team. And why aren't other software systems do it that way if it is so insecure and "falce-security" so encrypt user passwords in a local db? Couldn't even an OS use that argument and say "hey, you got physical access to the system, here are all the passwords in plain text, have fun!".
>So, why not change THAT and store them encrypted with a master key?
They are; it's called your user account password.
If you mean an extra password, the answer is that most people don't want to type in a password when they open their browser. And even if they did, then the argument would be "well they leave their browsers open, so it should ask for a password every time", which defeats the whole purpose of password saving.
If you mean an extra password, the answer is that most people don't want to type in a password when they open their browser. Think it through and try to see the issue.
I don't see your "issue", as using a master password does not "defeat the whole purpose of password saving" at all. Many people have different login credentials for different websites (not only passwords, also login name or email) which are hard to remember which one you used where. Having access to them with a single master password is convenience.
I like the way this is handled in Opera, where your passwords can never be accessed/viewed in plain text at any time. Once your login data are stored, you can simply use them via CTRL+ENTER on the login form and the data is pasted into it. If you want to you can use a master password to restrict access to that data. And you can even set a time after which the the browser will forget that password and then asks for it again after e.g. 15 minutes.
I sit down at your computer and Opera is open. I go to facebook.com, click on the password field, press ctrl+enter. I then use the dom editor to change the field to text. Will I see the password?
You will not, because that domain is blocked in every OSI layer possible in my local setup. ;)
But seriously: Yes, of course you would. They have to be pasted in clear text. There is no other way to do this.
But that's not the point. The point is that you do not get to use CTRL+ENTER in the first place! Unless, of course, you type in the master password, which Opera will forget after x minutes (zero if you want it to be forgotten instantly). So you have a windows of x minutes after I've used the password manager for the last time to do your "DOM hack".
You drew an analogy with having root and being able to edit the sudoers file, but note that in that case the attacker is not able to see any passwords, only change them. I think it provides a useful level of security if the browser would encrypt stored passwords with a master key, using an OS-provided keychain. As with Safari, it could then ask for the master password before showing any passwords, while remembering the same password for normal logins for convenience. This is under the assumption that revealing your password is worse than somebody being able to use your accounts.
Please explain the exact algorithm that the browser stores encrypted passwords and needs a master password before showing, but can "remember for convenience".
Or do you mean that it'll prompt people for a master password for uncommonly used sites? Because that's just going to lead to people forgetting the master password and having to do a password reset.
My suggestion would be to use the OS keychain facilities, so the master password would be the same as the one used to log in. The master password is only needed once to decrypt the passwords, but I'm suggesting that for the 'show passwords' functionality the browser should insist on asking the password again. The advantage is that on disk, passwords are not stored in plaintext, and the browser doesn't reveal passwords trivially. A determined attacker could still extract the encryption key from a memory dump, but that's on a completely different level from a "show passwords" button.
Chrome already uses the OS keychain facilities. People are complaining that this is insecure because unauthorized people can look at the saved passwords if the user leaves their computer logged in and unlocked. They want Chrome to adopt the Firefox approach of storing them directly on disk optionally encrypted with a master password.
Or the Safari approach, where even though it could show you the passwords directly, its policy is to ask for your password before doing so. Note that while Chrome uses the keychain, it actually circumvents the point of the keychain by decrypting all keys at startup, before they're needed.
Sounds like the debate over running SSH on a nonstandard port. Sure, it provides only a little protection and only against opportunistic, drive-by attacks... but it's easy to do and it can't hurt. So why not?
If the password submission was handled in javascript couldn't the website rewrite the password field with a one time password. This would let people use password storage, but give the ability to revoke later on. The only difference between a stored password and a cookie, is that cookies are trusted less. Both can give password equivalent access.
I've often thought that it was strange that these passwords were stored in plain text. Although. At least with the version of Firefox my old workplace had on their machines, I was able to view all the passwords stored in it as well. Not sure if this has been fixed, but at least it's not always been just Chrome guilty of this.
I don't get the controversy. There are very few reasons to have multiple user accounts on a home PC, but this sounds like one of them. If you want to lend your PC to someone or allow other friends/family members to access it at will, you need to create separate user accounts for those people. Problem solved.
The dimwit Chrome developers continue their dumb insistence that penetrable security shouldn't exist.
"Bathroom doors shouldn't have locks; someone could just kick the door in and then where would you be!"
"Houses shouldn't have locks; you've got glass windows, don't you?! It's a false sense of security!"
"Prisons shouldn't have 20-foot walls; Home Depot has 21 foot ladders, don't they?! Lex Luthor escaped via helicopter! It's a false sense of security!"
"Bicycles shouldn't have locks; there are bolt cutters with five-foot handles, aren't there?! It's a false sense of security!"
Of course in the real world, where Chrome developers do not live, we use locks in all these cases. There's a combination of social signalling (this is mine; do not disturb it) as well as legal signalling (locked means an affirmative action must be taken to break the security, which is punishable; unlocked is not punishable) as well as a substantial amount of actual security (the reality is not everyone carries five-foot bolt cutters, even if some people do).
Maybe I can put it another way: Android, up through 4.2, only contemplated a single user per tablet. So if you gave your kids (or anyone) the tablet to play with, they had FULL and unrestricted access to your Gmail account, Google Play account, and so on. Someone, eventually, slapped some sense into the Android developers and now Android 4.3 has restricted profiles where you can let the kids play games without giving them access to your Google accounts.
That someone needs to get their slapping gloves and wander over to the Chrome development team...