Here here. [1] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ben Scott Sent: Wednesday, August 7, 2013 3:28 PM To: [email protected] Subject: Re: [NTSysADM] Google Chrome stores passwords in plaintext
On Wed, Aug 7, 2013 at 12:21 PM, Micheal Espinola Jr <[email protected]> wrote: > http://www.theguardian.com/technology/2013/aug/07/google-chrome-passwo > rd-security-flaw > > No obfuscation to the casual snooper, no master password, no nothing. > This is the same thing that Firefox caught flack for 3 years ago. If your browser lets you "save" a password for replay, then it *has* to store the password in a fashion that can be reversed. There's no way around this. Obfuscating the stored passwords does precisely nothing, because the browser *has* to be able to reverse it. The bad guys will happily write their own UI if you don't provide one. (This has happened to more than one iteration of the password bank that comes with Windows.) You can't make this difficult for the bad guys to do without also making it difficult for the browser to do. You want it to take 20 minutes for the bad guys to decipher the password bank? Then it will take 20 minutes for the browser to do so, too. Firefox still has a "Show passwords" button, FYI. The lack of the ability to cipher the database using a user-provided password as a key *is* a problem, and something Chrome deserves heat for. But once the user has provided it for the current session, then you've still got the exact same behavior a lot of people are complaining about, and prolly would still be complaining about, because they don't get it. This reminds me of when Steve Gibson started ranting about raw sockets. Paying attention to this kind of thing encourages the introduction of behaviors that prevent professionals from getting work done, provides people who don't understand a false sense of security, and slows the bad guys down not one iota. -- Ben [1]Or, for Ben: Here, here.
