Securing the RememBear Browser Extensions
Share this post

Securing the RememBear Browser Extensions

Editor’s note: This blog post requires some base level understanding of cryptography and networking protocols. We’d like to share the details behind the decisions that secure the contents of your RememBear, but some of them are fairly technical. Links to outside resources have been provided where we felt further explanation might be necessary.

As we started building our RememBear extension, our biggest challenge was figuring out how to securely get your passwords from the app to the password form and vice-versa. The baked-in security measures in modern browsers prevent communication between tabs or apps that are outside of the browser, so we had to answer two questions. First, how do you pass information back and forth between two apps that can’t communicate? Second, how do you do it securely?

The options are fairly limited, but we had two realistic solutions, Native Messaging or Websockets.

Native Messaging

Native Messaging is a way for native applications to communicate with browser extensions on Google Chrome and now Firefox. Safari has its own version of this integrated within “App Extensions”. When we started work on RememBear, Google Chrome was the focus of our attention, but we wanted to support multiple browsers/platforms right off the bat.

One of the disadvantages of Native Messaging implementations is their lack of security integration and documentation around the security model. A malicious application can fool your browser into thinking it’s communicating with your favourite bear-themed password manager, instead of the malicious process it actually belongs to. If we went down the Native Messaging route, we knew we’d have to build a pairing/encryption layer over top of it.

WebSockets

WebSockets were our second option and allow full-duplex communication between clients and servers so they can share information faster. If a client knows something the server doesn’t, like initiating a file save to the cloud, the client can upload the file to the server. If the server knows something the client doesn’t, like when a new email is available, the server can push the email to the client and notify the client in real-time.

we felt WebSockets provided the best solution to. . .work across different platforms and browsers.

While websockets are usually used to send real-time data between a client and server more efficiently, for RememBear, we felt WebSockets provided the best solution to allow the native app to talk to our browser extensions and have one solution work across different platforms and browsers.

Securing the browser communication

After we figured out a way to communicate from the browser extension to the apps, we asked ourselves, “How do we securely communicate?” We felt that we couldn't start building anything until we were able to answer three key questions with confidence:

  1. How can we prevent someone from listening in on the conversation between the browser and the RememBear app?
  2. How does the Browser know it’s talking to the real RememBear app and not a malicious one?
  3. How does the RememBear app know it’s not talking to a malicious browser trying to steal all your passwords?

Encrypting our Websocket connections

WebSockets can provide a layer of encryption that covers all communication being sent through the socket called WebSocket Secure. Using WSS solved our first concern, it would prevent someone from listening in on the conversation between the browser and the RememBear app. However, in order to use WSS without your browser complaining, you need to get your certificates digitally signed by a trusted Certificate Authority.

To complicate things further, we needed to generate a pair of keys and certificates for each browser and device. Getting that many keys digitally signed by a CA isn’t feasible, and still doesn’t solve the problem of verifying the app and the browser (questions 2 and 3).

Since we technically can’t use WSS with self-signed, generated certificates, RememBear creates its own TLS layer on top of a normal WebSocket connection. The end result is very similar to using WSS.

Pairing the browser extension with the native app

To function properly, the native app needs to verify that it’s communicating with the expected browser, and not a malicious process pretending to be the browser. To confirm the identity of the connecting process, RememBear checks the code signature and the publisher of the connecting process. However, we found these checks were brittle and couldn’t provide the security guarantees we wanted against a determined attacker.

We also found an issue with auto-update in some browsers. When the browser does an automatic update, the modified executable’s code signature can’t be verified until the browser is restarted. When we realized our initial checks weren’t able to give us the level of security we required, we decided to come up with a pairing mechanism.

The difficulty with pairing mechanisms (e.g. Bluetooth) is that you need a method of communication outside of the connection you’re trying to secure, better known as Out of band communication. We use the RememBear servers to make our Out of Band connection, since the native app is already authenticated with our servers, and our servers are authenticated with the browser extension using the standard https mechanisms.

We use the RememBear servers to make our Out of Band connection

Finally, a visual check is used to close the pairing loop. RememBear uses a two-step authentication system, where the person using the app verifies that both the browser and native app pairing codes match. This way, we prevent someone else from pretending to be RememBear when a normal pairing process is initiated.

Authentication process

To sum up, in order for RememBear to authenticate the connection with your browser, it has to run through a few steps. Brace for it, the process looks like this:

  1. RememBear receives a handshake request from the browser
  2. RememBear asks the browser for its security certificate along with the request
  3. Through the handshake, your browser and RememBear receive both certificates
  4. RememBear and the browser independently calculate a security token
  5. The calculated result is displayed to the account holder
  6. RememBear uses account master password to verify identity
  7. RememBear sends the authenticated request to our servers
  8. Servers accept the authentication and allow the browser connection
  9. RememBear saves the browser's verified certificate locally
  10. Browser checks the server to see if original request was accepted
  11. Browser asks for new connection to RememBear
  12. RememBear trusts the browser's certificate
  13. RememBear accepts the new request
  14. Encrypted TLS connection is created between RememBear and browser
  15. RememBear noms all your yummy logins

Secure by design

Minimizing RememBear’s attack surface is incredibly important. We felt that securing your passwords outside the browser, rather than storing them in the browser extension, was one of the best ways to protect your passwords. Using our approach, we’re able to protect against common DOM based attack vectors and phishing attacks. Building a native app also allowed us to work with existing, well known and trusted encryption tools. By adding an extra layer of encryption during information transfer, RememBear keeps your passwords safe and secure outside of your browser when they aren’t being used.

Minimizing RememBear’s attack surface is incredibly important.

In the coming months, we’ll have more articles explaining some of the key features of RememBear and the security decisions we made along the way, as well as a whitepaper that will go into much greater detail about how we built RememBear. In the meantime, if you have any questions you can always reach us at RememBear.com/support.

Scientifically rawrs,
Dane C. - Camp Bear