Opt-out of Haveibeenpwned

Hello all,
during trying out the service I have activated the Haveibeenpwned check for a vault in the Webinterface under the assumption that the activation can be reverted at a later time. This does not seem to be the case however. At least I can’t seem to find the function.
Could you please point me in the correct way to opt out of sending data to Haveibeenpwned again? Thanks!

I‘m aware how Haveibeenpwned works and that the security risks are supposed to be minimal, but I still would like to deactivate the option but still use the rest of the Watchtower functionality

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided


  • MeekMeek

    Team Member

    Hey @kslfngdlsr,

    The easiest way to disable it once you've opted in is to clear your browsing data - however, that will clear all data for all websites, which is likely not something you'll want to do. You can reset this one specific item, but it is a bit more involved.

    In Chrome, you can do so like this:

    1. Click View > Developer > Developer Tools.
    2. Select the Application tab.
    3. Click the disclosure arrow beside Local Storage.
    4. Click on the only element in that list beginning with https://
    5. Select the item that starts with hibp_ and change the value to false

    Let me know how that goes or if you have any more questions.

  • edited February 2019

    Hi Meek,

    I tried just that - deletion of all browsing data - in the internal 1Password browser of the iPad app. This is the place where I activated the functionality to begin with and the only place where I used the web interface.
    Then I logged into the web interface again und clicked on Watchtower. It again showed me the Passwords that are vulnerable according to HIBP. I would have expected to be prompted again for activation the HIBP functionality as I had been the first time. But this did not seem to be the case. Any ideas?

  • MeekMeek

    Team Member

    Hey @kslfngdlsr,

    Hmm, that definitely should have cleared it out. Just to confirm, when you cleared the browsing data, did you go into the 1Password app > Settings > 1Password Browser and click the Clear Web Data button?

  • Yes, I did exactly that. Just tried it again with the same undesired result.
    What I also found was that currently open tabs are being preserved. I would have expected that when I reset all website data that also open tabs will be removed as it is the case for example when you do the similar operation in Safari under iOS. But that does not seem to be the case.

  • Hey @kslfngdlsr were you able to close the tabs and repeat the same steps with any success?

    Out of curiosity... on your iPad if you open Settings > Safari > Advanced > Website Data and then search for "1password.com", do you see any results? If so... perhaps swipe to delete and then try again?

    Any success?

  • So, I did a few more tests:

    1) 1Password Browser:
    Closed all tabs and repeated to delete website data: no change, the opt in option I still not there. Also, wenn I go to https://my.1password.com in the internal browser (manually going to the website, not clicking on the link in the login data set to avoid autofilling the login data) the Secet Key is already prefilled (see below why I find that perculiar)

    2) Safari on iPad in private mode:
    As expected for the first login in safari I could opt in to HIBP. Once I logged out and in again I had to opt in again as no website data is being saved in the private mode. Also here the Website data display option in the settings app did not show anything. Everything fine.

    3) Safari on iPad Not in private mode:
    Once opted in the HIBP setting stayed even after logging of and logging on. Here the website data in the settings app showed entries for 1Password and HIBP. Once I cleared the safari website data I again saw the opt in option. So far everything as expected

    Basically in Safari all is how it is supposed to work, but in the 1Password browser it is not.

    Regarding the Secret Key in 1): In Test 3) the Secret Key was prefilled upon loading the website for the second login attempt. After deleting the website data I had to enter the secret key again. In Test 2) I had to enter the secret key every time I loaded the website. In test 1) the Key is prefilled every time, even after resetting website data. That leads me to two conclusions:

    A: Somehow the secret key seems to be related to website data stored in the background. Maybe some clarification is required where it is stored and how it is filled? My understanding so far was it is stored in the iOS keychain? How is this related to the website data?

    B: The deletion of Website Data in the 1Password Browser seems to have some issues and works not for everything. That reduces somewhat the trust that I have in it as you might understand.

  • Hey @blaxxz...

    The integration is entirely safe, as you mention. The current implementation is indeed setup to be device specific, but it could indeed also be a setting on the account instead. We try to keep account settings like that to a minimum, which is why it's implemented this way, but I'll mention this to the rest of the team and it may end up making its way there.

    Thanks for the feedback, we love to hear it.

  • LarsLars Junior Member

    Team Member


  • @brettbollman

    This morning I typed out a long answer to my last question to me. When I edited a minute after posting the system told me that my comment would be displayed once it got approved or something like that. Any idea what’s up with that?

    Anyway here now the shorter summary as I can‘t be bothered at the moment to retype the long version:

    I closed all tabs in the 1Password browser and it did not make a difference. Somehow I can’t get rid of the setting in 1Password irrespective of what I try.

    I tried the same in safari on iOS and there everything worked perfectly. In the private mode as expected I have to renewable HIBP with every login and outside the private mode the browser remembers but resets correctly when I delete all browsing data.

    But what it found as well is the following: every time I login in the 1Password Browser the secret key is already filled in (not an input field but as „hard text“). This is the same behavior as in Safari in the non private browsing when I login the second time. But in Safari everything resets when deleting the browsing data and also the secret key has to be entered again for the next login.

    From a completely unknowing perspective it seems like the website data reset function in the 1Password browser doesn‘t do anything. At least in regards to 1Password data.

    Can maybe somebody else confirm that as well?

    On a related note: as it seems the secret key is stored together or at least related to the website data in the browser I was foundering how this works from a security point of view? I thought the secret key is stored in the iOS keychain?

    Best regards

  • brettbollmanbrettbollman

    Team Member
    edited February 2019

    Hey @kslfngdlsr...

    Thanks for the original longer post you wrote out... it did indeed go into a moderation queue because of the link you added in. It's now in the thread in its entirety. Thanks for all the detail and sorry to have to make you post twice.

    This is definitely sounding like a bug of some sort, so I've kicked off a conversation here internally. Hopefully it's not and I'll be able to come back with a solution. Otherwise, I'm sure we'll be looking into squashing it. The temporary fix here with regards to haveibeenpwned.com, is of course to simply not load the Watchtower using the 1Password Browser, which is the only place where you have the integration enabled. Not ideal, but also under your control now that you know exactly what is happening.

    As for the Secret Key, it does indeed get stored in the browser's local storage. This makes the browser a trusted device and therefore does not require you to input it every time you visit the site. In our native apps, 1Password for Mac and 1Password for iOS, the Secret Key is stored in the respective keychain as you mentioned. When signing-in via a browser, there is the option to check the box for "This is a public or shared computer" which will then not store the Secret Key along with other details in your browser's local storage.

    Here's a snippet from our security design white paper about the local storage of your Secret Key:

    Locally exposed Secret Keys

    Once a client is enrolled, it will store a copy of the Secret Key on the local device. Because the Secret Key must be used to derive the user’s Master Unlock Key (MUK)􏰏􏰑􏰂 it cannot be encrypted by the same 􏰏􏰑􏰂MUK. Although lightly obfuscated, the Secret Key is stored on the local device unencrypted. Where possible, the Secret Key will be put into something provided by your system for storing authentication secrets. For 1Password for Mac and 1Password for iOS that will use the iOS and OS X keychains respectively. But when 1Password has been used from a web browser, the Secret Key is stored in the browser’s local data store, a fairly exposed location.
    Recall that the Secret Key is designed so that an attacker will not be in a position to launch an offline password guessing attack if she captures data from the server alone. It does succeed at that goal, but in the current version, our ability to protect the Secret Key on your computer is limited by the tools available to that particular client.

  • Thank you for your answer.

    At least I‘m happy that I did not misunderstood anything or made a mistake on my side although it is not ideal that it seems to be a potential bug that prevents you from cleaning up private data from a browser (albeit it one in a „secure“ app) without giving you much indication that something is not happening as intended.

    Do I understand the explanation correctly that the secret key for unlocking the 1Password app in iOS is stored in the keychain but inside the 1Password Browser the secret key is stored relatively plainly in the browser data as well? Which I right now can‘t delete? I‘m just trying to estimate the risk to use the browser for potential „not-perfectly-save“ websites. In Safari for example I would use the private mode to prevent storing the key in the browser in the first place or clear the browser data after a login and before doing something else.

    I‘m very much looking forward to further information as feedback from the internal discussion (of cause without the details that you can‘t share in public) to keep the transparency about this issue and to give us an information when this issue will be resolved.

    Best regards

  • Hey @kslfngdlsr...

    Yes... your understanding of the Secret Key storage is correct. And you can only NOT delete it inside of the 1Password Browser, due to the bug you discovered. As you noted above, it does clear properly in other browsers.

    In Safari specifically, you can either use the browser's private mode or you can check the box on the sign-in page for "This is a public or shared computer". The first option will store the Secret Key in the browser's local storage until you close the browser window, relying on Safari to properly remove all stored data from the private session. The second option will simply not store it at all in the browser's local storage.

    With regards to the issue with 1Password Browser, bug issues have been created and the discussions about the solution are still ongoing. With the new autofill integration that came as a part of iOS 12, the need for 1Password Browser has been reduced significantly, as there is now a simple way to get your passwords from 1Password into a website in Safari. So we are still considering what the best steps are moving forward.

    Hope that helps!

  • Hey @brettbollman

    thank you very much for following up on that issue and providing an update.
    I‘m looking forward to your feedback once a solution has been found and decided upon.

    Best regards

  • My pleasure @kslfngdlsr.

This discussion has been closed.