A limited account can still install extensions, userland rootkits (which do exist), background startup programs (which would have full access to the user's running program memory and files), and so on.
Seriously... I'm getting mad just at the thought that the head of any computer security team can think in this way.
Thats because like so many others you do not have a clear conception of what the actual threats are and the proper way of mitigating them.
This is really very simple: If the attacker has access to your session, you have lost. If an attacker has access to your machine and you have not used disk encryption, you have lost. If you dont understand why those two are true, you will not understand Google's response here, but if you were willing to place money on the line I could easily write you a service in AutoIt or Powershell which scrapes all of your "secured" firefox passwords and mails them to me with nothing more required than the ability to drop a file somewhere in your user profile.
C) Yes, but it's not always guaranteed that the attack will happen when the master password keychain is unlocked or that it will be an ongoing attack. That means this is a security risk mitigation. I'm fine with that.
Someone wanting to attack a browser with such a mechanism would specifically design it to wait resident until that keychain was unlocked and immediately dump it.
The real issue with the "weak security" being suggested is that it will cause people to misunderstand the level of security they have. See all of the responses that are absolutely shocked that you dont NEED to give your password for a program to be able to access your OSX keychain; the password prompt had given them a false sense of security, and they had assumed that their computer was more secure unattended than it actually is.
It will stop anyone who happens to be on my machine from casually getting them.
Security theatre. Such an individual would take 5 seconds to google "how to dump chrome passwords", and would realize theres about 800 ways to do so. In a few seconds, he could browse to amazon.com, for example, and use the HTML inspector to change the password field to be cleartext. Bam, theres your password.
Or he could install an extension which has almost certainly already been created which pulls the password store into the extension storage as soon as the store is unlocked, and then uploads it to a website.
So yes, you would prevent completely incompetent people from gaining access to your passwords, but that is NOT how you design security. You design based on the principle that people will always attack the weakest link, not the strongest, and in this case the correct choice is to let the OS handle keystore security.
You realize chrome IS using the OS "home" area to store the passwords, right? The reason that "passwords" was greyed out in the Chrome "import from safari" is probably because both use the OS keychain, so chrome would already have access to the safari passwords-- just like every other application running in the user's context.
If this guy is the head of 'security' for Chrome, he's either incompetent at that
Youre pretty clearly not the person to judge that as you not only dont understand how chrome is storing its passwords, you also apparently dont understand how the OS stores it, and what the threats being worked against are.
This thread is a goldmine of security theatre. Any hiring personnel could probably also use this to weed out folks who dont actually understand security.
Chrome's security tech lead gives a pretty good answer here:
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.
People worried about the security of this are worried over the wrong things. Firefox's master password would do absolutely nothing to stop a dropped-in extension from monitoring webpages for when passwords are filled, grabbing the filled form-data, and storing it in the extensions own preferences; and that wouldnt even take a background process, admin privileges, or really anything more than the ability to drop a file in the firefox profile.
I would be willing to place a large bet that in any scenario that would allow me to recover Chrome or Safari passwords, I would also be able to recover firefox passwords that are locked with a master password, within a reasonable amount of time. As has been said many many times, anything that tries to protect against a malicious user with access to your user session is pure security theatre.
So Safari has some security issues as well. Where is the "master key" to export passwords?
This whole article is basically an indicator of those who understand security, and those who do not. Author does not.
The reason this isnt a problem is that like any sane browser, Safari, Chrome, etc are using the OS's user keychain. If the user is logged in, the keychain is unlocked. It puts such security concerns where they belong-- with the OS. Any attack which could compromise Safari / Chrome would compromise Firefox even with a master password.
THe problem is that its only "sort of" secure in firefox.
Any scenario that might present a threat to Chrome's password storage would compromise Firefox's just as easily-- once the master password is input, the keystore is unlocked.
But having Firefox not show my encrypted passwords if I happen to forgot to lock up the desktop? That's still better than just letting them out without quibble.
The issue with firefox's method-- and why i stopped using if years ago-- is that it has to re-lock itself periodically, or else other programs / admins on the system can simply scrape from the unlocked keystore. But re-locking isnt preventing such an attack, its simply shortening the window of availability for an easily automated attack that would take just a few seconds to execute.
In other words, youre creating headaches that wont actually stop the sort of attack that it is designed to defeat. Any program that might scrape chromes keystore could also wait until the firefox keystore is unlocked, and immediately dump it. There simply is not any technical method to dealing with this other than "let the OS worry about userland security".
Someone with admin rights could replace the Chrome executable with a trojan'd version which keylogs everything you do and reports everything to the admins mailserver.
This just in: users cannot defend themselves against a determined systems administrator. He will just drop a userland rootkit in your logon session and all of your clever defenses are useless.
Someone with the capability to do so is by definition an administrator, and able to keylog everything you do quite trivially.
Im really glad most of the slashdot commenters here dont develop security systems, because they would constantly be reinventing the wheel to defend against attacks that cannot be stopped. Worrying about whether a sysadmin can get access to stored passwords is the LAST thing a browser should worry about.
Chrome stores everything in the cloud if you're logged into Google. That's what makes this even more dangerous than it's being reported.
Only if you request chrome to do so, and then specifically tell it to sync your passwords, and then specifically tell it to save your passwords. And if you do, it offers to let you use an encryption password for your chrome sync.
This is why two step authentication,
I believe "google account auth + secondary encryption key" counts as two factors.
It's not like it would even be that hard for Chrome to implement, so I'm not sure why there is such a struggle to add it.
Because it is the job of the OS to secure userdata, not the job of the browser. Chrome uses the "keychain" mechanism of whatever OS it is on, which is exactly the right thing to do.
Firefox certainly gets props for going beyond that, except for 3 things: A) a re-implementation of a keychain outside of the OS opens additional potential security issues. Generally the OS's keychain security will have more eyes / devs looking at it than Firefox's. B) 99% of users dont use the master password mechanism C) once the keychain is unlocked, whether it is the OS keychain or firefox's, any program can access it.
Yes, of course, but with the current system they are guaranteed access.
Only if the attacker is already running arbitrary code with access to the userdata, in which case youre screwed anyways. Such an attacker could simply log keypresses, or wait in the background for firefox's keystore to unlock, he has full access. Trying to defend against arbitrary code running in the user context is really not in the scope of what a browser should be doing.
Generally if you have access to the logged in session, it would be absolutely trivial to drop a userland agent which captures keystrokes, or waits until the browser's keystore is unlocked and then grabs credentials then. I think I recall seeing tips on how to snag someone elses keystore in that manner for firefox as early as the 1.0 days.
It would be great if chrome had some sort of master key, but A) 99% of users would not do it, and B) I do not think it is wrong to rely on the OS's security mechanisms, and to assume that "unlocked user session = access to all user data". I will be honest, I would not use chrome's master-key doohicky either, because when I want that functionality I use lastpass.
It is way overblown to call this "insane" when the vast vast majority of users dont use the password locking feature of the one browser that supports it.
They arent producing derivative works, theyre inserting content into the stream. IANAL, but it seems to me a derivative work would require redistribution, which theyre not doing; theyre simply dropping something in the middle.
If your reasoning was in the slighest valid, then every site that had third party scripts (facebook buttons, adwords, google analytics, etc) would also be liable.
One would hope that when objecting to such an awful idea, people could at least object for the right reason (like, oh i dont know, MITMing every connection is an awful idea from every single angle?)
I mean, if this prevent having to deal with the RIAA or the MFAA and all the legal expenses, wouldn't it be better to be warned and go "My bad." and move along?
If we set aside the whole "monitoring your connection" issues (privacy issues, who watches the watchers, etc) and pretend thats not a problem... and if this were them "sending you a friendly warning letter", maybe thered be some room for discussion.
But the only way to accomplish what Comcast is suggesting here is by MITMing all of your connections and injecting content into the middle. Thats great in company environment, and "less than great" on a home ISP connection where you have a high expectation of privacy. Off the top of my head, some major concerns here:
What if the JS that Comcast injects opens up security holes / info leaks?
What are your chances of holding them liable or proving it, much more given the nature of the notices-- you would essentially have to admit to everyone that you got one of these potentially embarassing notices
Will that injection be legally considered a "notice", and what happens if it never arrives (noscript etc)-- could that cause further liability on your end?
Will it trigger "unsafe connection" notices in otherwise Secure pages, and potentially open the door for SSL leaks (mixed content is a big security hole)
Are they MITMing SSL via a trusted CA? That presents about a million other concerns, if so
I am not one to rail at the RIAA / MPAA without acknowledging that there is an issue with piracy (or whatever you want to call it). But 95% of the time the issue is that the response-- whether by MPAA, RIAA, or the ISPs -- is that the response is completely over the top. This is a golden example-- Comcast here suggests completely undermining the expectation of privacy and integrity of the connection they provide.
Why do you think the Sandvine / bittorrent issue a few years ago was such a big deal? Its because "somebody" randomly inserting bogus traffic into your connection represents a MASSIVE threat.
Your whole arithmetic is completely wrong. There are vulnerabilities which are cross platform, for example a number of flash and adobe exploits. The work to discover a bug for windows is precisely the same as the work to discover one for linux.
The simple fact remains that Windows is the least secure platform, and you cannot just hand-wave that away.
Youre doing an awful lot of handwaving yourself. You are aware that this
most Mac/Unix users are not running as the equivalent of root as most Windows users are.
...has not been true for 6 years (the advent of Vista), right? UAC is exactly the same sort of control that OSX and linux have, and windows goes a step further by having much more granular controls over what an account can do than stock linux. You could, for instance, log in as the administrator on Win7, but you would be running with an unprivileged security context until you invoked UAC to elevate.
But then, ignorance has always been a mainstay of the accusations leveled against Windows by folks who apparently derive self-worth from insisting on the superiority of their favored OS.
Also, we should stop using this complicated "ASCII"; good old binary is much simpler.
Sometimes layers of abstraction are necessary to make sense of things. How much exactly is 1 beq, in terms of health effects? This is where "complicated biological models" are a lot more useful.
You forgot to mention that you need to specify that the page should not be spider'd in your robots.txt, so that the spambots know that they shouldnt parse the page. Setting the evil bit to 0 may help as well.
Should a government deal with it's own citizens more harshly than an enemy combatant (whom they would have killed had he not surrendered)?
No, and I didnt say that. But it is silly to claim something violates the geneva convention when its way outside the scope of the geneva convention. Keep in mind that the Geneva Convention isnt some magical standard of morality; its simply a treaty of how we agree to treat other nation's POWs so that they will reciprocate to our POWs.
We dont want our POWs summarily executed, for example, but that doesnt mean we cant practice capital punishment in our own justice system.
Have you actually used one? The guys at PA (who have been doing webcomics for a decade and a half, and presumably are good judges of sketch tools) reviewed one, and seem to indicate that it has sensitivity levels: http://www.penny-arcade.com/2013/02/22/the-ms-surface-pro
Plus, its not "worse than a wacom", it IS a wacom.
Slashdot Mirror
A limited account can still install extensions, userland rootkits (which do exist), background startup programs (which would have full access to the user's running program memory and files), and so on.
Seriously... I'm getting mad just at the thought that the head of any computer security team can think in this way.
Thats because like so many others you do not have a clear conception of what the actual threats are and the proper way of mitigating them.
This is really very simple: If the attacker has access to your session, you have lost. If an attacker has access to your machine and you have not used disk encryption, you have lost. If you dont understand why those two are true, you will not understand Google's response here, but if you were willing to place money on the line I could easily write you a service in AutoIt or Powershell which scrapes all of your "secured" firefox passwords and mails them to me with nothing more required than the ability to drop a file somewhere in your user profile.
Thats maybe the one scenario this would help against, and Im not convinced that should be a browser job rather than a full disk encryption job.
C) Yes, but it's not always guaranteed that the attack will happen when the master password keychain is unlocked or that it will be an ongoing attack. That means this is a security risk mitigation. I'm fine with that.
Someone wanting to attack a browser with such a mechanism would specifically design it to wait resident until that keychain was unlocked and immediately dump it.
The real issue with the "weak security" being suggested is that it will cause people to misunderstand the level of security they have. See all of the responses that are absolutely shocked that you dont NEED to give your password for a program to be able to access your OSX keychain; the password prompt had given them a false sense of security, and they had assumed that their computer was more secure unattended than it actually is.
It will stop anyone who happens to be on my machine from casually getting them.
Security theatre. Such an individual would take 5 seconds to google "how to dump chrome passwords", and would realize theres about 800 ways to do so. In a few seconds, he could browse to amazon.com, for example, and use the HTML inspector to change the password field to be cleartext. Bam, theres your password.
Or he could install an extension which has almost certainly already been created which pulls the password store into the extension storage as soon as the store is unlocked, and then uploads it to a website.
So yes, you would prevent completely incompetent people from gaining access to your passwords, but that is NOT how you design security. You design based on the principle that people will always attack the weakest link, not the strongest, and in this case the correct choice is to let the OS handle keystore security.
You realize chrome IS using the OS "home" area to store the passwords, right? The reason that "passwords" was greyed out in the Chrome "import from safari" is probably because both use the OS keychain, so chrome would already have access to the safari passwords-- just like every other application running in the user's context.
If this guy is the head of 'security' for Chrome, he's either incompetent at that
Youre pretty clearly not the person to judge that as you not only dont understand how chrome is storing its passwords, you also apparently dont understand how the OS stores it, and what the threats being worked against are.
This thread is a goldmine of security theatre. Any hiring personnel could probably also use this to weed out folks who dont actually understand security.
Chrome's security tech lead gives a pretty good answer here:
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.
People worried about the security of this are worried over the wrong things. Firefox's master password would do absolutely nothing to stop a dropped-in extension from monitoring webpages for when passwords are filled, grabbing the filled form-data, and storing it in the extensions own preferences; and that wouldnt even take a background process, admin privileges, or really anything more than the ability to drop a file in the firefox profile.
I would be willing to place a large bet that in any scenario that would allow me to recover Chrome or Safari passwords, I would also be able to recover firefox passwords that are locked with a master password, within a reasonable amount of time. As has been said many many times, anything that tries to protect against a malicious user with access to your user session is pure security theatre.
So Safari has some security issues as well. Where is the "master key" to export passwords?
This whole article is basically an indicator of those who understand security, and those who do not. Author does not.
The reason this isnt a problem is that like any sane browser, Safari, Chrome, etc are using the OS's user keychain. If the user is logged in, the keychain is unlocked. It puts such security concerns where they belong-- with the OS. Any attack which could compromise Safari / Chrome would compromise Firefox even with a master password.
THe problem is that its only "sort of" secure in firefox.
Any scenario that might present a threat to Chrome's password storage would compromise Firefox's just as easily-- once the master password is input, the keystore is unlocked.
But having Firefox not show my encrypted passwords if I happen to forgot to lock up the desktop? That's still better than just letting them out without quibble.
The issue with firefox's method-- and why i stopped using if years ago-- is that it has to re-lock itself periodically, or else other programs / admins on the system can simply scrape from the unlocked keystore. But re-locking isnt preventing such an attack, its simply shortening the window of availability for an easily automated attack that would take just a few seconds to execute.
In other words, youre creating headaches that wont actually stop the sort of attack that it is designed to defeat. Any program that might scrape chromes keystore could also wait until the firefox keystore is unlocked, and immediately dump it. There simply is not any technical method to dealing with this other than "let the OS worry about userland security".
Plus theres the whole "the attacker can simply wait for the keystore to be unlocked" thing, which makes the whole thing an exercise in futility.
Someone with admin rights could replace the Chrome executable with a trojan'd version which keylogs everything you do and reports everything to the admins mailserver.
This just in: users cannot defend themselves against a determined systems administrator. He will just drop a userland rootkit in your logon session and all of your clever defenses are useless.
Someone with the capability to do so is by definition an administrator, and able to keylog everything you do quite trivially.
Im really glad most of the slashdot commenters here dont develop security systems, because they would constantly be reinventing the wheel to defend against attacks that cannot be stopped. Worrying about whether a sysadmin can get access to stored passwords is the LAST thing a browser should worry about.
Chrome stores everything in the cloud if you're logged into Google. That's what makes this even more dangerous than it's being reported.
Only if you request chrome to do so, and then specifically tell it to sync your passwords, and then specifically tell it to save your passwords. And if you do, it offers to let you use an encryption password for your chrome sync.
This is why two step authentication,
I believe "google account auth + secondary encryption key" counts as two factors.
It's not like it would even be that hard for Chrome to implement, so I'm not sure why there is such a struggle to add it.
Because it is the job of the OS to secure userdata, not the job of the browser. Chrome uses the "keychain" mechanism of whatever OS it is on, which is exactly the right thing to do.
Firefox certainly gets props for going beyond that, except for 3 things:
A) a re-implementation of a keychain outside of the OS opens additional potential security issues. Generally the OS's keychain security will have more eyes / devs looking at it than Firefox's.
B) 99% of users dont use the master password mechanism
C) once the keychain is unlocked, whether it is the OS keychain or firefox's, any program can access it.
Yes, of course, but with the current system they are guaranteed access.
Only if the attacker is already running arbitrary code with access to the userdata, in which case youre screwed anyways. Such an attacker could simply log keypresses, or wait in the background for firefox's keystore to unlock, he has full access. Trying to defend against arbitrary code running in the user context is really not in the scope of what a browser should be doing.
Generally if you have access to the logged in session, it would be absolutely trivial to drop a userland agent which captures keystrokes, or waits until the browser's keystore is unlocked and then grabs credentials then. I think I recall seeing tips on how to snag someone elses keystore in that manner for firefox as early as the 1.0 days.
It would be great if chrome had some sort of master key, but A) 99% of users would not do it, and B) I do not think it is wrong to rely on the OS's security mechanisms, and to assume that "unlocked user session = access to all user data". I will be honest, I would not use chrome's master-key doohicky either, because when I want that functionality I use lastpass.
It is way overblown to call this "insane" when the vast vast majority of users dont use the password locking feature of the one browser that supports it.
They arent producing derivative works, theyre inserting content into the stream. IANAL, but it seems to me a derivative work would require redistribution, which theyre not doing; theyre simply dropping something in the middle.
If your reasoning was in the slighest valid, then every site that had third party scripts (facebook buttons, adwords, google analytics, etc) would also be liable.
One would hope that when objecting to such an awful idea, people could at least object for the right reason (like, oh i dont know, MITMing every connection is an awful idea from every single angle?)
I mean, if this prevent having to deal with the RIAA or the MFAA and all the legal expenses, wouldn't it be better to be warned and go "My bad." and move along?
If we set aside the whole "monitoring your connection" issues (privacy issues, who watches the watchers, etc) and pretend thats not a problem... and if this were them "sending you a friendly warning letter", maybe thered be some room for discussion.
But the only way to accomplish what Comcast is suggesting here is by MITMing all of your connections and injecting content into the middle. Thats great in company environment, and "less than great" on a home ISP connection where you have a high expectation of privacy. Off the top of my head, some major concerns here:
I am not one to rail at the RIAA / MPAA without acknowledging that there is an issue with piracy (or whatever you want to call it). But 95% of the time the issue is that the response-- whether by MPAA, RIAA, or the ISPs -- is that the response is completely over the top. This is a golden example-- Comcast here suggests completely undermining the expectation of privacy and integrity of the connection they provide.
Why do you think the Sandvine / bittorrent issue a few years ago was such a big deal? Its because "somebody" randomly inserting bogus traffic into your connection represents a MASSIVE threat.
Your whole arithmetic is completely wrong. There are vulnerabilities which are cross platform, for example a number of flash and adobe exploits. The work to discover a bug for windows is precisely the same as the work to discover one for linux.
The simple fact remains that Windows is the least secure platform, and you cannot just hand-wave that away.
Youre doing an awful lot of handwaving yourself. You are aware that this
most Mac/Unix users are not running as the equivalent of root as most Windows users are.
...has not been true for 6 years (the advent of Vista), right? UAC is exactly the same sort of control that OSX and linux have, and windows goes a step further by having much more granular controls over what an account can do than stock linux. You could, for instance, log in as the administrator on Win7, but you would be running with an unprivileged security context until you invoked UAC to elevate.
But then, ignorance has always been a mainstay of the accusations leveled against Windows by folks who apparently derive self-worth from insisting on the superiority of their favored OS.
Also, we should stop using this complicated "ASCII"; good old binary is much simpler.
Sometimes layers of abstraction are necessary to make sense of things. How much exactly is 1 beq, in terms of health effects? This is where "complicated biological models" are a lot more useful.
Like an image of a baby and three buttons saying MAN, WOMAN, BABY.
Why wouldnt the hypothetical spambot just guess randomly? 33% success rate makes it useless.
You forgot to mention that you need to specify that the page should not be spider'd in your robots.txt, so that the spambots know that they shouldnt parse the page. Setting the evil bit to 0 may help as well.
Oh come on, Apple started this war. Probably not a good idea to go after the company providing so many of your components, but whatever.
Should a government deal with it's own citizens more harshly than an enemy combatant (whom they would have killed had he not surrendered)?
No, and I didnt say that. But it is silly to claim something violates the geneva convention when its way outside the scope of the geneva convention. Keep in mind that the Geneva Convention isnt some magical standard of morality; its simply a treaty of how we agree to treat other nation's POWs so that they will reciprocate to our POWs.
We dont want our POWs summarily executed, for example, but that doesnt mean we cant practice capital punishment in our own justice system.
Have you actually used one? The guys at PA (who have been doing webcomics for a decade and a half, and presumably are good judges of sketch tools) reviewed one, and seem to indicate that it has sensitivity levels:
http://www.penny-arcade.com/2013/02/22/the-ms-surface-pro
Plus, its not "worse than a wacom", it IS a wacom.