When we launched RememBear to Beta, we were happy to receive a steady stream of great questions surrounding how we built our new password manager. Even though we spent a lot of time perfecting the Bear animations, we invested even more time thinking through RememBear’s security design.
In this post, we’d like to share some insight into the cryptography and security approaches we’ve used to secure your RememBear. In the weeks to come, we’ll be publishing a technical White Paper that will take a deep dive into the core functions and technologies we used.
Designing a new Bear
Our goal for RememBear is to provide a product that you can trust to secure all of your passwords. A pivotal design decision, that we made from the very beginning, was that you would be the only person with access to the contents of your RememBear account. To allow this, we decided to use end-to-end encryption, which grants you exclusive control over your account and leaves fewer ways for someone else to gain access to your passwords.
The challenge with building an end-to-end encrypted security product, is finding the balance between security and convenience. RememBear needs the ability to store the contents of your account securely, while allowing you to conveniently access your passwords on any device you authorize. That level of ease presented a challenge, since syncing the contents of your RememBear between your devices meant we needed to encrypt the data on your device then transfer it to be stored on our servers.
Designing a threat model that helped us identify possible attack vectors people could use to intercept or decrypt your RememBear data, has been the primary challenge of our security design. To defend against attacks, we incorporated proven encryption technologies into our architecture, then had our implementations of these tools publicly audited by Cure53, a well known security auditor. The result is a design for RememBear that maximizes security and convenience.
Why we chose end-to-end encryption
In order for RememBear to hold some of your most sensitive information, and be easily accessible on all of your devices, we need to store data on our servers (In the the future we plan to offer local storage options). To keep your data safe, we encrypt everything on your device so it’s protected in transit, on the internet and when it’s stored on our servers. Keeping information encrypted significantly reduces the risk of storing sensitive data on our servers.
In fact, the only time your information is ever decrypted is by you on your authenticated devices. If anyone maliciously accesses our servers or monitors your internet connection, all they will find is unreadable encrypted content.
Encrypting your passwords in RememBear
When you add new passwords to your account, RememBear encrypts the stored data using your Master Password, the password you enter each time you unlock your RememBear. Choosing a strong, unique Master Password to protect your RememBear is an important step to keeping your passwords safe. To reinforce this point, RememBear provides tips and an evaluation bar to show you just how secure your Master Password is while you setup your account.
Strong passwords are just the first step to keeping your account safe though, even the strongest passwords can leave hidden clues that make them easier to guess. In order to make sure your Master Password is as unique as possible, we provide you with a New Device Key (NDK). Your NDK is a series of characters that adds a measure of randomness to your Master Password, making it nearly impossible to brute force. For example, if your password is your birthday, there are only a few thousand combinations of characters to guess, while a uniformly random password (like your NDK) would offer millions of millions more combinations.
Along with making your Master Password harder to guess, your NDK provides a trusted way to add new devices to your account. Whenever you authorize a new device, we require you to enter your NDK and Master Password to authenticate the device.
|Possible Attack||Design Decision|
|Dictionary and brute force attacks against RememBear contents stored on our servers||Master Password, New Device Key and Key Management System|
|Offline attacks||Master Password|
Encrypting RememBear on your device
Your Master Password and NDK are the base layer of protection used to secure your RememBear, but we also need to think about what happens if someone gets a hold of your device. To protect your passwords, in the case that you lose your device or it gets stolen, we designed RememBear to store passwords in an encrypted form, and only decrypt passwords when they’re ready to be used.
When RememBear displays the items in your account, it’s only showing the most basic metadata about each item, like the name of the service or the email associated with it. You can see your logins in a list, but none of the important specifics, like passwords or notes attached to that item, have been decrypted. Tapping the login item decrypts the more sensitive content locally so you can see and use the password. When you’re done, RememBear deletes the sensitive data from memory.
In the event that someone gets a hold of your device, one possible way for an attacker to access your passwords is to connect your device to a second device then download everything stored in your device’s memory. By decrypting items only when you need them, then flushing the device’s memory when you’re done with the information, we’re able to minimize the amount of data that gets stored in memory.
|Possible Attack||Design Decision|
|Physical access to your device||Account related meta data items decrypted on an "as-needed" basis|
Secure servers for trusted sync
Creating an app that’s available on all of your devices is a key feature for making a password manager useful. Opening a new account for a service on your phone then having almost immediate access to that same account on your laptop means no more worrying about which logins are stored on which device.
In order to sync your RememBear, your device has to store a copy of your data on our server. Before your data is synced to the server, it’s already encrypted with your Master Password and New Device Key. However, we’ve also added additional measures to ensure that your RememBear is safe while it’s stored, as well as while it’s being transferred to our servers.
Secure Remote Password
To ensure that you’re the only one who can retrieve a copy of your data from the server with your Master Password, we use a form of Diffie-Hellman key exchange called Secure Remote Password. In short, SRP allows us to verify your password without our servers actually having to know what that password is. Instead, our server and your device agree on a series of cryptographic calculations (also called a shared secret) values to pass back and forth to prove you know your password without revealing the actual password to our server.
Using key exchange also helps defend against the chance that passwords could be collected if someone managed to get physical access to our servers. Since there are no Master Passwords being sent to the server for verification, there’s nothing to steal. Protecting your Master Password is important because it serves as more than just a login for your RememBear. Your Master Password is one of the keys to the cryptography protecting all of your other logins.
Most web services store a cryptographic hash of your login credentials. When you login, your password is sent over HTTPS. When it reaches the server you’re trying to log in to, that server verifies your password against the hashed version and if they’re a match, the service grants you access. If someone were to get access to our servers or staged a Man in the Middle attack, they could potentially grab all those passwords.
By using the SRP approach, even if someone were able to capture all of the information in the handshake, they wouldn’t be able to login to your account because the handshake doesn’t contain any login credentials.
KMS prevents offline attacks
While your NDK is the foundation for RememBear preventing offline attacks, Amazon Key Management Service (KMS) protect data stored on our server. KMS adds another layer of encryption to the encrypted data we store on our servers. The key to KMS encryption is stored in a secure hardware module that can only be used through an API call. In the event our server was compromised, KMS would need to be compromised as well in order to have a chance at an offline attack on your server-stored data.
Transport Layer Encryption
Not long ago, Cloudflare suffered a security breach, dubbed Cloudbleed, where some of their servers leaked plaintext information that should have been encrypted by HTTPS. Cloudbleed showed us HTTPS isn’t always enough which is why RememBear mitigates its reliance on HTTPS by using an extra layer of Transport Layer Encryption on top of HTTPS.
In the unlikely event that HTTPS breaks, the traffic between your RememBear client and server are still encrypted to prevent leaking plaintext data.
|Possible Attack||Design Decision|
|Compromised DB with sorted passwords||Key Management System and New Device Key||Man-in-the-Middle attack||Secure Remote Password|
|HTTPS failure||Transport Layer Encryption over HTTPS|
Building trust through transparency
Our 2017 TunnelBear security audit laid the groundwork for increased transparency regarding our security practices. Even though we have a team dedicated to securing TunnelBear, Cure53 still found a few issues in our first audit. In building RememBear, we decided that we needed to make security the focus from our initial design stages, before we even started to code.
For RememBear, we hired Cure53 once again to test our apps from initial architecture designs to our current Beta and we’re happy to share the results of this latest round of audits. We’re happy to announce:
- Cure53 found no critical issues with RememBear from as far back as our initial design drafts.
Cure53 were given white-box access to multiple RememBear builds, including the current Beta release, for testing. The few issues that were found were fixed prior to our Beta launch. Our team has a made a commitment that RememBear security will be independently audited and the report published annually.
RememBear your sensitive data
Designing RememBear as an implementation of end-to-end encryption, gave us the opportunity to consider all the threats a password manager could face while storing and syncing logins between a device and a server, which we secure but don’t trust. Hopefully this post answers some initial questions but for an in-depth look at our security implementations, our RememBear White Paper will be available soon.
For now, we want RememBear to be one of the first apps you put on a new device because it secures your sensitive information, while making daily tasks easier. We understand the trust it takes to put all your passwords into an app and we want to do everything we can to share the decisions that go into keeping your logins secure.
We encourage you to take RememBear for a spin on macOS, iOS, Windows and Android with extensions for Chrome, Firefox and Safari. We’re eager to hear your experiences and feedback, so please share any ideas with us by visiting remembear.com/support.
RememBearing you fondly,