Chrome and Firefox extensions not seeing vault

Arghh! After yet another Windows re-install, my 1Password extensions are not working in Chrome or Firefox. The add-ins buttons are there, but the resulting pop-up windows do not have contact with the vault. None of my data is visible, but it does offer to save new logins. The first tab on the interface shows "all vaults" as the only item in the list, the "all items" tab shows an empty list. Are they accessing some new, empty vault? The IE plugin works fine and has my vault data. Desktop 1Password also sees the data fine, and even the 1Password anywhere web interface is fine.

1Password for Windows Version 4.6.2.626
Microsoft Internet Explorer 11.125.16299.0
Mozilla Firefox 57.0.2 Installed 4.6.12.90
Google Chrome 63.0.3239.108-6-4 Installed 4.6.2.12.90

I have tried uninstalling the extensions, re-installing them and rebooting the computer with no effect.


1Password Version: 4.6.2.626
Extension Version: 4.6.2.12.90
OS Version: Windows 10 Latest
Sync Type: Local (USB Stick)

Comments

  • brentybrenty

    Team Member

    @JohnHind: Thanks for reaching out. I’m sorry for the confusion! Since 1Password 4 does not have an "All Vaults" feature, it sounds like you've also got 1Password 6 installed and that's where you're running into trouble. Given that you're using a local vault, you'll want to remove 1Password 6 and use 1Password 4 to open that. Having only one version will also mean that you won't have to deal with both of them trying to connect to the browser extension, and 1Password 4 is also compatible with Microsoft's legacy Internet Explorer browser. So, to be clear, the only thing you should do is uninstall 1Password 6. The browser extension you're using will work fine with both versions, but not both at once. I hope this helps. Be sure to let me know if you have any other questions! :)

  • @brenty: Thanks for reaching back! I had installed 1Password 6 in error and had not removed it when I installed 1Password 4. After removing 1Password 6, Chrome works fine too. However Firefox shows the 1Password button greyed out. About once a minute, it flashes very briefly into availability and immediately greys out again. Is it trying to access the vault but failing for some reason? Again I've tried uninstalling, booting and reinstalling the add-in but no change. I also tried shutting down all Chrome instances in case both cannot access the vault simultaneously.

    As a suggestion, it would be helpful if somewhere on the UI the version of 1Password being assumed would be mentioned. For example, instead of "All vaults" you could say "All 1Password6 vaults", or there could be an '''About" button. I had installed the extensions from the 1Password 4 Preferences dialog and it had reported 4.6... version numbers for the extension in both browsers, so I assumed all was well.

  • brentybrenty

    Team Member

    @JohnHind: I'm not sure I agree, since I can't think of any software where it would be a good idea to try to install and use multiple versions simultaneously, but it's something we can take into consideration. Also, "All 1Password 6 Vaults" would not make much sense and be confusing since only 1Password 6 has the All Vaults feature, and it is impossible to use multiple versions in the browser at the same time.

    If you've got 1Password 6 uninstalled though, I think there's just one more thing you need to do: remove the 1Password extension from the browser (in case it is still trying to connect to 1Password 6), enable Native Messaging in 1Password 4 Help > Advanced, restart Windows, and install a fresh copy of the 1Password extension:

    https://agilebits.com/onepassword/extensions

    And just to be clear, 1Password 4 works with one vault at a time, so you will only see data in the main app or browser extension for the vault you currently have open. Let me know how you get along! :)

  • JohnHindJohnHind
    edited December 2017

    Thanks again @brenty. The Native Messaging magic spell was all that was needed to get it working.

    Maybe the installer for 1Password 4 could warn about the presence of 1Password 6 and even offer to uninstall it? It is all too easy to install 1Password 6 by mistake since we all assume we want the latest version (as I would if 1Password 6 would work with a local vault). Call me paranoid, but there is no way I would ever store my passwords on the cloud, however good you guys are at security, the risk just massively outweighs the benifits in my opinnion.

  • brentybrenty

    Team Member

    Thanks again @brenty. The Native Messaging magic spell was all that was needed to get it working.

    @JohnHind: Thanks for letting me know! Glad that helped! :chuffed:

    Maybe the installer for 1Password 4 could warn about the presence of 1Password 6 and even offer to uninstall it? It is all too easy to install 1Password 6 by mistake since we all assume we want the latest version (as I would if 1Password 6 would work with a local vault).

    1Password 4 pre-dates 1Password 6, so it does not have a way of detecting it. Also, some of us do use both (though I wouldn't recommend it). You can always install the appropriate version from the license email you received, which you'll need to register the app anyway. I don't expect we'll be making elaborate changes to 1Password 4 given that it will soon be superseded by version 7. I think our time and effort is best spent there.

    Call me paranoid, but there is no way I would ever store my passwords on the cloud, however good you guys are at security, the risk just massively outweighs the benifits in my opinnion.

    I hear you. And we feel the same way. That's why 1Password never stores anyone's passwords "in the cloud". It sounds like security is your chief concern (as it should be), and frankly it's ours as well. Otherwise we wouldn't use 1Password.com either! There's a lot more detail in our security white paper (which is actually a really fun read, even if you're not into cryptography), but I'd like to offer a few points that summarize how 1Password secures our data:

    1. Your 1Password data is encrypted locally on your device before it is transmitted.
    2. The server receives only an encrypted blob.
    3. Your Master Password is never transmitted.

    You might think I'm talking about 1Password.com specifically there, but that's the case no matter what 1Password setup you use — the only difference being that 1Password.com data is also encrypted using the 128-bit randomly generated Secret Key, which is also never transmitted to us. So there's an additional layer of security there as well.

    Indeed, when you use 1Password, AgileBits never has access to your data, regardless of the setup you choose. Even with 1Password.com, your data is encrypted on your device, so all the server ever ends up with is an encrypted blob. And since the Secret Key is created locally, your Master Password is only known by you, and neither is ever transmitted to us, only you have the means to decrypt the data.

    Suffice to say, if someone gains access to our servers and dumps the full database (we've designed 1Password.com with this in mind), they simply don't have what they need to decrypt it, as each individual user alone has the keys to their data. So an attacker won't have that and can't get it from AgileBits, even if they get everything else. So while there's a lot more that goes into making all of this work smoothly, this is something that I think all of us can appreciate. Cheers! :)

  • @Brenty: Actually I do not have my licence email. I store my licence code in 1Password! Hopefully you will always preserve the ability to read a vault without a licence or I'm screwed! Every time I have to copy and paste the licence from one dialog to another in 1Password I'm thinking "couldn't it do this for me" though!

    From the above I hope what you are saying is that version 7.1 will support local vaults alongside cloud vaults, with the same interface.

    The scheme you describe does seem watertight, but it requires blind trust both that you actually intend to implement the scheme as described and that you are competent to do so. You are not offering compensation for losses, so the risk is mine. Additionally, there is the bank vault argument. It simply is not worth criminals putting much effort and investment into steeling my net worth, but if I put my modest stash of doubloons in a bank vault known to be used by the local billionaire I risk becoming collateral damage to much more ambitious criminals.

  • bundtkatebundtkate

    Team Member

    @JohnHind: If you ever need another copy of your license e-mail, we can have it resent to you -- just ask. :chuffed:

    Every time I have to copy and paste the licence from one dialog to another in 1Password I'm thinking "couldn't it do this for me" though!

    It would be cool if 1Password could hunt through your vault for a license key and apply it for you. 1Password memberships effectively do this already as your account status is sent to the apps by the server letting it know to unlock full functionality. We haven't fully hashed out how licensing will work in 1Password 7, but doing something similar with licenses is something to consider as we're developing it for sure and I'll definitely share your thoughts with the development team. :chuffed:

    From the above I hope what you are saying is that version 7.1 will support local vaults alongside cloud vaults, with the same interface.

    That's what we're aiming for. Accounts and standalone vaults use the same app on Mac, so while we don't know exactly what all of this will look like in 1Password 7 for Windows just yet, one goal is definitely to better mirror the experience on Mac. Plus, we definitely want to ease the struggle for folks using both a standalone vault and a 1Password.com account. Since each and every one of us supports both 1Password 4 and 1Password 6, we're very familiar with having to juggle the two and I doubt much of anyone will be happier to see the end of that than us. :wink:

    it requires blind trust both that you actually intend to implement the scheme as described and that you are competent to do so.

    We actually do our best to eliminate the need for that blind trust where we can. We don't obfuscate our code and would absolutely encourage folks to reverse engineer our apps to see how they work. If you'd like to man-in-the-middle yourself and inspect the traffic between app and server, we say go for it. The Security White Paper brenty linked earlier will do a much better job at explaining the technical details than I will. In fact, I'd probably be complete rubbish were I to try, so instead I'll point you there and, should you have any questions, @rickfillion told me he'd be happy to hop in when he's back after Monday's holiday to answer questions and I'm sure others will have insights to add as well. So, if you have questions, ask away. :+1:

    Additionally, there is the bank vault argument. It simply is not worth criminals putting much effort and investment into steeling my net worth, but if I put my modest stash of doubloons in a bank vault known to be used by the local billionaire I risk becoming collateral damage to much more ambitious criminals.

    When folks have concerns about "cloud storage" in general, this tends to sum up that concern, and overall it's a very legitimate concern. In fact, this was one thing that motivated the use of the Secret Key. Greater risk demands greater security and the Secret Key is a guaranteed strong layer of protection that pushes the entropy of your keys above a certain threshold that likely won't be attained with your Master Password alone. You can take a peek at the math here (and again, in the White Paper), if you're interested.

    We developed 1Password.com accounts knowing that we'd be an attractive target and our security design was implemented with that in mind. Rather than trying to protect secrets, we designed things so we never have them in the first place. As our Chief Defender Against the Dark Arts has said, we cannot misuse or leak what we never have in the first place. I'd add that it's unwise to assume we're immune from mistakes and better to design things in such a way that the damage can result from mistakes is as close to nil as we can make it and we feel we've done just that. But, of course, that's up to you to decide and one of the reasons we're happy to spend whatever time we need to talking about security and spent the time to write documents like the White Paper so that you have the tools you need to make that decision for yourself. :chuffed:

  • Thanks again @brenty and @bundtkate for your generosity with your time explaining this. The White Paper is indeed very impressive, particularly the honesty of the "beware of the Leopard" section! The link in @brenty post did not work however, I found it here:

    https://1password.com/files/1Password%20for%20Teams%20White%20Paper.pdf

    While very impressive technically, I think this needs more consideration of legal jeopardy though. For example you could be compelled by law to secretly deliver a malicious client with a back door for law enforcement and this back door could be discovered and used by criminals. Technically, this is just as concerning for the locally stored vault scenario, but legally it is probably less likely. A court can argue that it has a right to search data held in its jurisdiction and compel you to take any measure to cooperate in decrypting it, up to and including delivering a malicious client. Technically this would be no different searching data on a computer outside that legal jurisdiction, but legally that would be hard to justify.

  • brentybrenty

    Team Member

    @JohnHind: I'm really sorry about that. Apparently we broke our nice little short URL for the white paper. I appreciate you letting me know so we can fix it. :(

    ref: AGW-397

    As for security, apart from our own efforts, we participate in external audits and cooperate with independent security researchers to find any flaws so we can fix them.

    And there is no law that can compel us to do the bidding of governments. We only do this work because we love it, and faced with being ordered to do something we don't love would have us looking for other jobs. I think our website says it better than I ever could though:

    Absent a restraint authorized by Canadian law, customers for whom responsive data is held will be notified and will be provided a complete copy of the request for their data.

    Certainly it is within our power to turn over encrypted data, but there is a high bar that must be met before we will even do that, in accordance with Canadian Law:

    Information for Law Enforcement

    But again, encrypted data is all we have, not the means to decrypt it. And this, to me, is the most important thing as a 1Password user myself:

    Secure Data is owned exclusively by our customers and we have no plaintext access to this information. This means we have no means by which we are capable of providing decrypted information which may be stored in 1Password account vaults.

    Ultimately we just don't have the kind of information that would be useful to anyone targeting 1Password users, whether that be malicious hackers or governments, and that makes 1Password a much less interesting target for both. It is because of these threats that we've designed things the way we have, and that we continue to test our assumptions and allow others to freely do so as well.

    And I think you hit the nail on the head: it's much more likely that a government or criminal would be successful in getting to your data through you, since you're the only one with the means to access it. Much less cost and effort for them to come after you with a persuasive wrench than try to coerce all of us us to essentially rewrite 1Password so they can get your stuff. Cheers! :)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file