Various RememBear security issues

Whenever I write about security issues in some password manager, people will ask what I’m thinking about their tool of choice. And occasionally I’ll take a closer look at the tool, which is what I did with the RememBear password manager in April. Technically, it is very similar to its competitor 1Password, to the point that the developers are being accused of plagiarism. Security-wise the tool doesn’t appear to be as advanced however, and I quickly found six issues (severity varies) which have all been fixed since. I also couldn’t fail noticing a bogus security mechanism, something that I already wrote about.

Stealing login tokens

Password managers will often give special powers to “their” website. This is generally an issue, because compromising this website (e.g. via an all too common XSS vulnerability) will give attackers access to this functionality. In case of RememBear, things turned out to be easier however. The following function was responsible for recognizing privileged websites:

isRememBearWebsite() {
    let remembearSites = this.getRememBearWebsites();
    let url = window.getOriginUrl();
    let foundSite = remembearSites.firstOrDefault(allowed => url.indexOf(allowed) === 0, undefined);
    if (foundSite) {
        return true;
    return false;

We’ll get back to window.getOriginUrl() later, it not actually producing the expected result. But the important detail here: the resulting URL is being compared against some whitelisted origins by checking whether it starts with an origin like No, I didn’t forget the slash at the end here, there really is none. So this code will accept as a trusted website!

Luckily, the consequences aren’t as severe as with similar LastPass issues for example. This would only give attacker’s website access to the RememBear login token. That token will automatically log you into the user’s RememBear account, which cannot be used to access passwords data however. It will “merely” allow the attacker to manage user’s subscription, with the most drastic available action being deleting the account along with all passwords data.

Messing with AutoFill functionality

AutoFill functionality of password managers is another typical area where security issues are found. RememBear requires a user action to activate AutoFill which is an important preventive measure. Also, AutoFill user interface will be displayed by the native RememBear application, so websites won’t have any way of messing with it. I found multiple other aspects of this functionality to be exploitable however.

Most importantly, RememBear would not verify that it filled in credentials on the right website (a recent regression according to the developers). Given that considerable time can pass between the user clicking the bear icon to display AutoFill user interface and the user actually selecting a password to be filled in, one cannot really expect that the browser tab is still displaying the same website. RememBear will happily continue filling in the password however, not recognizing that it doesn’t belong to the current website.

Worse yet, RememBear will try to fill out passwords in all frames of a tab. So if embeds a frame from and the user triggers AutoFill on the latter, will potentially receive the password as well (e.g. via a hidden form). Or even less obvious: if you go to and that site has third-party frames e.g. for advertising, these frames will be able to intercept any of your filled in passwords.

Public Suffix List implementation issues

One point on my list of common AutoFill issues is: Domain name is not “the last two parts of a host name.” On the first glance, RememBear appears to have this done correctly by using Mozilla’s Public Suffix List. So it knows in particular that the relevant part of is and not On a closer glance, there are considerable issues in the C# based implementation however.

For example, there is some rather bogus logic in the CheckPublicTLDs() function and I’m not even sure what this code is trying to accomplish. You will only get into this function for multi-part public suffixes where one of the parts has more than 3 characters – meaning for example. The code will correctly recognize as being the relevant part of the host name, but it will come to the same conclusion for as well. Since domains are being registered under the namespace, the two host names here actually belong to unrelated domains, so the bug here allows one of them to steal credentials for the other.

The other issue is that the syntax of the Public Suffix List is processed incorrectly. This results for example in the algorithm assuming that and belong to the same domain, so that credentials will be shared between the two. With being the public suffix here, these host names are unrelated however.

Issues saving passwords

When you enter a password on some site, RememBear will offer you to save it – fairly common functionality. However, this will fail spectacularly under some circumstances, and that’s partially due to the already mentioned window.getOriginUrl() function which is implemented as follows:

if (window.location.ancestorOrigins != undefined
    && window.location.ancestorOrigins.length > 0) {
    return window.location.ancestorOrigins[0];
else {
    return window.location.href;

Don’t know what window.location.ancestorOrigins does? I didn’t know either, it being a barely documented Chrome/Safari feature which undermines referrer policy protection. It contains the list of origins for parent frames, so this function will return the origin of the parent frame if there is any – the URL of the current document is completely ignored.

While AutoFill doesn’t use window.getOriginUrl(), saving passwords does. So if in Chrome embeds a frame from and the user logs into the latter, RememBear will offer to save the password. But instead of saving that password for it will store it for And will be able to retrieve the password later if the user triggers AutoFill functionality on their site. But at least there will be some warning flags for the user along the way…

There was one more issue: the function hostFromString() used to extract host name from URL when saving passwords was using a custom URL parser. It wouldn’t know how to deal with “unusual” URL schemes, so for data:text/html,foo/ or about:blank#:// it would return as the host name. Luckily for RememBear, its content scripts wouldn’t run on any of these URLs, at least in Chrome. In their old (and already phased out) Safari extension this likely was an issue and would have allowed websites to save passwords under an arbitrary website name.


  • 2019-04-09: After discovering the first security vulnerability I am attempting to find a security contact. There is none, so I ask on Twitter. I get a response on the same day, suggesting to invite me to a private bug bounty program. This route fails (I’ve been invited to that program previously and rejected), so we settle on using the support contact as fallback.
  • 2019-04-10: Reported issue: “RememBear extensions leak token.”
  • 2019-04-10: RememBear fixes “RememBear extensions leak token” issue and updates their Firefox and Chrome extensions.
  • 2019-04-11: Reported issue “No protection against logins being filled in on wrong websites.”
  • 2019-04-12: Reported issues: “Unrelated websites can share logins”, “Wrong interpretation of Mozilla’s Public Suffix list”, “Login saved for wrong site (frames in Chrome)”, “Websites can save logins for arbitrary site (Safari).”
  • 2019-04-23: RememBear fixes parts of the “No protection against logins being filled in on wrong websites” issue in the Chrome extension.
  • 2019-04-24: RememBear confirms that “Websites can save logins for arbitrary site (Safari)” issue doesn’t affect any current products but they intend to remove hostFromString() function regardless.
  • 2019-05-27: RememBear reports having fixed all outstanding issues in the Windows application and Chrome extension. macOS application is supposed to follow a week later.
  • 2019-06-12: RememBear updates Firefox extension as well.
  • 2019-07-08: Coordinated disclosure.


  • Jamie Katz

    Thanks so much for these. Can you look into and give us your opinions about FireFox Lockwise? And on self-hosting Lockwise? Are they on the right track?

    Wladimir Palant

    Last time I looked into Lockwise, it was depending on Firefox Accounts for generating crypto tokens. And Firefox Accounts are still in that sad state with only 1000 PBKDF2 iterations applies on the client side:

  • Anestis

    Hi Wladimir,

    You have a great blog! I'm a long time user of LastPass and wanted to switch to a different manager that's app based as I switch from browser way too often and wanted a solution that was centrally managed from an app. I.e. you login to the app and you're logged in to all the different browser extensions regardless of the browser window.

    I did extensive research and did like Remembear the most but I also wanted to make sure their security was good too. I ended up here after googling for Remembear security and couldn't find much else.

    While I'm glad all the issues that you reported were fixed I was disappointed that a) there was no security contact easily available and b) all the issues that you reported seemed pretty much as growing pains for a pwd manager that might not be ready for prime time. What were your thoughts in general from their response?

    Also, do you have any comments on their security model?

    Thanks Anestis

    Wladimir Palant

    Their general approach is almost identical to 1Password, to the point that some people say they copied it. As to the implementation, you can probably see from this article that I wasn’t too impressed. They fixed the issues quickly and in a professional way, but I have no idea whether they are more thorough now.