We have designed Mitro so your data remains secret as long as your password is secret. Anyone with access to our servers (either our staff or attackers) can only access encrypted data, and are forced to crack your password. However, we also want to make a product that non-experts can use, so we've had to make a few trade-offs between the ultra-secure paranoid solution and sharing passwords using email or shared documents, which is what most people do today. Here are the questions we typically get from security experts. Please email us at security@mitro.co (PGP key) if you have additional questions or comments.
Can crypto in the browser be trusted?
Cryptography in JavaScript on a web page can only be trusted if you trust the server, which kind of obviates the purpose of client-side crypto. For example, MegaPWN demonstrates how an attacker could get access to encryption keys if they added malicious JavaScript to MEGA's web site. In effect, any XSS attack could steal secrets by injecting JavaScript. This is why Mitro's user interface is implemented in a browser extension. Your passphrase is sent to a background page which performs all crypto operations, and has a limited interface so it never releases your private key. Background pages run in their own security context, so web pages cannot access them. Someone needs to do one of the following to get your key from your computer:
- Find an exploit in the browser's security model.
- Get access to our Chrome web store account and upload a malicious version of our extension.
- Run arbitrary code with access to your web browser.
None of these things is impossible, but they are more difficult than finding an XSS bug or getting access to our web server. We believe this is the protection you would get from installing a native password manager with automatic update and synchronizing its data using a cloud service like Dropbox or Google Drive.
Could a court order get access to my data?
If Mitro were served a legitimate court order, we would first verify that we are required to comply with multiple lawyers. If we were legally required to turn over data, the data that we can provide is encrypted, and government officials would be forced to crack your password. It is theoretically possible that we could be required to add a "backdoor" (e.g. Hushmail may have been required to do this in 2007). In this case, the extension auto-update mechanism could deliver this "malicious" code, the same way the iOS, Android, and Mac app stores can. You can protect against this by disabling automatic updates for the extension.
Why should I trust your implementation?
Our team has built security services before, at previous jobs. However, we will admit that we are not full-time security experts, and we know it is easy to get this stuff wrong. That is why we got multiple experts to review our design before we built it, and hired a third-party security firm to audit our implementation. We will share more details about our design in the future, but if you are interested, please contact us and we can share our detailed design document and a security report with you.
How can I trust that I am sharing passwords with the correct person?
When you share a password using Mitro, your client gets the public key associated with the destination email address from our server. The question is, does this public key belong to the person you intend, or it is an attacker's key? We verify that the user who generated the key has access to the email address they provided (they must click a link in an email with a randomly-generated nonce), so you have some assurance that you are getting better protection than emailing the password. However, there are two weaknesses. First, an attacker with access to our servers could replace friend@example.com's actual key with their own. Then, when you share a new secret or edit an existing shared secret, the attacker gets access. PGP solves this problem through a "web of trust", and SSL solves it using trusted certificate authorities. To mitigate this threat, a future version of Mitro will cache public keys that you've seen before, and warn you if they change (similar to SSH's host key change warnings). We are also adding an optional key verification step, so you can view and verify your friends' keys through another channel, like you would with PGP.
The second weakness is that when you invite a user who doesn't yet have an account, we generate a key for them, encrypt it with a random password, email them the password, then erase all traces of it from our server. Thus, there is a small time window where our servers have access to these new keys. To reduce the time where this key is valid, we will force invited users to generate a new key, and are planning on revising the UI to make it obvious when this will happen. In this case, you can choose to invite your friends to Mitro before you give them access to a secret.
Can someone with access to my device steal my passwords?
If you are logged in, a skilled attacker who can run code on your machine could steal the key from RAM, or possibly attack the crypto with side channel or timing attacks. However, they can also record keystrokes or network traffic, so they have easier ways to get your secrets. If you are not logged in and you don't check "remember me," your private key is never written to disk. An attacker can get your encrypted private key, but will then need to crack or steal your password. If you check "remember me", then an attacker can get your key and access your account. However, they will need to get the device decryption key from Mitro, which gives you a chance to revoke access by changing your password if a device is lost or stolen.
What cryptographic algorithms and parameters are you are using?
We use Google's Keyczar on the server, and our Keyczar JS implementation on the browser. We are using the defaults that Google's security team selected:
- Master key is a 128-bit AES key derived using PBKDF2 (SHA-1; 50000 iterations; 16 salt bytes)
- RSA with 2048-bit keys using OAEP-SHA1 (separate signing and encryption keys)
- AES with 128-bit keys in CBC mode with PKCS7 padding
- All encrypted data includes a MAC (HMAC-SHA1)
Why aren't you using 4096-bit keys, SHA-256, ECC, etc.?
Experts believe that 2048-bit RSA keys are strong enough for at least a decade (e.g. NIST SP 800-57 Part 1 Section 5.6 states that 2048-bit keys acceptable for government use until 2030). Keyczar provides the tools we need to change the algorithm and length in the future, if the need arises. We use RSA because Keyczar does, but also because we like using widely understood crypto code and algorithms.
Keyczar currently uses SHA-1, which is being phased out due to weaknesses (e.g. See NIST SP 800-107 Section 5.2). Work is underway to upgrade Keyczar to support SHA-2 (e.g. SHA256). As soon as that happens, we will use it.
I want to write my own client to store secrets in Mitro.
Hey - that isn't a question, but we love your enthusiasm. We're working on a public API and an open-source client library in C which you'll be able to inspect and use for your own applications. Due to Mitro's design, you don't need to trust our servers (only your client) in order to know that your secrets are safe. Some of our customers are using this for automated, machine-level password management. Contact us if you'd like more information.