Chrome's insane password security strategy
blog.elliottkember.com
blog.elliottkember.com
Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.
We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.
Joe User doesn't know a thing about how this magical box of tricks called a computer works. He just assumes that his data is safe on it, and won't get into the wrong hands, and that his passwords will always be protected by asterisks or what-not.
Sure, you may encrypt them using keychain, which is good, and yes, if someone has physical access to their machine and user account then it's compromised, fundamentally - but you're missing the far more likely scenario that this could be used, by, say, an unscrupulous employer, or a mistrustful spouse, or a child to get at daddy's porn passwords. People re-use passwords. Yes, it's bad behaviour, but what do you expect from a shaved ape? By making it possible to view these, you could grant the keys to the kingdom to any would-be eavesdropper.
It's not good. I understand your reasoning, but it's not connected to how people actually use their computers in reality.
I know, and you know, that locking one's account is the Thing To Do when not at one's terminal, but Joe User is still learning this, and in practice, most people do not lock their terminals when AFK, leaving them open to others in the household/dorm/school/office/whatever.
Yes, locking the account is the user's responsibility, but it wouldn't hurt to help them out, by not making it possible to view all a user's passwords in their chrome preferences.
Again, I'm aware that you could simply hop into keychain and check "show password", but this prompts for the user account password. At the very least, you should be doing the same.
Passwords are normally masked to prevent shoulder surfing, but the presumption is that the correct person is still at the keyboard. When you explicitly chose to show a password, the presumption is that you attempt to be aware of who is around you. If the bad guy is at the keyboard for your unlocked account, the fact is you've already lost.
> Yes, locking the account is the user's responsibility, but it wouldn't hurt to help them out, by not making it possible to view all a user's passwords in their chrome preferences.
This isn't about pushing responsibility off on the user. It's about not tricking users into believing they're safer than they actually are.
> Again, I'm aware that you could simply hop into keychain and check "show password", but this prompts for the user account password. At the very least, you should be doing the same.
If I'm an attacker, why would I use the keychain app to get Safari passwords? Just navigate to the site and change the auto-filled password field to text, or use an extension, or one of the many system-level approaches you have at your disposal. Many of these things are even available as tools that any novice can trivially acquire and use.
If you honestly think that the average user knows how to crack, hack and phreak, you're on another planet.
I cannot comprehend what useful purpose showing the passwords achieves. This falls into the same bucket as eCommerce sites which email the user their password after they sign up. In fact, again, by your measure, why do other google products not display passwords in plaintext? For instance, gmail?
I also note you sidestepped the suggestion of enforcing access control before allowing a user to view these passwords - it wouldn't be painful to implement, and would to a large degree obviate the issue.
Drawing equivalence to sites that email your password is also misguided. The issue with those sites is that, contrary to a password manager, they have no reason to ever retain the cleartext password. And more fundamentally, there's no excuse to ever transmit credentials in the clear over a network. Whereas in this case, we're talking about showing the user passwords that must be retained in a recoverable form, displaying only on user request, and within a security context that can trivially access them anyway.
At this point I think I've repeatedly conveyed the reasons for Chrome's design decisions on this front. Since there's no new information, and the discussion seems to be going around in circles, I don't really see a value in continuing this thread.
It's a simple one: why make it easier for a user to be compromised than is necessary? Why is it such a problem to ask the user to enter their account password before viewing this prefpane? You've not provided a valid argument against this.
As to lulling users - they already are. All of your marketing screams about how secure chrome is, how you don't need to worry about security, and all the rest, so showing their plaintext passwords just seems... silly.
Most users do not have to enter their password when their OS boots, and thus won't know what it is. So offering it in Chrome is an inconvenience for most users, but adds no extra security. Once an attacker has physical access and can run Chrome browser it's game over and they can get everything, even if Chrome asks for a password before showing you the password pane.
Users should be setting up "guest" accounts for their OS and "Guest" user profiles for their web browsers.
As to users who don't set a password - never make the passwords visible.
You're trying to prevent my friends from fetching my email password to look secretly at my self-nude pictures.
Justin is trying to prevent my enemies from fetching my email password to gain access to my bank account and rob me of all my money.
His point is Chrome preventing the former threat, while useful by itself, can lead me to believe that I'm also protected against enemies with physical access. This belief, as we know, makes preventing the latter threat impossible. As he cares way more about the latter threat, he thinks it's counterproductive to defend against the former.
> All of your marketing screams about how secure chrome is
To be fair, that refers to being secure against remote attackers, which is the primary concern of a browser since there's not much the user can do about it by himself.
His argument is that since a person could just smash the windows and open the car that way there's no point in putting locks on the door.
It's just a very myopic and weirdly out of touch position. He seems to think that he's 'training' users to have more secure practices? This isn't the business world. You don't get to blame the user for not being security experts. He should be doing everything in his power to make it inconvenient and difficult to access a user's passwords.
To be honest this reminds me a lot of how Microsoft used to treat issues in their code/software 'Oh, that's a user error. That's not a bug, that's a feature!'. And then when you get pushback you go 'I've discussed this enough, no more talking with the plebes'.
Your axiom seems to be that anyone with access to your computer should be 'trusted'.
In other words, if I hand my laptop to my spouse I am essentially granting her root privileges.
A lot of us are making the point that this isn't true. I may have a wife, children or a roommate who I trust to use my laptop but don't want to make my passwords easily visible.
When I hand my laptop to my wife I have an expectation that without resorting to some special tools she should not be able to find out what my Amazon password is or what my hotmail password is.
Your position seems to be that by making these passwords visible you are encouraging more secure behavior - ie. I will now log my computer into a 'guest' account every time I give it to my wife.
It just seems like you don't get how people ACTUALLY use your product. For many reasons I'm not going to lock my computer every time I give my laptop to my wife or a roommate. I have an expectation that there is SOME obscurity that protects my passwords even if it's just obscurity by not explicitly showing the password. You're not going to change my behavior and frankly most of us are pretty shocked that a) you are so resistant to challenging your own axioms b) you think this is somehow our fault for expecting Chrome to not have a giant 'show passwords' button.
You need to challenge your assumption that the 'attacker' is some malicious agent. Widen the scope to also include the suspicious spouse or the prankster roommate and you'll understand why we think this is a bigger deal than you seem to consider it. Even if it just presents a small barrier I think most of us feel that small 'annoyance' is enough to prevent pranks and snooping spouses.
Exactly. Well said.
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.
What I'm proposing is that you just don't show our passwords, all in one window, in plain text. I agree that this won't solve the problem, but would be a good first step. And I don't see how that would be dangerous.
Alternatively, Chrome should make this more obvious so that users don't make assumptions about its security.
How on earth can I convince you that many, many, many people are surprised and concerned about this? Can I direct them to you on Twitter?
I've enumerated this multiple times now, so I'm not sure how else to explain it. The simple fact is that you need to lock your user account if you want to protect your information. If you don't do that, nothing else really matters because it's all just theater and won't actually stop anyone willing to invest minimal effort.
Your software allows me to open up one application and see all passwords. It's likely the single most-used application, and the easiest attack vector on the machine. If I wanted your password, I'd try Chrome first. It's very widely-used, and therefore a huge vector. That is the problem here.
Either change it, or better communicate the need to lock your system. Because to an average user on the street, this is a scary thing to be able to do so easily.
Is there a public point of contact that I can speak to about this?
Justin, can you tell us the real reason Chrome does it this way? Because the reasons you list so far don't make sense.
If you don't want people browsing your passwords, you can't ever give them access to your user account or your unlocked desktop. That's it, that is the entire solution. Any other method of protecting the passwords is vulnerable as long as the potential attacker has physical access to the unlocked desktop.
Now, perhaps some of this is mitigated by the fact that most of those friends, coworkers, significant others won't know how to install a keylogger or install extensions - but some small percentage will anyway, and those users who were lulled into a false sense of security will have been just as exploited anyway.
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 to have the know how to use keyloggers in order to break, over one where Joe Schmoe can walk in and take everything.
In the end I have always known the security issues with saving passwords so I don't save any banking passwords or email account passwords in any browser.
And what's a better way to make it clear than actually showing the passwords ?
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.
Nope.
Just don't use Chrome. That's an even better solution.
Let me teach you a neat trick (I'll use firefox as an example, but this can be done in any browser because it's a "feature" of HTML).
>Open firefox and navigate to a login page where your password is saved
>Right click on password box and click inspect element
>In the console, change type="password" to type=""
>Move your eyes back to the password field
Oh dear, what's this?!
Protip: Don't store your passwords in your browsers if you let other people use your computer. End of story.
In Firefox you can go to preferences, security, and saved passwords. And News Flash: If you leave your wallet unattended for 30 seconds, someone could take your money. I guess wallet makers should include a warning too?
Incorrect if you set a master password, which Firefox allows you to do and is the reason why everyone's saying 'wtf, chrome?' and leaving firefox alone.
As for the dumb ones, they're storing their passwords on a sticky-post. Or using Chrome.
After all, google's business model depends directly on how much private information is shared over much of the internet.
2) Either the browser demands an unlock password every single time it queries the password store--which is probably not an acceptable experience for most users--or the browser can arbitrarily read the password store when left unattended. There's no meaningful middle ground here. An option to demand a credential before unlocking the store might be nice for nerds, but nerds don't need it anyway, because they can use 1Password (or similar) to do this for them. It's simply not tenable for normals. Good grief, just look at the wailing and moaning that the UAC prompts in Windows Vista generated. Those prompts by default didn't even demand credentials, just a click through.
But this is EXACTLY Justin's point: EVEN with a master password, they'd be accessible in other ways by anyone using his computer, because it's just stored in the keychain - and if they add a master password, people will think that makes it more secure.
The solution here is to remove the show button - don't add any kind of master password - because that's just snake oil.
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 plain text.
The more interesting argument here is the "crime of convenience" - where someone didn't want the passwords, but just saw them laying around in plain sight. But that isn't actually the case in Chrome: it's like four clicks. You have to actually be trying to find them.
Not to mention this doesn't seem to be an oversight by the Chrome team - it seems this is 'as designed'.
Why are you more concerned about something he has to go digging through settings purposely to find, than something he is almost guaranteed to stumble across?
You talk about lulling users into a false sense of security but do you have any idea how many Chrome users assume that their saved passwords can't just be viewed in plain text with a couple of clicks? I had no idea until I read Elliott's article and I immediately turned the feature off and deleted all my saved passwords.
If the broadband engineer comes round to investigate your connectivity issues and you (sensibly) watch over their shoulder while they fiddle with your browser settings, looking away for 10 seconds shouldn't result in them having ALL your passwords.
It's about ease & simplicity of breaching the "security" for non-technical people as well as techies.
Or are you saying chrome(ium?) uses the same technique but hidden to the user?
Please Justin, explain the real reason that Chrome does this, or admit that it's a bug and get it fixed. The reasons you mention are just stupid.
Smacks of laziness, especially in a world where it often takes very little to deter people.
On my system, I have installed scrypt and use it as a password management tool. When I need a password, I simply run a shell script I created, type my master password, and the password I'm searching for is placed in my clipboard.
Sure, I could write an extension to do this and I really should be concerned with the security of the clipboard implementation... but, those are fairly trivial (I do flush my clipboard buffer when I'm done).
This would be a simple solution for Chrome, actually. You already have all of the works for managing passwords implemented. All you need to do is add in the decryption process and simply not log the master password.
In this way, even the root user wouldn't have access to a user's passwords (as is currently the case with Chrome).
It's not secure against any attacks running under the user, though.
PS. This was always an issue with Chrome, and it is why I don't use Chrome on my mobile machine. Safari has a similar problem. So I recommend 1Password for mobile computing if those are your browsers of choice.
As far as I know, Safari uses OS X’s keychain which means you practically have a master password (very likely your user account password, although you could use a different keychain). If I try to retrieve a password (either through Keychain Access or Safari’s Preferences) I get asked for my “master password”.
You write about "lulling your users into a false sense of security." If that is true, then how do you explain that the 'show' button only appears when clicking a password? In the name of full disclosure, shouldn't you make that option immediately visible?
Furthermore, contrary to what was posted here, I believe that you encrypt passwords when storing them. On Windows, you would use the user's password as a "master password" in fact. So, kudos for that. But, wait, isn't this a case of using a master password to lull the user... etc? (because, you know, things such as Ophcrak do not exist?)
I am not going to re-iterate what was already written about the cable guy being able to lift your password in 10 seconds, it's simply a scenario you cannot dismiss and it seems strange to me as I would expect you guys to do some persona-based design rather than deal in hypotheticals (cf. "trivially recoverable")
So, yes, Chrome is an excellent product. And yes, from an absolute standpoint, you make valid points. I simply do not believe that you are the only one here doing so, and if you are willing to post comment on HN, then hopefully you are also ready to acknowledge that things are not as clearcut as you make them to be.
Simply gaining physical access to the machine should ABSOLUTELY NOT enable an attacker to extract practically all web passwords in something like 15 seconds, without any special tools.
Are you completely ignorant of how the OS X Keychain works and should be implemented application-side, or are you just willfully ignoring it?
You're thinking of security in the sense of some hacker or someone who has technical abilities.
What about the jealous ex-bf? He asked to use the gf's computer when they were dating, easily grabbed ALL of her password info and now she has to change everything when they break up. You're giving complete technophiles the ability to nab passwords. The question is WHY - what utility is there to make these show up in plain text over just prompting for a master password? What's the use case that you NEED to make these visible so easily?
It's also a terrible, terrible excuse to say 'well, there are other ways to get that info so our security flaw isn't an issue since it's already trivial'.
The fact of the matter is that you should at the very least require the master password to make these other passwords visible. There should be SOME authentication being done here.
What would this conversation be like if we were talking about gmail.com? You think it'd be OK to show in plan text a person's gmail password in the Settings page. I mean, if you logged in then of course you are the only person who should be looking at it.
Basically, you are fighting ignorance with even greater ignorant decisions.
The reason to have a master password to protect Chrome passwords, for most people and in 99.9% of cases, is that not that we fear we'll get hacked by some random jerk. It's to prevent a casual acquaintance from discovering our passwords easily.
At this point, I think what may have happened is that, at some point, the Google Chrome Security made a decision based on logic that had numerous merits, but doesn't work too well in practice. Now that they've committed themselves over and over by defending this practice, they're so vested in this decision, that they'll defend it, even to their professional demise.
Again, I think their original decision not to have a master password was a smart decision, but not a wise one. As an analogy to door locks again, the smart decision is not to have door locks because they're very insecure (think breaking down a door or window with an axe).
It sounds like this Google Chrome security policy will most likely not change until some significant leadership changes are made over there..
If someone starts their first sentence with name calling, you know they're not mature enough to have a real discussion.
In many situations its cumbersome or not socially acceptable to log out if someone just wants to use your browser for a second, because that implies you mistrust the other person. On the other hand, you wouldn't necessarily give the other person your passwords, of course.
I guess what many people expect is that passwords you save in the browser should be really hard to get out. There should be a function to recover them, because it can really be a life saver, and because it would give a false sense of security otherwise. But this function should be in a separate tool, and it could be really cumbersome to use (only runs in safe mode, is a command line tool, displays a full screen warning in red on black, plays a loud fanfare :-), etc.). It should be the equivalent of taking a bolt cutter to your bicycle lock, when you lost the key.
What people want here is not more security in a strict technical sense. Most people understand that you should log out, and if necessary enable disc encryption and/or physically secure your computer, to be safe against "bad guys". What people want in addition to this is a layer of obscurity, a social speed bump. Something that makes it inconvenient for nosey people to see your passwords, that adds friction and shows them they are doing something wrong.
(Oh, and having a master password (that is forgotten after a few minutes) does offer perfect protection against anybody who doesn't know how to install a keylogger etc.. I guess I and many other people are mainly worried about "foes" that are not so technically adept.)
If what you said about studying threat models and securing your computers and users accounts before handing over the system to friends or family is true and valid, why am I being asked a password to edit my Google Account settings. By extension of your claim, I should never have been handing over my system with a logged in user to anybody else. And definitely, the other claim that providing an extra layer of security is a false pretense must be valid in that Google is just providing us a false pretense of security when we want to edit our Google Account Settings which it does not require when we try to edit settings of the individual services?
Why is this distinction between Google's web services and your browser security?
So are all the policies and procedures of the TSA, if not the entire agency itself, but nobody is suggesting that making it a tiny bit harder to get weapons onto planes isn't a worthwhile goal. We argue over implementation details.
I read in a Tom Peters book years ago that if a flyer sees a coffee-stained tray table, they assume the airline doesn't maintain its aircraft. That's an utterly irrational conclusion -- and a typically human one. The solution is trivial: clean the tray tables! SO back to software.
Make it a tiny bit harder for ANY user to view the plain-text versions of the passwords stored in a web browser.
> So are all the policies and procedures of the TSA, if not the entire agency itself, but nobody is suggesting that making it a tiny bit harder to get weapons onto planes isn't a worthwhile goal.
Very large number of people have been, in fact, suggesting since day one of the TSA that the restrictions imposed on travel in the name of advancing security theater are not worth the costs that come with them, in some cases in some states (particularly Texas, but I think other states had started the process) going so far as moving to criminalize some of the TSA actions, until the TSA escalated by threatening to retaliate against Texas (who was the State where this had progressed farthest in the legislature) by shutting down all commercial air travel in/to/from the State if the bill was passed.
So, the basic premise of the analogy you are trying to use here is rather critically flawed.
justinschuh seems to have a deep technical understanding of programming and program security so I will defer to his greater understanding and make sure that I secure access to my computer when I am not physically present.
With all of that, my concern is that justinschuh seems to believe that anyone who has physical access to my computer and wants to do something malicious will have a deep understanding of programming, and that is silly. What about my druggie cousin who comes to my birthday party. He has no programming skills, but if he knew one simple URL he now has passwords to my bank account, my Amazon account and a ton of other accounts that he can use to transfer money or otherwise feed his habit at my expense. Or how about my ex-wife who gains access to my laptop because my daughter needed it for a school project. Now my ex, who has zero programming knowledge, nor does she understand what "threat model" even means, has passwords to all of my accounts including Facebook and Twitter that she can use to seriously harm my social/professional life.
So, you see, I get that you understand the programmatic "threat model," my problem is that you seem to be too smart to see that not all threats come from tech savvy "hackers." Some threats just come from opportunistic malfeasors, and I don't need to add any new opportunities to the seemingly unending list of ways people can screw up my life.
His attitude is very much like an ivory tower academic who is befuddled that people don't follow best practices.
I also get the feeling he's not used to having to admit he's wrong. I guess you don't make it to 'head of security' at Google by having a little humility but his responses are really not very encouraging.
As long as your password keychain is unsecured, EVERY browser does this -- it's just a matter of knowing where the passwords are stored in the browser as plaintext. If you don't want people to access your accounts, then secure them. You can't have your cake and eat it too. Either your passwords are conveniently stored in plaintext so you can login easier, or you take actions to secure your account and add a step to the login process.
Respectfully, a fairly common real world circumstance under which this is exactly the wrong choice was described, then ignored.
In response we got "you don't get it, we're staying where we are."
Is it possible that the reason people think you're doing the wrong thing is that you have made literally no attempt whatsoever to explain why you're flying against the best practices everyone else uses?
Saying "we have data" doesn't count, because we didn't see it, and everyone says that while justifying obviously incorrect stuff. I've had people mail my password back to me plaintext then insist that because they're (random important sounding thing) I should just trust their judgment.
And yes, this includes directors of security at first class software organizations with backgrounds in research security and the CIA.
Even if it turned out that you were correct, your current standoffish non-explanation is directly and severely undermining our trust in you. Do you just not care?
Sometimes you're a lot better off explaining than saying "you're too naive to understand."
.
> I've enumerated this multiple times now
Where?
.
> so I'm not sure how else to explain it
You give the very strong impression that you believe that saying "you're an amateur and we have data" is a kind of an explanation.
.
> The simple fact is that you need to lock your user account
"The simple fact is that you need to secure your server, and if you don't do that it doesn't matter that you salt and hash your passwords, and if you do do that then you don't need to salt and hash your passwords."
Yes, that's cute, LinkedIn. Back here in the real world, multiple layers of redundant, superficially weak, superficially unnecessary security have actual productive results.
.
> nothing else really matters because it's all just theater
The only theater I see here is "I've enumerated this and I don't know how else to explain it."
Unless you're talking about some other site, you haven't explained it at all, and what you're really saying is "I don't know how to explain it."
Maybe hire a communications person. You're making what appear to be by all basic security books and protocols dire security errors, then saying "I have data to support this decision and you're too dumb to understand what's going on."
Really?
Try us, sir. Closing the door in our faces is not a form of doing a good job here. If you're going to take liberties with our data, please be willing to give at least one good faith attempt to explain yourself. It's not a lot to ask.
.
> won't actually stop anyone willing to invest minimal effort.
I think you've confused wanting to stop blackhats with wanting to stop real world situations.
An angry significant other can pull this off. You're not just opening the door; you're opening it ridiculously wide, to the point that the average non-technical user can figure out how to penetrate your "security."
And then you're justifying it in terms of not wanting, through an unknown mechanism, to justify bad behavior, by leaving a vulnerability few technical people know about in place.
I just don't know how to respond to this.
Please share the data you keep talking about. The reason you don't know how to explain this better is that you haven't even begun to try.
Saying "I'm right and you're an outsider" isn't an explanation. It's a dodge.
Or in this case, give anyone physical access to your computer, and they have all of your passwords.
Security through obscurity is not security, but it still has practical uses. You could say that hiding the passwords behind the few clicks it takes is not real security, but it's still more useful than having the passwords displayed plaintext on a sidebar at all times.
Also, I think someone like a thief, jealous spouse, unscrupulous roommate or coworker or the like is much more likely to try and get someone's password to do evil with. The way Chrome is now, all a person needs is 4 or 5 minutes alone with the computer to get the user's passwords.
It seems to me you won't make token efforts to protect a user's password because that protection would be an illusion. So you would rather tell them the truth, so to speak, by letting them discover that their passwords are all easily visible by anyone who sits down at their machine. But if that's really the best you can do (I'm accepting this claim for the sake of argument), why store the passwords at all? Just by offering to store the passwords you are lying to the user, and lulling them into dangerous behavior.
Do you have data that users expect the passwords to be shown, or that storing them and making them so easy to see has any positive effect on users' password hygiene or security behavior? As for me, I know never to ever allow Chrome to store any password. Has that made me more secure? And is that representative at all of the standard user? I highly doubt it, but don't have any evidence either way.
> I appreciate how this appears to a novice
As you are in the process of defending storing passwords in plain form (or at least in a manner that allows them to be accessed in plain form so easily), without any warning that this is happening, I am of the opinion that you have no right to be so condescending as to publicly call someone else a novice.
> but we've literally spent years evaluating it
Some creationists have spent decades evaluating their position too. That does not make my any more inclined to agree with their assessment of the way the universe works, nor does it make me feel inclined to recommend that position to others.
> and have quite a bit of data to inform our position.
Please provide said data so that we can evaluate it, otherwise what you are saying here is simply "I'm right because I know that I'm right".
> what you're proposing is that that we make users less safe than they are today by providing them a false sense of security and encouraging dangerous behavior. That's just not how we approach security on Chrome.
That is EXACTLY how you are approaching security in Chrome it would seem.
If the criticism of the way Chrome currently does these things is wrong for this reason then Chrome's behaviour is wrong for the same reason. Users will assume that the passwords are stored securely, or will be blissfully unaware that they even need to be, and will think they are safe when they are not. This argument may not make the alternate suggestion being made correct, you certainly believe that it is not, but your argument doesn't make Chrome's current position any less incorrect either.
While here we all know that locking out workstations provides much better security (as mentioned in your earlier post) than a master password on the browser's credentials store would, the general public do not tend to have much concept of that in my experience (while it very much should be, it is not something most people give any thought to unless explicitly prompted). Letting them take their ignorance of the matter one step further is lulling them further into a false sense of security.
You are not wrong in stating that users should lock their workstations when leaving them, and should have them set to auto-lock after a time in case they forget. Likewise we are not wrong in stating that any key store should be locked after use, and automatically locked after a period of inactivity (requireing the master password to be requested again).
Essentially you are silently opting in (on the user's behalf) to exchanging security for convenience. This brings us full circle, back to the word "novice".
With regard to my earlier acknowledgement that other vendors do the same thing, while I'm taking cheap shots like the "novice" thing above: "other people are doing it" is no more a valid excuse for irresponsable behaviour here than it was in the school playgound when we were five.
We (by "we" I'm including developers, DBAs, technical managers, security experts, and other members of the technical "community") should be trying to teach users to take better care of their credentials and their information security more generally, making it inconvenient for them not to if neccessary rather than making it easy for them to continue to be blissfully ignorant of the situation.
- Showing passwords in this fashion is consistent with most users' expectations about how their passwords can be accessed.
- Requiring authentication before showing passwords has the effect of encouraging people to leave their computers unlocked in a potentially hostile environment.
Don't forget, all security, regardless of how good it is, is just a delay mechanism. It's perfectly valid to delay the easy attacks as well as the hard ones.
-----
"I appreciate how this appears to a novice"
Respectfully, I don't think this is a valid answer. This is the same sort of "I know better than you because I'm in the industry" thing that has led Yahoo! to believe that it's okay to re-issue email addresses: "we've done a study that we won't show you, we decline to address your criticisms, and we're right. We wanted to talk to you in public to create the illusion of interactivity and contact, but in reality we're ignoring your statements, refusing to explain ourselves, and declining to adjust."
LinkedIn said literally exactly the same thing about their password strategy right before their plaintext password database got owned.
It turns out that working at Google and saying nuh-uh isn't actually a valid form of explaining the security choices you're making in a way that almost nobody else is aware of. Having worked at IBM Security and the CIA doesn't change that. Whereas you may call the people pointing out the obvious problems in your approach amateurs, your ability to actually interpret what they say seems to be very, very limited.
I would note that your own past employers agree. What you're doing is a violation of FIPS 140-3, which your former employers helped the NIST craft.
No other browser does this. There's a good reason that everyone else does something different.
.
"[we] have quite a bit of data to inform our position"
You have quite a bit of data to support that it is not a critical security defect to allow people to pull passwords out of a little known browser dialog?
I find this unlikely, on grounds that I can't even imagine what sort of data would be used to support this.
Am I correct in suspecting that you will absolutely refuse to explain this claim, yet still expect it to be taken seriously?
.
"what you're proposing is that that we make users less safe than they are today by providing them a false sense of security"
No, eliminating a hidden attack vector does not create a false sense of security: nobody will know. In the meantime, an extant vulnerability will go away. This is the exact opposite of correct, and honestly fairly transparently so.
.
"And while you're certainly well intentioned, what you're proposing is that that we make users less safe"
And while you're certainly well intentioned to suggest that a car should have seatbelts, what you're proposing is that we make users less safe by encouraging them to drive over fifteen miles an hour.
The disconnect between your theory of how people use browsers and how people actually use browsers, as the head of security, making choices like these, is genuinely alarming.
But you have data. Which, conveniently, nobody can see, or point out your misunderstandings within.
Because that's how science works, or something, probably.
.
"encouraging dangerous behavior."
Taking away a little known mechanism for people to extract saved passwords from the browser does not in any way encourage dangerous behavior.
.
"That's just not how we approach security on Chrome."
It appears that how you do approach security on Chrome is with transparently false anecdotal claims backed up by no measurements, unprovided claims of difficult to guess about data, and no willingness to look at other peoples' points of view.
In the whole of human security history, this has never gone well.
Unfortunately, you have the provenance, and in unweildly large security organizations, that's often quite a bit more highly valued than actually hearing what other people say.
It is absolutely fascinating that Google's browser's head of security thinks it's a good idea, backed by mystery data, to be able to pull saved passwords out.
Of curiosity, do you honestly expect to be taken seriously when you fly in the face of every best practiced, based on data you won't provide, while just calling other people amateurs?
You realize how this sounds, right? Like denial?
Good lord. "We make your passwords recoverable from a dialog you don't know about because if we didn't you'd be encouraged into unsafe behavior."
What unsafe behavior is that? Saving passwords?
Seriously, you're intentionally leaving it weak so that nobody will use it for important things, but then not actually making them aware of that?
Just take it out, then.
Mind-boggling.
Truly, these are the situations over which we abuse the phrase "stockholming."
I use LastPass, and it is possible to set it so that a master password is required before any password is automatically entered, but in practice no ordinary user can suffer the loss of usability there.
Passwords are not actually the thing we are trying to protect. We're trying to protect against a user being able to use your credentials. If they have access to your browser, they have that already.
Maybe requiring you to re-enter your login session password, as a pseudo master password, would slow down a really naive attacker. But it will probably also annoy people who just need to get their passwords for some other reason. I would like to hear more from the Chrome team here on their reasoning but I would not be surprised if a 'master' password just leads to more users storing passwords on post-it notes.
I side my house I have safes, medicine cabinets and a gun rack. Those things are locked all the time, and I only unlock the cabinet when I need to use the items inside the secure container.
So, too, I have a use account login. Sometimes I will hand my computer to a friend (or they sit at the computer, same thing) so they can do stuff. At no point does my friend's physical access to the computer imply that they need access to my bank account details. So those credentials are locked up in 1password to prevent casual theft.
Keychain Access and 1password both require a master password to unlock the ability to see stored passwords.
The argument about "having physical access negates security" is missing the point: there are different forms of physical access. I won't let visitors plug in random USB, FireWire or Thunderbolt devices for example. They have use of the machine, they have physical access. But if any of them made moves to dunk my computer in liquid nitrogen before removing the RAM, I would shoot them.
If the computer is locked, my password safe is locked. If someone steals the computer (or an NSA agent inades my house to freeze and steal the RAM), the key material is encrypted and thus still not accessible to casual inspection.
The attitude of "the NSA can break the encryption so it is not even worth hiding things from the visitor casually using your computer" is defeatist.
Rethink your assumptions. What are you protecting against? Do I need to switch to a guest account to prevent casual guests from seeing my credentials? How does that aid convenience?
I'm so angry right now that I can't even string together my sentences properly :)
> Maybe requiring you to re-enter your login session password, as a pseudo master password, would slow down a really naive attacker.
That's exactly what I'm trying to achieve. It's a real concern for many people. Please show this to a non-technical person and see what they say.
Go to amazon right now and try to change your password without having to enter your password first.
You could lock it away with a one-way encrypted password but the problem with that is it's just "theatrics", giving a false sense of security... the stored passwords are still two-way encrypted either way, or else they can't be retrieved for later use. That means it is just as breakable as if they weren't. Once the hacker finds the password database on your computer it should be considered compromised.
If you don't trust your browser or your computer then you should use a service like LastPass or 1Password, i.e. if you consider them trustworthy to handle your passwords and if you're not on an insecure WIFI network. There is really no other way around it.
I do agree though that all browsers should be more clear about it... unfortunately it's not particularly easy to explain computer security to a user who is not a computer science nerd.
I've removed all stored passwords and stick closely to 1Password now.
"locking" the passwords would require intermittent master-pass entry like `sudo`, this would come off as an inconvenience to many users.
I think people here miss the fact that many users, even if they say they want more security, are unwilling to give up convenience and will switch platforms (i.e. browsers) if that's what it takes to get a smoother experience. In many ways (in this particular instance) security vs. convenience is more or less 0 sum- chrome team has decided users would prefer more convenience which means less security. Chrome team is giving users what they want: ease of use.
So, I think Pidgin’s situation is a bit different and if they would have keychain integration they may solve this differently than Chrome does right now.
[0]: https://developer.pidgin.im/wiki/PlainTextPasswords#Isthatth... [1]: https://news.ycombinator.com/item?id=6168039
Apple does not require any sort of approval or valid developer certificate to use the Keychain. Any app that attempts to access the Keychain will trigger a system-level notification to the user informing them of what the app wants to access, and allowing the user to "Allow", "Deny" or "Always Allow" the request.
> This is somewhat controversial in Windows, due to its weak file protections, but that's the way things are.
I read this as: we haven't bothered to look into the APIs for this... The Windows file permission model is a lot more granular than the "uid/gid/other" that most people are familiar with from Unix. Maybe this is a problem if you install to FAT32, which Windows disallowed since 2006.
Edit:
Apparently the text used to be:
> This is somewhat controversial in Windows, especially Windows 98 due to its weak file protections, but that's the way things are.
A user MarkDoliner then wrote:
> We no longer support Windows 98, so don't mention it.
But somehow in his editing neglected to make it a true statement.
The reality is that you're using the browser under a certain user profile. If you want to really separate your data from other users using your computer i would suggest icognito sessions or creating different user profiles. If you share your user profile (active user) you expose all this data (bookmarks, extensions, passwords).
Seems logical to me
https://www.dropbox.com/s/kgrrtil2s7hi43j/Screenshot%202013-...
Their first responses to outrage over the Google Maps cars they'd sent out to hoover people's wi-fi information were similarly obtuse about the mysterious ways of the non-machines: It's all information that was freely available to anyone who happened to have a fleet of packet-sniffing vehicles anyway, so what's the big deal?
With Google Glass they seem clueless on both sides of the equation: Never mind the role that facial symmetry plays in beauty or the billion-dollars industries that have sprung up to relieve people of their despised eyeglasses, more data is always better, affirmative? And why would even silly water-machines mind being always photographed everywhere? In many senses they already are! Jeepers can extermination day not come quickly enough.
And now this, here. Yes a given all-knowing cyborg entity could steal a "novice's" passwords with or without Chrome's help. But the easier you make it, the more it will happen. Meanwhile Google doesn't help its case with the clearly deceptive wording within the menus that make this possible. But mainly, our being from Google here seems genuinely baffled as to why this skeeves humans out so much. It just. Does. Not. Compute!
It is their seeming contempt for their customers coupled with a bizarre tin-eared bafflement about aspects of human nature the rest of the world seemingly grasps intuitively that often make for... well, entertainment at any rate; this story is presently top-of-fold on Techmeme. But it also is a window into a massive blind spot that could hobble the company.
I'm glad I have never clicked "save my password" on any browser.
Tools...options...saved passwords....show passwords...
So I'm missing the point why it makes Chrome so bad?
Generaly tho, i don't have any passwords there (all of them are in lastpass), except a few email account ones. Why do i have ANY passwords there? Well, they are being used by an extension that sort of needs them to push notifications about emails. I do have them protected by a master password, but the extension can still acess them. However, the extension has an option to ask for the password if i click one of the mailboxes in its menu. But then again i can still bypass that if i type the adress of one webmail provider, because i will get credentials for it. A good way around it would be if that extension developer would integrate with lastpass somehow, but does lastpass allow that? Now or in the future forevermore?
It has been discussed ad nauseum for years. As is the frequent suggestion to store all passwords via third party utilities or services (keepass, lastpass, etc).
The password protected password manager is the main reason why Firefox remains my primary browser. If my laptop is stolen, I'm confident that my passwords will be safe (although I still do not store banking related passwords.) More info at raidersec.blogspot.com/2013/06/how-browsers-store-your-passwords-and.html
Encrypted passwords are only unlocked in FF during a single browser session after one has entered the master password. Do people not understand this??
http://support.apple.com/kb/PH10698
No idea how does it look like in other operating systems - especially under Linux which doesn't have THE keychain, it has keychains (ie. there's no common api to access a particular KDE/Gnome/etc implementation of it).
With keychain locked, Chrome asks for its password every time it needs to fetch a password - be it showing a list of them or pulling a password for particular site. It's done in a proper manner, and if you hand the keys to your house to that guy... well, you better trust them :)
I have been waiting for so long to bash you on this point. And now when it comes, I'm at an utter loss for words.
What would it take to open your eyes to the severity of the matter? Are you really intending to let this slide away? Putting a master-password or some other level of security over the stored passwords is not such a big deal either that you would want to so actively evade them.
Are you counting on insecure stored passwords as a "differentiating feature" from Firefox?
I had stayed off Chrome for a long time due to the same reason: "No security for my stored passwords". But then I switched because Chrome became very fast and I used LastPass for storing passwords.
I'm telling you this because I'll not shy away from recommending Firefox or even IE10 to other people when they are looking for a browser, because hey, Chrome lets other people see your passwords, just like that.
Yet that may be a good use case for a master password…
What's technically possible for serious malware, or what someone can do with unlimited access to your computer for hours is not the point.
Reality is time-constrained, and UIs that slow people down are useful in this case.
However, keep in mind 'open door' syndrome. A crime of opportunity is very different than one of bad intentions. Leave a car unlocked with a $20 bill on the seat and you might find that $20 gone when you return. Now, if you lock the doors the odds are it will still be there when you return. The fact is that when you increase the barrier to doing evil, many give it up. A potentially honest person might open a door and take something but if they must now break a window to accomplish the same task many will not pursue it.
Having to potentially download a third party program to decrypt the password DB and/or run additional commands is very different that just navigating to the chrome settings page. Its almost akin to why so many coworkers always jacked each others wallpaper when they forgot to lock their computer. They could have still done it even though the computer was locked, but they did not because it was too much work.
Also, going off what you have said, the "locking" process in windows is pointless since it offers a false sense of security. It can be broken just by rebooting the computer with a boot disk, right? So why include it? Because its useful.
Just because I forgot to lock the door of my house, doesn't mean I shouldn't be allowed to hide and secure some valuables I don't want stolen that easily.
Just logout and give them guest access...geez.
Yes, if I'm not besides it, I will switch user accounts. And if I walk away from my computer for a bit, I lock it (except when there are no untrusted people around, like at home). I have "Lock Screen" bound to Ctrl-Alt-L, so it's trivial to do.
I actually don't think this is the case. An honest person would not open a car door if they saw a note in the car. Sure crooks and theives would, but honest people don.t
As a counter-example, just look at what happens sometimes when you lose your phone or wallet. Oftentimes you get it back. A lot of people are honest.
A good safe is judged by the time required to break it. There is no safe that is unbreakable, you just need to put enough time, effort and noise to open it. Same thing could be applied here. Installing software, dump the cookies and so on requires time. Right now with this security a person could get my password in a couple of clicks with almost no technical knowledge. I'm not talking about a clever hacker, but rather a random person in a cafe with wifi asking someone if she could check her emails and steal the password while staying in Chrome. Again, it's not about making it impossible to retrieve, it's about making it a bit harder than just clicking the "show me the password" button.
Of course I would never give physical access to my machine to anyone I don't trust. I always lock my computer when leaving it unattended... but I really doubt that anyone acts like that. It's a pretty geeky thing to do and the mainstream crowd isn't as worried by security.
Let's say the master password solution isn't good because of the feeling of security it brings. Instead why not never show the password? Just say to the users it's stored on your system, but don't show it in plain text in Chrome.
My point here is that there is little to no value (unless I'm missing something) to display the password in plain text, but there are some drawbacks (easy to see for semi-technical people). So why have this feature in the first place?
This being said, security through obscurity is never an optimal solution, but again going back to my "safe" analogy (not unbreakable, just hard to break). If a hacker wants to change the password, it takes a few clicks to locate a site where the user could be logged in. Then the clicks required to get a new password. Add the delay of email reception and so on... It takes more time and effort to do that than just click "show me all the passwords" and take a photo with a smartphone. Plus doing so will give you 1 password only.
About the keyboard presses count, let's say I use both mouse and keyboard.
ctrl+, (shortcut to settings) click to advanced click to manage click show
It's 4 operations. In my opinion, it's way shorter to do that and get ALL the passwords of a given user than try to change the Facebook password. Again, and I'm really stressing this out, it's not about making an unbreakable system. It's just making it a bit harder to break.
If this attacker is your friend, co-worker, spouse, room-mate or the like, your problem is social and not technical.
Those two points really should be obvious to everyone here. (This is a forum for software engineers, right?)
It is safer (and more honest) to provide no security mechanism where none can work, than to provide a fake mechanism and then claim that it can work. Perhaps people are so mentally abused by decades of security snake-oil (e.g. anti-virus products) that they have come to accept snake-oil as the pinnacle of security engineering. I don't know how else to explain what is going on in this thread...
I mean, he's absolutely right in that if you have physical access, or if you have OS account access to a computer, it really doesn't matter what you do, your shit isn't safe any more.
The argument of a 'crime of opportunity' doesn't play out in the digital world. Everything in the malware world is so automated and the scenario of 'If there are exposed passwords on this particular machine, I'll take them' just doesn't ever play out.
To that end, while it certainly seems awkward from a 3rd party perspective, I'm kind of agree with Google on this one.
This flaw makes it possible to read their web passwords in a manner which is not suspicious, quick, and not easy to trace.
If it even took slightly longer, or there was a risk of being caught attached to this action it would be far less likely for someone to casually browse another's passwords.
Think about most simplest case: childs John and Jack do their homework on Jack's computer. Jack goes to the toilet and John continue the writing/drawing. Then John gets "brilliand" idea: "Hmmm, why not stole his passwords all around and sell/play them later..."
Is this something which you think never happen?
There is two simple solution to avoid this: 1) Jack is having two accounts: admin and JackTheUser 2) There are no passwords in clear text format unless someone add JackTheUser's credentials. And this must happen everytime you look the passwords.
#1 makes impossible to install any bad software #2 avoid simple friends to see your passwords
Maybe Justin and Google just doesn't know how to verify user on the OS? Very same way than UAC behaved earlier on Windows.
Some professionals call it layer security: if your front door is open, your safety box is still locked. May I ask, is that something which we do not want?
I expect a hacker using my computer with admin rights to get everything. I don't expect my GF to get my passwords simply by pressing the 'show passwords' button.
And it's not very realistic for me to tell my GF she can't use my computer or to log out every time I give it to her. She's going to be kind of insulted if I do that. I just expect you guys to understand that in this day an age people DO actually share their computer with people without expecting them to have a giant 'SHOW PASSWORD' button in their favorite app.
Problem is a certain amount of people don't expect that, and it's important that this group doesn't grow.
"if people want to play a games console thats not connected to the internet we already have a product for them - it's called the xbox360"
Worth noting that he no longer works for M$.
Hiding passwords doesn't protect against someone malicious; it's enough of a speedbump to mean you don't need to be vigilant over all of your computers every second of every day.
Say you have a party with your friends, and are playing music through your laptop. What if you want to use the bathroom? Do you have to lock your PC? Is leaving the room "risky behaviour"?
Otherwise you are lulling people into a false sense of security.
E.g., to view passwords in my coworker's Keychain, I have to at least enter their account password to show the plaintext. To view their web passwords (which probably overlap significantly with their Keychain) all I have to do is open Chrome. I often use my coworkers computers for minutes at a time, and they use mine.
This flaw actually makes it possible to read their passwords — something not possible using other methods within seconds or minutes as they step out of the room.
- It's not as fast or inconspicuous as navigating to chrome://settings/passwords
- It does not present all passwords in a single list with the ability to show the one I'm interested in
- I would have to go to each site, allow Chrome to auto-fill, and then inspect the DOM and change the input type for each password I'm interested in. Far slower.
- It feels far more malicious to do what you suggest. Feeling is important. If I feel like I'm doing something bad, I'm less likely to do it. If I feel like I'm innocently navigating the Chrome settings page then I'm more likely to take a peek at your passwords.
- Far fewer people will be comfortable or familiar, or capable of using the DOM modification method. If a novice practices they are likely to get good at it. But that goes back to malicious intent.
Because the vast majority of the population don't know what a browser is, let alone a URL.
You (the developer) are providing the illusion of consent. The person don't know what just happened, but you're inferring that they have consented to what it showing up in that url.
There is no technical reason it can't do this. Safari does this if you want to view passwords.
Chrome makes passwords casually available, this is unlike Safari and unlike the Keychain. So either Chrome informs the user of that behaviour or it stops doing it.
What it is doing now is very poorly designed behaviour. I am surprised that you are arguing for Chrome's current implementation.
I fail to see how it is beneficial to the user. As you say, most non-technical users don't know about chrome://settings/passwords, these are also the group of users who most likely need to be reminded of their passwords. So what Chrome is doing is essentially allowing slightly technically competent users to easily peek at the passwords of the "vast majority of the population." Bad design that is easily fixed.
Not all OSes have a "Keychain".
Wish my passwords were at least behind my Google Account username/password :/
It sounds like that computer owns nuclear bomb instructions.
Take a breath and one step back: How about if the kids likes to play with their friend and likes to stole his/her facebook passwords when the friend is in the toilet (others are playing games at the same time with their friend's computer).
Most of the kids do not think about dumping cookies, installing malicious extensions etc. They just like to look the password and use it later.
We do not ask from you to provide any master password. Why not only ask user's credentials (the pure end user, not administrator credentials)?
If I go to your computer while you are in toilet, can I come and change your password? Or can you agree that your following comment was not actually 100% correct: "...when you grant someone access to your OS user account, that they can get at everything..."
At least mine OS: 1. Ask me the old password before I can change it. 2. I'm running normal end user credentials, so by default I do not have admin credentials. And by this way, I have very limited credentials to do what ever I like...
That computer, for many people, owns ways to access their online bank account. That's why Justin et al. need to take it so seriously.
On OS X, once you save a password using Safari, it is added to your login keychain. In order to then see that password* you must enter your login password again, be that via Safari's preferences dialog or the Keychain Access application. What Chrome does is it uses the same mechanism of storage as Safari (and indeed, requests access to the same encrypted keychain item) but never prompts the user for the login password to authenticate. This sets up a situation where Chrome actually circumvents and makes passwords originally stored in Safari less secure than they were initially. This is your responsibility, and no amount of theoretical grandstanding about physical access to a computer changes that.
You also talk about installing malicious browser extensions as another potential vector. I agree, and I think browser makers ought to take steps to require the current user to authenticate in order to install browser extensions. When you consider that a browser extension can act as man-in-the-middle to all your browser activity, it's astonishing that this isn't already the case. You have to prove you are the logged-in user when you change your password by providing the current password, so how is this any different?
When talking about security, there will always be holes, but they will be of differing practical value or risk depending on how they are exploited. Grabbing session cookies or internet history requires a certain level of technical proficiency, as does developing a malicious browser extension; installing said extension or typing chrome://settings/password into the address bar, on other hand, are easy enough that any kid who wants to get hold of his big sister's Facebook password can give it a go. Reducing the surface area of attack is every bit as important as ‘real’ security, here, and the stance you've set out above is that you aren't interested in that if it doesn't also provide real security. I think that's the wrong thing to do, and I urge you to reconsider.
*As people have pointed out, you can inspect the password via web inspector etc. This is another, serious security flaw and one that I think the HTML WG ought to look into.
You've fallen into exactly the trap they wanted to avoid. You assumed Safari's password security mechanism was more secure than it is. If chrome can access it without a password prompt, I can too. In fact, there's probably some nice apple script one liner to do it.
Sometimes just having basic security that keeps a casual attempt from opening my door / accessing my password from succeeding is enough.
It requires a stronger level of intent for someone to dump my Keychain passwords than it does for someone to browse my Chrome passwords.
This concerns me. I have friends that I would not trust around my computer now because I know that going to chrome://settings/passwords is too tempting for them. But I trust them not to maliciously or actively attempt to subvert the security on my computer.
It's not hard to understand where the boundaries are. Also, it's actually up to Apple to fix the broken thing, not Chrome. There should be a settings in the preferences of the keychain to require a password even if it's been unlocked before (or however that works. I don't Mac)
1. I do not lock my computer when my friend comes along to debug code on it. I do not lock my computer when I pass it to a friend at home so he can look something up. With Safari's password storage, I have a reasonable expectation that my passwords will not be viewed in the 30 seconds or so that I let people use my computer.
2. Keychain is not broken. Safari requires your Keychain password every time you wish to unmask a password. Chrome could easily do this too.
3. Chrome lowers the barrier-to-access for passwords. It reduces the amount of intent required. I would feel less bad going up to a friend's computer and browsing their Chrome passwords than, say, allowing Chrome to auto-fill a password on their computer and running a script to modify the DOM elements to reveal it. The latter is a more serious breach of trust, implies stronger malicious intent, and is more traceable.
Chrome would be better if it implemented this. I have yet to hear how this will make Chrome worse in any way. Why do you not want Chrome to be better?
The point is that it would prevent a certain number of attacks (such as non technical mischievous people) from unpremeditated attacks.
Your comment about 'false sense of security' is completely out of place as well. Chrome currently isn't doing anything to prevent the false sense of security (obviously from all the surprised people out there - can you see it now?). Why does it have to be a mutually exclusive choice? You could have your 'master password' and still have your false sense of security disclaimer displayed prominently next to it as well.
For maximum effect, remove doorknobs to make sure people who can't even turn doorknobs can get in. Doorknobs provide a false sense of security.
Oh to hell with it. We can't have people lulled into a false sense of security, and educating customers is bad for biz. Doors themselves must go as well.
It's also key that we plant our feet on this issue regardless of what damn near every person on the planet would prefer: a deterrent against theft by someone unable or unwilling to break a window.
The Chrome user interface doesn't let average users know their passwords are stored in such an easily accessible way. "Do you want to save your password?"... If they knew, it would 100% of the time be "Hell no!"... but Chrome asks by default, which puts millions of average users at risk... what a shame.
That's great, thanks for the reminder. I'll go use another safe that has extra security.
Does it means that all these passwords are stored in my Google Account ?
Does it means that applying steps below is possible ?
1. Steal Google credentials : By using phishing or simply access the password Chrome page of an unmonitored screen (it only requires 10 seconds), 2. On a other system, use the stolen Google credentials to connect on an blank Chrome installation, 3. Open the password list page, and get access to all the passwords registered in the Google Account.
If it works, it provides a long term remote access to all the passwords stored on the targeted Google Account.
Even if the targeted user changes the stored passwords (Facebook, ...), as long as it stores them on Chrome and does not change its Google password, I can get all the password changes.
Please, tell me that I missed something, and that I am wrong ...
The goals are clear:
GOAL 1. avoid giving the user a "false sense of security"
GOAL 2. give the user the best security/convenience tradeoff for her particular needs
The current Chrome behavior fails to achieve GOAL 1 because the user is not informed about the lenient "Show Passwords" behavior (as many posters here noted), nor is she informed about how vulnerable she is when someone has access to her local login account (as Justin described). Avoiding a "false sense of security" really means helping to educate the user, and Chrome has failed to educate the user. Only the user knows what threats she needs to defend against (is it just a naughty little sister at home or a tech-savvy corporate spy breaking into her work computer?). Chrome should inform the user so she can make a choice that is in her interest.
Nearly everyone in this thread is assuming that Chrome has to make the security/convenience tradeoff choice for the user. But Chrome can satisfy GOAL 2 by offering a few options.
My proposal is that Chrome should present the user with a few clear choices in plain English with realistic explanations of the advantages and disadvantages of each, and the user can then pick her own security/convenience tradeoff.
Let me give some suggested text to get the discussion going.
I will suggest three specific behaviors to choose from, but these are just examples. Chrome engineers may decide on a different set of behaviors to offer (perhaps even still only one choice).
The point is that the user MUST be presented with choices in plain English that give her enough information to avoid any "false sense of security." Even if Chrome offers no choices, Chrome MUST still inform the user about what she is getting when she chooses to save passwords.
I suggest that after the user has just installed Chrome and she clicks to save her first password, she should be presented with the following choice (the choice will then persist until and unless she changes it Chrome settings):
-------- BEGIN SUGGESTED TEXT ------------- Saved Passwords Security
Please choose how you would like Chrome to restrict access to your saved passwords:
CHOICE 1: No security: You or anyone sitting at your computer can view saved passwords at any time in the "Managed Saved Passwords" screen of Chrome settings. This option is the most convenient, but the least secure. If you use this option, consider locking your computer every time you leave it so that others cannot view your passwords.
CHOICE 2: Master Password to view passwords only: Chrome will ask you to create a Master Password. You must type the Master Password whenever you want to view your saved passwords in the "Managed Saved Passwords" screen of Chrome settings. But you do not need to type your Master Password in order for Chrome to fill passwords into websites you visit. This option can prevent casual, non-technical users from seeing your passwords (e.g. practical jokes from siblings or coworkers), but it does not offer any meaningful security barrier to an even mildly technical user who has gotten access to your account on your computer.
CHOICE 3: Master Password to view or use passwords: Chrome will ask you to create a Master Password. You must type the Master Password whenever you want to view your saved passwords in the "Managed Saved Passwords" screen of Chrome settings, AND you must type the Master Password every time Chrome is about to fill a password into a website that you visit. This option is the least convenient, but it offers a significantly higher barrier to a malicious, technical user who has gotten access to your account on your computer.
Please be aware that none of these options offer complete protection in the event that a malicious user (or malware) has gotten access to your account on your computer. For example, such a user can always examine your history or install malicious plugins to track your browsing activity, even if you never save any passwords. These Saved Password Security options simply let you choose from amongst practically available tradeoffs of security and convenience.
-------- END SUGGESTED TEXT -------------
In this suggestion, I have provided a #3 option which assumes that, under the hood, Chrome would NEVER store the Master Password in core or on disk, except during the short interval between when the user is prompted for it and when it is used to decrypt the website password. There is NOTHING magical about option #3 that offers 100% security. It is simply a higher barrier for bad guys to jump over (they have to hack into the binary's core at a particular moment to get the Master Password, or use other attacks not related to saved passwords). Option #3 may possibly be too inconvenient for anyone to choose: maybe a "sudo" timeout option is better, with different security/convenience tradeoffs. We can discuss all that....
But the main point is that Chrome must do a better job of informing the user about whatever behaviors it offers, and only then can Chrome truly avoid a "false sense of security."
-----
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
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.
Chrome (on OS X at least) doesn't seem to actually store them in plaintext per-se, but what it does do is equally creepy.
When you visit a site (i used twitter.com for my test) Chrome will attempt to access any Keychain items matching that location - you should get the stanrdard Keychain Access dialog prompting you to Allow, Deny or Allow Always.
If you click deny, obviously it can't read the keychain entry. But if you click either Allow, or Allow Always the same thing happens: Chrome creates a NEW Keychain entry with the same credentials, location etc, and set to always allow chrome to access it.
What a fucking surprise Google just does what the fuck they want with no regard for what the user has indicated they want.
I'll wait for the Google apologists to tell me it's either a) nothing to worry about or b) a harmless mistake.
https://code.google.com/p/chromium/ or Tools > Report an issue...
Have you reported the bug and asked the Chrome team about it?
In contrast to adwords defaulting to automatic payments and auto-bidding, or tracking users across the web universally over all the google services, or pushing people to use G+ everywhere, this wouldn't really benefit Google would it? I'm sure Google do lots of evil things, but I can't see any upside to them in this, and lots of downside.
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.
The access control tab in the keychain entry had Safari as the only listed application. When I then visited the site in Chrome, it asked for permission to access the keychain. When I clicked "Allow" it worked, but Chrome was not added to the "Always allow access by these applications" list and re-prompted when I refreshed the page. When I then clicked on "Always Allow", it added Chrome to the application access list, and I'm no longer prompted for access to the keychain.
At no point was an additional entry added to the keychain.
I did notice that when Safari offered to remember the password, with an additional option to make it so that only Safari could access that password. Is it possible that you clicked on that and Chrome had to create a new entry?
Edit: I tried getting that option again to test setting it, deleting the facebook entry in the keychain and then logging in again in Safari. It no longer asks me if I want only Safari to have access to that...not sure why it won't.
Well I was tripping balls on acid at the time so no
/sarcasm
Meanwhile I see no bug on https://code.google.com/p/chromium/issues/list filed today on the topic, and you obviously don't use Chrome as your primary browser, so I'm not going to worry about you. Cheers.
I can just as easily claim you have a weird keychain/chrome setting: no one else has disputed my claim about what it does, others have even acknowledged seeing the same behaviour.
tl;dr - This duplication activity is a bug. Chrome also likes to remember incorrect passwords in these duplicate entries, thwarting attempts at usability on many of the AD-credentialed sites I visit. I have not tested this stuff with non-HTTP, non-AD authentication, but I would expect similar behavior. I've provided Google with details.
I'm a Mac developer for my company. I use a Mac running OS X. I use Chrome as my default browser. The company network has Windows servers and our network credentials are handled by Active Directory. For this test, I closed Chrome and deleted the passwords (there were three listed) and reopened Chrome.
I open TFS in a new tab, I'm prompted for my AD credentials. I enter them, log in successfully, and Chrome asks if I it should save this password for my. I answer 'Yes.' I look back at the keychain and bam there are two entries.
When I changed my AD password on Monday, Chrome needed the new password. I enter it in the prompt, but Chrome changes the password in only one of these keychain entries. Deleting the incorrect password entry while Chrome is running did no good - it was recreated by Chrome with the wrong password. Then on subsequent starts, I don't know which password Chrome is trying to use, I click 'login' without typing a password[1] and it fails. So I continually have to type my password anyway, unless I visit the keychain and remove the offending password.
[1] The prompts for AD credentials annoy me; I'm presented with the login prompt every time I open this page; can't the browser just submit the password and only prompt me if it fails?
For reference, here's what Safari prompts you with when you try to view your saved passwords: http://imgur.com/k2gIqtM
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).
1. that does not make it OK to display all cleartext passwords, Keychain requires the account password before displaying the cleartext. And keychain can optionally require the master password to be entered before providing a password for form-filling as well.
2. an other user notes above that, whether you "allow" or "always allow", Chrome will copy the entry it just got to a new keychain entry which it sets to always allow.
This is a problem entirely caused by Google
Still, though, I find Chrome's practices in this respect rather crazy. The security I expect from the password manager is not that it will stop a person who really wants my passwords, but that it will allow me to lend my laptop to Joe Random Untechnical Friendquaintance to look at a web site, without feeling like I can't leave the room for two minutes because it's just that easy to see all my passwords. That's as simple as (say) a reversible hash.
I don't expect chrome's password saver to be secure: I'd just prefer it to not go out of its way to present passwords to the public. Or, at least, to make it very clear to users that their passwords can be seen that easily.
Finally, there's absolutely no reason why an untechnical user would know that chrome will give up their passwords like that - why would they?
Go to any page where browser (Chrome or Firefox) pre-fills password. Click on the password, click on "inspect element", change the type of the form input from "password" to, say, "pasword". You just broke the internet security.
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.
That is, actually, pretty nice.
You can set a master password, though.
I've been using web browsers for over 10 years and assumed a browser wouldn't make it this easy to find passwords.
After reading this I quickly checked and saw over 50 accounts listed all with the passwords in plain text next to them.
I guarantee each and every one of my friends that don't work in IT don't know about this - I could ask them all if I could quickly borrow there laptop to check a soccer score and find out the majority of there passwords.
What needs to be done is make people more aware of what's happening when they save a password - and perhaps a quick pop up in the bottom right coming up notifying them which passwords are saved and if they want to clear them before lending out, or leaving it unattended.
The case of "somebody used my computer and saw all my passwords" is solved by setting a password in your OS and locking your session when you're not there.
The problem here would be if some malware were to steal your passwords when logged on, but then not even a dozen of master passwords can save you (just install a keylogger and wait!).
(I realise I could visit sites and use password reset, but this is so frictionless as to be insane)
Or you might not just let random people sit down at your laptop and start using it without you being there?
People care about their security and also care about the convenience of being able to let a friend or co-worker use their computer for seconds or minutes at a time without all their passwords being easily discovered.
If I debug some code on a friend's machine he would not expect me to be able to open his Keychain and read his passwords. I would need a master password for that.
Chrome should do what Safari does — ask for a master password before unmasking other passwords. It would prevent a scenario where one can look up another's passwords inconspicuously and without trace in seconds.
If you leave your computer unlocked in a public area, that's asking for trouble - which is the example I was referring to.
However, in your example, you cited giving your machine to a friend to debug code - in that case, you either trust your friend, or you don't.
If you don't trust your friend, why are you giving them your machine then.
It's like asking your friend to collect your letterbox mail - do you trust them enough to not open and read your mail? If you don't, then why are you entrusting them to collect your mail?
There are levels of trust. It's not binary, and it's not as simple as you make it out to be.
Because Chrome presents your passwords in an easily accessible list from the settings screen, it lowers the barrier to access and increases the opportunity for passwords to be read.
Maybe my friend wants to read my passwords out of idle curiosity and they won't do anything malicious with them. I don't know, and I don't want to find out.
It is not at all like asking your friend to collect your mail. First, you can easily see if your mail has been opened. And for your friend to "cover up" opening your mail they would have to have some serious intent to breach your trust. This is not so with the password screen in Chrome.
I'm surprised that you can't see how making the passwords to all your websites easily accessible and readable in a convenient list is a bad thing. Adding a simple hurdle to access is all that's needed to prevent the majority of casual peeking at peoples' passwords. Safari does this, there is no technical reason Chrome can't.
Nb:not saying it is cool to be doing what they're doing.
security find-internet-password -g -s news.ycombinator.com
As others said: don't let anybody use your computer if you're logged in (have the keychain(s) unlocked).
That's insane too then! as it suggests/teaches that keychain passwords are master password protected.
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.)
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.
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.
If you "Allow" when Chrome prompts for access to a keychain item it then creates a new keychain item and gives itself "always allow" access.
Someone that does that to me would not get a punch in the nose, but that is certainly what they would deserve.
Regardless, what you suggest is an enormous invasion of privacy.
How about a, "Did you know that within 30 seconds, I can see all your passwords?"
Now I'd like to remove my saved passwords but visiting chrome://settings/passwords and removing them one at a time will take forever; can anyone tell me how to remove them in bulk?
Don't forget to turn of the option to save passwords, and optionally install a password manager extension (I use 1Password).
I use 1Password religiously but until now I'd been lazily saving passwords in Chrome as well to avoid the hassle of entering my master password. I feel slightly ashamed that I just assumed Chrome stored them "securely" and didn't give it any more thought.
<input type='passwordhash' hash='sha256' salt='26:$:9' editable='false'>
The actual password would have to be backed in RAM if the field is set to editable. But if it isn't, upon editing it would clear the current input.
Having hashes stored instead of actual passwords is of course not a total solution because someone savvy enough could use those same hashes to login to your services - but it definitely is better than plaintext - and will help stop novices from jacking your passwords. This of course requires both web dev and browser acceptance, I believe it's the future way to go
With the salt option, a website could use a different salt for changing your password or for doing certain 'secure' actions. This would prevent wholesale catastrophe when an account is hijacked, effectively a salt-based level system.
Thoughts?
Having <input type='challenge' algo='xxx' challenge='reallylongrandomchallengetoken'> would work better than yours, I think?
There's also nothing stopping the user using a "password", where that password is fed through a KDF and then used to generate the relevant private key (all done client side) -- but this is only as strong as the password used, so a really savvy user would just generate the private-key really well, and store that in a similar way to the way SSH keys are stored (i.e. passphrase). Non-savvy users can generate it a-fresh every time.
But aren't we just re-implementing client-side SSL certifications?
You've never handed your laptop to a friend to quickly check something on the web?
It would be insulting if you were to explicitly logout whenever someone wants to use your computer for a few seconds / minutes. This flaw makes it easy to view passwords in seconds, and makes it easy to do so in an inconspicuous manner.
It's a user interface failing more than a security issue.
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.
https://code.google.com/p/chromium/issues/detail?id=97510&q=...
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://developer.pidgin.im/wiki/PlainTextPasswords
I encourage the author as well as the submitted to read that.
Anything you did to obscure it would just give you a false sense of security.
In KeePass, a passphrase or a key file act as the encryption key.
Storing multiple encrypted passwords behind a single "master" password (in the case of Windows and OSX its usually the OS level User password) is a common way to provide convenience and security for users.
Do you somehow think that your OS is more insecure?
I don't think you've exactly explained what exactly you're trying to protect against.
Is it casual attacker who happen to chance upon an unattended computer? Well, in that case, either your computer is locked, or it's pretty much game over.
There is no additional security you can get by just obfuscating it.
This doesn't affect me personally in the slightest, I don't use Chrome for anything but debugging, but claiming this is anything other than Google doing what Google does best (fucking the user) is short sighted.
No.
1. Safari stores its passwords in Keychain (OSX's built-in password manager), in which a master password (the account's password) is required to get cleartexts. Safari itself does not give direct access to the passwords list.
2. Firefox has a master password option.
It's not very onerous and it prevents quick, casual swiping of passwords. (Sophisticated attackers could navigate to a fresh login prompt and use DOM-manipulation... but that's also more time-consuming and doable by far fewer people.)
Anyway...this is what happens when you optimize for "usability" over security. Microsoft used to get a lot of flak over this.