Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome's insane password security strategy

blog.elliottkember.com

Post reply on HN
Print view View original

181–190 of 315 posts

Re: Chrome's insane password security strategy

#181

Post by corobo »

marcgg wrote: post #105
justinschuh wrote: post #77

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.…

I understand that a master password would just lead the user into a false sense of security. However, I feel that it should be make as hard as possible to find the user's password. 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…

"My point here is that there is little to no value" Personally speaking I've had plenty of occasions where I've logged into a site and saved the password then later Chrome doesn't recognise where to put the credentials on another page on the site (e.g. a header login vs a separate login page) - In those cases I'd rather just look to see what the password is and re-enter it than go through a password reset process.

Re: Chrome's insane password security strategy

#182

Post by ginobean »

noivad wrote: post #160
justinschuh wrote: post #86

Earlier quoted context omitted.

It matters that you don't seem to understand the threat model here. You think your passwords are protected somehow in other applications, but they're simply not. The fact is that they're still trivially recoverable, and if the bad guy can read them at all than he already has access to fully compromise your entire OS user account. So, you're arguing that we take measures to make users think they're safe when they've a…

I take it that you are unaware of the concept of defense in-depth, because your argument is essentially: well if they can come in the front door, then they can open the garage & steal my car too easy, so putting lock on the doors would make people think their car was secure. To enable a person to lock the car door would be silly because once a person has access to your house, they own everything in it. While no secur…

I'm a professional programmer with more than 20 years of experience and I think noivad makes an excellent point here. If you apply Justin Schuh's argument to door locks, the conclusion would be that door locks are insecure so don't even bother having them in the first place. How are they insecure ? Take an axe and break the door down. That should probably bypass almost any kind of residential door. Alternatively, break a window.

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

Re: Chrome's insane password security strategy

#183

Post by papacity »

dmaclay wrote: post #173
justinschuh wrote: post #83

Earlier quoted context omitted.

I appreciate how this appears to a novice, but we've literally spent years evaluating it and have quite a bit of data to inform our position. And while you're certainly well intentioned, 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.

This prevents Chrome from ever being my primary browser.

Too bad every other browser works the same way...

Re: Chrome's insane password security strategy

#184

Post by MarkEllis »

elliottkember wrote: post #81
justinschuh wrote: post #79

Earlier quoted context omitted.

Soft boundaries within the user account do nothing to protect you from exactly those scenarios either. Your protection is to lock your OS user account.

Hey Justin, I'm the author. I appreciate your sentiments, but I feel like they may be out of touch with the way real people are using computers in the wild. My suggestion is to seriously re-evaluate this approach in light of the actual use-case of how people perceive these passwords. It appears as though many, many users don't expect these passwords to be visible. This is an important thing to take into consideration…

I can do this in firefox too...

Tools...options...saved passwords....show passwords...

So I'm missing the point why it makes Chrome so bad?

Re: Chrome's insane password security strategy

#185

Post by MarkEllis »

elliottkember wrote: post #81
justinschuh wrote: post #79

Earlier quoted context omitted.

Soft boundaries within the user account do nothing to protect you from exactly those scenarios either. Your protection is to lock your OS user account.

Hey Justin, I'm the author. I appreciate your sentiments, but I feel like they may be out of touch with the way real people are using computers in the wild. My suggestion is to seriously re-evaluate this approach in light of the actual use-case of how people perceive these passwords. It appears as though many, many users don't expect these passwords to be visible. This is an important thing to take into consideration…

I can do this in firefox too...

Tools...options...saved passwords....show passwords...

So I'm missing the point why it makes Chrome so bad?

Re: Chrome's insane password security strategy

#186

Post by corobo »

jperrez wrote: post #174
justinschuh wrote: post #77

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.…

OK, it is my fault to leave my laptop unlocked and I'm putting myself at risk by using a browser that let anyone to see my stored passwords in plain-text in a single click...

Not sure if sarcasm.. Yes it is your fault if you forget to lock your account when you leave your machine unattended. It's also a click per password after the three clicks to get to that page.

Re: Chrome's insane password security strategy

#187

Post by DanBC »

madaxe wrote: post #95
justinschuh wrote: post #89

Earlier quoted context omitted.

I'm sorry, but I really do understand your argument. You're claiming that the same novice who can't install a simple application or or follow three steps to reveal a password on the page will be capable of drilling down through the Chrome settings menus and displaying passwords. The corollary to your claim is that the threat of this novice outweighs the damage of encouraging people to leave their computers unlocked i…

I can see you don't, which is why I'm trying to pose it variously. 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 n…

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

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.

Re: Chrome's insane password security strategy

#188

Post by AdminUser »

mkautzm wrote: post #147
justinschuh wrote: post #77

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.…

I'm inclined to agree with Justin here. 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 particul…

I would like to ask to think twice until agree Google's reply. And not only because they have so much power on the Internet.

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?

Re: Chrome's insane password security strategy

#189

Post by Shooti »

interpol_p wrote: post #170
justinschuh wrote: post #77

I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.…

You say you do not wish to lull users into a false sense of security. So why not clearly tell people each time Chrome saves a password that the saved password will be visible in plaintext by visiting chrome://settings/passwords ? 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…

"Inspect element" and then changing the "password" input type takes seconds/minutes.

Re: Chrome's insane password security strategy

#190

Post by interpol_p »

Shooti wrote: post #189
interpol_p wrote: post #170

Earlier quoted context omitted.

You say you do not wish to lull users into a false sense of security. So why not clearly tell people each time Chrome saves a password that the saved password will be visible in plaintext by visiting chrome://settings/passwords ? 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…

"Inspect element" and then changing the "password" input type takes seconds/minutes.

Here are the issues with your method.

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

Post reply on HN