On 3/18/2016 10:15 AM, NFN Smith wrote: > > I think this is particularly true with Internet Explorer -- I've always > found Microsoft's methodologies of "remembering" passwords via the > registry to be sloppy, and that they're far too aggressive about > offering to remember, and where it's too difficult to rescind, if the > user changes their mind, or accidentally remembers, when they don't want to. > > Although that stuff is encoded, it's not encrypted (and no requirement > for user authentication for access, beyond having a valid login for > Windows). To me, that's a security-by-obscurity thing, where it seems > likely that a script writer who knows what he is doing should be able to > extract that content from the registry. I've always been surprised that > the security experts don't push Microsoft a lot harder on that one, > although it's entirely possible that there's something that I'm missing. > > However, I have seen reviews of comparative browser security, and > working from memory, I remember seeing that without a password, Mozilla > rates medium or medium-to-low, and below Google Chrome, but I think > about even with Internet Explorer. However, with the master password, > Mozilla is at the top. > > I do know this -- using the various password recovery tools from > Nirsoft, it's pretty easy to extract remembered passwords. If I'm > troubleshooting on somebody's machine, I will occasionally run these > tools (with the user present), as a way of demonstrating the > vulnerability of passwords saved in the browser (if not protected by a > master password). > > I think also that a majority of developers don't really account for the > idea of using third-party password managers. There's a comparatively few > number of people who use them, and from a development stand point, > trying to account for them merely adds complexity, and their focus tends > to be on facilitating the lowest common denominator of non-technical > user. That, in itself, is a challenge, because there's still far too > many many people who want one-button convenience, and where the > mechanics of proper authentication are an annoyance. > > True, although there is definitely a "speed bump" effect, if you you > have to click on a graphical button that takes you to another page, and > then requires subsequent data entry. > > And more sites are moving to setups that do lock-outs after multiple > failed authentication. Thus, for the bad guys, there's a lot more > emphasis of finding places where passwords have been reused. > > Consider: > http://www.eweek.com/security/sentry-mba-uses-credential-stuffing-to-hack-sites.html. > > The place where this is especially problematic is that so many sites use > email addresses as user IDs, and there's an implied encouragement to end > users to use the same passwords with those IDs. Thus, if an intruder > can get a password that is connected to an ID that is an email address, > then the logical first thing to do is to try that combination at every > possible site that that combination may work with -- not only the email > provider, but sites such as Amazon, PayPal, and more. > > I know that several years ago, when Adobe got its user list hacked (and > where user IDs are email addresses), I remember that they did warn users > that those IDs at other sites were vulnerable, if passwords had been reused. > > With "memorable information", some sites may have several questions, and > where the question posed rotates, from login to login. I've also seen > one site that has a user-selected graphical image (selected at the time > of account creation). I haven't studied the mechanics of that one, but I > know if that image isn't displayed, then it's evidence of tampering. > > That's where I am. I know that KeePass supports scripting, although the > syntax is a little cryptic, and I haven't tried to figure it out. > > However, that's definitely something that is for techies, and something > that somebody that isn't a power user is likely to figure out, unless > somebody does it for them. > > For what it's worth, I'm guessing that some of the other third-party > tools (such as LastPass or 1Password) are likely to be focused enough on > supporting non-technical users, that their scripting capacity may be > limited, although I'm sure that what's possible or not varies > significantly from tool to tool. > > Smith >
Enabling the use of a master password causes the Password Manager's database to be encrypted. The master password itself is not stored on the computer and should exist only in the user's head. I am not sure, but I think the encryption is symmetrical. That is, it uses the master password as the encryption key for both encrypting and decrypting the stored passwords. Bug #973759 proposes to strengthen this process. See <https://bugzilla.mozilla.org/show_bug.cgi?id=973759>. Prior to the complete implementation of the capability to save and use passwords for Web sites that try to prevent such actions, I examined several non-Mozilla password management tools. Some saved the passwords in the cloud, a point of vulnerability. Others were vague on how they secure the password database. I decided that using the Mozilla Toolkit's Password Manager provided me with more comfort than those non-Mozilla tools. -- David E. Ross While many tributes to the late Supreme Court Associate Justice Antonin Scalia now fill the news media, his legacy was not necessarily positive. See my "What Price Order, Mr. Justice Scalia?" at <http://www.rossde.com/editorials/edtl_scalia_wrong.html>. _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
