Browser Extension Password Managers Exposing Passwords Everywhere
isecpartners.github.io
isecpartners.github.io
In addition to this being potentially more secure, another benefit is that I can specify that KeePass open certain sites in a non-default web browser. I prefer not to log into some sites/accounts using my primary web browser, and KeePass helps me to avoid this. If I were to use a solution like LastPass for all my password management, I would need to pause and recall which browser I use to log into a site/account. But with KeePass, I just mindlessly Alt-Tab, Ctrl-F, Ctrl-C, and Ctrl-U.
One way of characterizing the particular paper is "password managers with browser extensions don't always prevent you from submitting your data to the wrong place."
Systems that rely on the user to copy/paste offer no such protections whatsoever (and so, I suppose, can't fail at them.) So I'm curious about what you may mean by "potentially more secure" in this particular respect. Are you concerned that you might come to rely too heavily on the password manager's anti-phishing mechanisms?
[Note that I fully acknowledge that there may be other security reasons you may wish to keep your password manager out of browser. 1Password and KeePass have different security architectures, development processes, platform support, etc, with their own advantages and disadvantages. People need to figure out which works best for them.]
For some people, the risk of disclosure by violence is more a worry than the risk of disclosure by the clipboard.
I originally looked at Lastpass, but it seemed 'too' easy. Decryption is done client side via javascript, but what happens if someone hacks into Lastpass's server, and modifies the code to send the user's entered password to their server?
I actually just released an account manager for Chrome, called Waltz. Waltz uses Clef (http://getclef.com) for multi-factor auth, and then submits using preconfigured login URLS - not heuristics like most other password managers.
After a semi-thorough read of the article, I don't believe Waltz falls into any of the security holes mentioned in the article.
From skimming the paper, the only real flaw that seems broadly applicable is in autofill features which I'm not sure 1Password even has. Those intuitively seem like a bad idea and are easy to disable.
But that doesn't justify this clickbait title which is simply untrue as nowhere in the report does it say that passwords are shared "everywhere."
EDIT: Nevermind..you can configure either behaviour. Either fill in or fill & submit.
1Password seems to be just fine according to this paper. It did not fuck up like Lastpass and only live flaw is about subdomain matching, which I actually find useful.
LastPass has me enter the master password in a pop up window when I click on the icon from the extension (firefox/chrome), although I suppose that's maybe not as good as an independent application?
I can, not only disable autofill in the Lastpass configuration, but also set to require password reprompt for any of my credentials. I could also individually disable autofill for any credential.
Please should first know how something works before criticizing.
In 1Password 4, there is no auto-filling. People can use Ctrl-\ or Cmd-\ to tell 1Password to "fill this page". In versions prior to 4, auto-fill was an option. (I'm not sure which versions had what defaults.)
But tumbler allows JavaScript redirects to phishing sites, so yahoo standard I guess.
If a form doesn't have a submit action, what's the point of the form?
If you have HTML and CSS, why not have forms?
A lot of my other accounts can be more easily hacked, but relatively little harm would be done if they were. I think one of my MMO accounts -- to a game I no longer play -- actually was.
"send it to your yahoo mail and LastPass would fill it up and submit because it's served under yahoo domain."
I am actually a LP user, but I would prefer it was more secure by default.
https://news.ycombinator.com/item?id=6943837
Actual Link: https://helpdesk.lastpass.com/security-options/multifactor-a...
I tried poking around with the add-in, but couldn't quite determine whether the implementation could properly protect from replay attacks, most notably whether a copy of the xml file used and the matching old OTP would be enough to unlock a newer database file.
In theory you could guarantee the OTP going forward, but it would be impossible to protect going backward, which kind of kills the whole point.
If instead you mean "browser-integrated" as in the default "remember my password", well, those are not what this paper discusses and are generally better, though they are still not as desirable as a standalone less-privileged manager.
The idea that the password manager should be separate is practically common sense. Browsers provide more surface are for attack. Browsers are made to share content and work with network data. Ideally, your password manager should never touch the network ever. It has no need to.
What the hell happens if I lose the yubikey? Or indeed anything else that substitutes as the 2nd factor?
We need to put the headline and some of the odd generalizations stated in the paper aside, and look at the specific security issues raised. When we do that, we find that 1Password matches or exceeds the "far more secure" built-in form fillers.
If we ignore the title and some odd generalizations, this paper actually spells out how well 1Password avoids various risks when you look at the details.
Readers need to go through section 2 of the paper carefully to see which studied systems do what. The most worrisome of the kinds of flaws that browser-based password managers face (filling things for https://foo.example into http://foo.example and filling for bar.example origin forms on foo.example pages) are things that 1Password handles correctly.
The things that we don't do "right" in their eyes are things that their recommended alternative (built-in browser form fillers) also don't do "right". I'm not sure that the authors have fully thought through would it would even mean to do those "right". But I encourage people to read the paper and decide for themselves whether we've made the correct choices in our handling of subdomains, and whether filling should be tied to a specific page on a site.
What of course does need to be considered are the risks of not using something in the browser. If you are copying and pasting from your password manager to your browser you are far more likely to be tricked by phishing, or cross origin forms than you would be with 1Password.
1Password tries to make it hard for you to fill in your credentials in the wrong place (you have to use copy/paste to manually do it where 1Password refuses to do it automatically), and to the extent that the concerns in the paper are legitimate, there are cases where browser-based fillers may fail to "make it hard" where the should.
Contrast that with the alternative of using copy/paste. Copy/paste offers no protections whatsoever against you filling in credentials to the wrong web form.
It would be foolish to claim that 1Password's phishing prevention mechanisms can't ever been defeated. But with respect to what was tested in this paper, they are the best out there.
Update: No, not able to set up a global policy - I'll contact them.
I didn't come here to engage in sales pitches, but when you specifically ask for a feature introduced in 1Password 4, it is hard for me not to mention it. 1Password Mini lives in the Menubar and does what you wish. There are also options for Alfred and LaunchBar integration.
The takeaway here is to turn off auto-fill and auto-login. You'll still get most of the convenience of the browser extension password manager: a repository of strong passwords that you don't have to remember and can access easily on multiple devices. This is why I use LastPass. I used to use KeePass and even donated to the project, but I wanted more convenience, support in the long run, and never liked the .NET dependency.
I trust my own brain rather more. And if my brain is comprised, what else can you do with all the security we have on our desktop?
The old-school method is to use a GPG-encrypted flatfile with your passwords in it.
I generate unique, long, passwords for each site I visit. There are _very_ few of these I can remember. I'll run:
gpg -d passwords.asc | grep siteurl
1) Over the years it ends up being much more than 20 passwords. Bank accounts, credit cards, stock trading accounts, web servers, email accounts, IRA accounts, bitcoin passwords/keys, all kinds of work passwords, evernote, etc. I have more than 50 records in KeePass.
2) If you want secure passwords, they must be long (20 characters minimum) and random. Remembering something like that is nearly impossible for me. Once I started using KeePass, I feel way more secure than with my older scheme.
Don't sign up hundreds of accounts. I only have one bank so that's just one password.
Relying on another software to take care of security like this is not a good solution to me.
https://github.com/mstarke/MacPass
It's alpha but been stable for me for a month or two.