We’re excited to announce that the Mitro team is joining Twitter’s location team in New York, focusing on a variety of geo-related projects! As we transition to Twitter, we want to provide you with some updates on our product.
Mitro is now open-source
As of today, we are releasing all of Mitro’s server and client code under the GPL license on Github. We’ve been working hard to build a secure, easy-to-use password manager for individuals and groups. We’ve made great progress and we believe that the community can help us accomplish even more. With that in mind, we’re excited to be receiving advice and assistance from the Electronic Frontier Foundation (EFF) in transitioning Mitro to a sustainable, community-run project (see the EFF’s announcement). The service will continue to operate as-is for the foreseeable future. To learn more and to see how you can help, please join the discussion on the mailing list.
We want to thank our users, institutional investors (especially Stan Reiss at Matrix and Rich Miner at Google Ventures), and angel investors for helping us build a product that is both secure and usable. We’d also like to thank Twitter for their support as we make this transition.
The Mitro Team
On April 7th, an extremely serious security flaw was found in OpenSSL, the library that is widely used to encrypt web traffic. Thankfully, Mitro encrypts all of your data in our browser extension, before it is sent to our web servers. While our web servers were vulnerable to this bug, any information that could have been obtained would have been encrypted. As a result: your data in Mitro was not at risk. However, as an additional layer of protection we updated our web servers immediately on April 7th, and are updating the SSL encryption key used to protect our web traffic. If you have any concerns, please contact us at firstname.lastname@example.org.
What happens when you make a Twitter account public, so anyone can use it to tweet, retweet, or follow others? To find out, we shared @notsecretapp using Mitro Access (you should try it). Its been available for a few hours, and already there have been some fun surprises. I like the self-tweet conversations:
NotSecretApp is powered by Mitro Access, a new way to give people access to accounts without software. In this case we made the account public, but Mitro Access is really useful to share accounts with specific people for a limited time. For example, you can order lunch as a team on Seamless, let someone submit their own complicated equipment order on Amazon, or let a contractor edit to your web site for a single day. It isn’t quite ready for the public yet, but if you want to try it with your own accounts, sign up for our beta release and we’ll let you know when you can try it.
I have a confession.
I admit it—I am a startup addict.
Whenever I see a shiny new product, I sign up and try it. I love seeing what other creative entrepreneurs are working on to make our lives more fun, fulfilling, and easy.
- You want to make planning my next Cards Against Humanities party easier?
I’ll try it.
- A collaborative inbox with my team?
Sign me up!
- Synergistic management solutions in the cloud?
Shut up and take my email!
This curiosity and willingness to try new things keeps the tech community strong, but also comes at a price: I fill in my personal information, only to lose track of what I’ve signed up for and never return. When the only trace of your membership is buried as an account verification link in your inbox, each startup discovery becomes a one-time disposable experience.
I know I’m not alone. At least 6,859 of you app explorers are out there—discovering new products, signing up, and never to return again.
In fact, if you’re reading this, chances are you’re one of us.
At Mitro, our mission is to make exploring, remembering, and sharing access to products as easy, enjoyable, and secure as possible. Today, we’re thrilled to announce a new way of discovering and accessing new services. We’re calling it Mitro Open Access.
Be one of the first to try Mitro Open Access
Here’s how it works:
- Get the Mitro browser extension so we can beam you access.
- We’ll send you an email of one hand-picked awesome new web app (no more than once per day).
- Interested? Click once on the email to launch right into the app—skipping the registration process (we’ll take care of that for you—behind the scenes). With the browser extension, you won’t lose track of the apps you have access to—and they’re all a keystroke away.
This is the future we believe in:
- What if tech founders impassionately pitching at a tech meetup could share access to their product with everyone in the audience? With one tap on a push notification, what if you could try the product and claim an account right at the moment you’re most captivated?
- What if keeping your finger on the pulse of the latest apps at festivals like SXSW was as easy as subscribing to your cool friend’s Spotify playlist? With Mitro, it could be possible in the future to not only have a list of all the startups you should explore, but be able try each one out with just one click.
- What if there was Highlight for sharing access? What if your friend’s WiFi password was automatically shared with you when you go to their house? What if you go to a conference and share/gain access with everyone you meet?
- What if you could see all the sites you’ve ever signed up for, ordered by what you use most? Would that be the tipping point to convincing you to pay for services you’re using most, and unsubscribing to those you now realize how rarely you touch?
- What if you could email all your beta mailing list subscribers their own personal link directly into your product the day it launches—instead of sending them a link to complete the registration process?
What do you think is the future of receiving and sharing access? Let us know in the comments or tweet us @MitroCo.
Do you have a product you’d like people to discover?
We’d love to #MitroOpenAccess your app (which requires no development work on your side). Please send us a link to the sign up page of your web product, and we’ll get in touch.
Two weeks ago, Naoki Hiroshima’s Twitter username (@N) was stolen. He was, of course, a particularly valuable target, but don’t think you’re immune just because you don’t have a rare twitter id! As more of our lives take place online, the value of our accounts, and the importance of securing them grows.
The details of the attack are as follows: The attacker alleges that using information provided by a PayPal phone support agent, he was able to convince GoDaddy to alter the password and email address on his account. He then intercepted emails sent to Naoki, using it to compromise other accounts. Successful attacks of this kind underscore that even if you follow best security practice and use strong, unique passwords for your accounts, your data is still at risk. So how can you protect your valuable data?
One common suggestion is to turn on two-factor authentication (TFA). TFA, while effective against certain attacks, provides very little protection against the kinds of “social engineering” that worked in this case. This works great until you drop your phone in a puddle. What do you do when you can no longer access the unique codes that TFA requires along with your password? Many services, including Gmail and Twitter, tackle this problem by allowing you to designate a phone number as a backup. If you break your phone, you can log in as soon as your replace it.
This approach means that the weak link in the system is now your phone provider, which isn’t great either. CloudFlare was breached because AT&T was tricked into giving an attacker access to their CEO’s voicemail. Alternatively, an attacker could usurp control of a target’s phone entirely; when I personally needed to get a replacement for my lost SIM card, a friendly T-Mobile customer service representative asked for my name, phone number, and payment, then proceeded to deactivate my old card, transferring my service, without ever asking for ID. Anyone who walked into the store could have easily pretended to be me, and walked out with my phone, and along with it, the ability to receive my TFA codes.
Unfortunately, aside from using strong passwords and enabling TFA, there isn’t much more that individual users can do to protect themselves. Application developers, however, have the power to make great strides in the fight against targeted attacks. Having a “paranoid mode,” which users can opt into is a step that increases security, but at the cost of substantially worsening the user experience. Credit bureaus already support freezing your credit report, which prevents anyone from opening accounts in your name or even seeing your credit history. This service is hard to enable but is mandated by various state laws since it helps to prevent identity theft in the physical world. A corollary could be built for online services: services could allow customers to opt in to a mode that makes it difficult, if not impossible, to recover a forgotten password or from a lost device.
Another possibility is to use real world social connections. Facebook requires you to identify pictures of your friends when you log in from an unknown device. This information is very difficult for an attacker to obtain, making the accounts far harder to steal. The one remaining downside is that some Facebook employees still have the authority to reset a user’s account (though it’s likely subject to many checks and balances).
At Mitro, a password manager for organizations, we’ve recently begun an alpha trial of something similar. Our system encrypts all data with a password (key) and doesn’t offer users a way of recovering their password if they forget it (any service provider that can recover users’ passwords has access to their data). For those who want some way to recover their account, we’re testing a scheme that will allow them to designate their friends as “recovery buddies.” Using secret sharing, we distribute pieces of the user’s key to all these friends (and we hold a piece ourselves). In order to restore access to his password, a customer would have to convince a number of his friends, along with us at Mitro that he was legitimately who he claimed to be, collect the pieces and recover his master password. This makes it incredibly difficult for an attacker; he would need to compromise our service, figure out who target’s friends might be, then individually compromise all of those users’ accounts.
While not perfect, this solution offers substantial benefits over the default service behaviour: employees have no way to unilaterally restore access to customers’ accounts, so social engineering attacks on the company won’t work; users still are provided a method to recover their data; responsibility for authenticating user requests is distributed across users’ friends; and the UX tradeoffs are much better.
Originally appeared as a guest post on Venture Beat on October 29, 2013.
We’ve used passwords since the beginning of computing. But back then you only had to remember one password—a single account let you access all the programs on one computer. You were unlikely to need to get into more than one of those giant machines! As the number of devices and applications we use has exploded, so has the number of passwords with which we have to deal.
Unfortunately, people are quite bad at managing passwords. Recent studies are full of frightening statistics. Over 60% use the same password on multiple sites — all these sites are then only as secure as the least secure site, a scary thought indeed. People also tend to select passwords that are easier to remember. While this avoids forgotten passwords, it makes them far too easy to guess.
So what gives? Why is this still such a mess?
For consumers, there’s at least been some slow progress. You can log into some services (e.g. Instagram, Quora, Spotify, etc.) using accounts from widely-used platforms such as Google, Facebook, or Twitter instead of creating a new account. But not everyone feels comfortable using platform accounts for fear of being locked out of their data if their platform account becomes inaccessible. Developers are sometimes reticent to agree to provider’s current and future terms of service.
Consumers’ password problems pale in comparison to the corporate world. Since employees have different roles and different data and software access privileges, companies need a way to export business identity — i.e., metadata about an employee and his rights — to cloud providers like Salesforce, Box, or GMail. But this usually requires Software as a Service (SaaS) developers and company administrators to configure and maintain a complex system to speak a special protocol (such as SAML). Consequently, most SaaS sites don’t interface with most business identity systems.
Additionally, business users in particular often share accounts on SaaS services: most services don’t natively support several people working on the same project or data (e.g., tax authority login, Twitter, many analytics products), and this use case is hugely prevalent in the corporate world. In fact, some 40% of business users share accounts, most often via email, spreadsheets or other insecure means.
Companies that try to prevent users from using non-sanctioned services (such as Google Docs, Dropbox, online analytics tools, etc.) for fear of data leakage often end up worsening their situation: in a recent survey, 70% of employees admitted to subverting such policies. Now, not only are the company’s data on third-party sites, IT staff is totally unaware, and have no way of accessing or controlling access to these data.
For large organizations with high employee turnover, the process of creating and deleting new accounts can be quite daunting. Forgetting to terminate users’ accounts means they can continue to access privileged information after they leave. There are some solutions for this in the market now: Okta is geared towards automating the account creation/deletion process for commonly-used SaaS sites, while providing better controls. But it isn’t optimized for the “long tail” of services which are so commonly used and shared in the workplace.
Can biometrics be a panacea? Unfortunately not. Passwords are supposed to be secrets, but biometrics are the exact opposite of a secret—you take them and leave copies everywhere you go. Using the same biometric data to authenticate to multiple applications is really no different from using the same password on multiple sites. (Bruce Schneier has a good summary of biometrics here.)
Developers should do a better job of storing passwords. Passwords should not be stored in plaintext (because anyone with access to the database will immediately know all the passwords). Proper practices require hashing and salting passwords. This is a daunting challenge. Even well-established sites often don’t follow best practices: 6.5 million poorly-hashed LinkedIn passwords were recently leaked. Others store passwords in plain text—Troy Hunt has put together a list of the most egregious violators here.
Using the power of modern processors, passwords are surprisingly easy to crack. Based on recent research, a random lower-case 8-character MD5-hashed password would cost only about $190 to crack on AWS (assuming $2.1/hour/machine and ~2B MD5 hashes/sec). Cracking a similar password stored with a stronger hash (e.g., PBKDF2) would cost around $2M.
One of the simplest ways of securing systems is the use of multi-factor authentication (MFA). MFA requires the use of a separate number generated by a program or device, or sent to you via SMS, in addition to a password when logging in to services, or performing certain actions. A good example of this is Google’s Two-Step Authentication. This means that having a user’s password is insufficient to impersonate him.
Unfortunately, it’s unlikely that most services will adopt oAuth, OpenID, SAML, or similar interfaces, store passwords correctly, or support multi-user collaboration in the near future due to the difficulty of implementation and limited payoff. Instead, we should try to build a better framework for managing business identity — starting by better managing passwords. We need a system that gets universal buy-in from the multitude of players in the space by providing a tangible benefit to each: developers, users, IT administrators, security officers, and regulators. It must be easier for customers to use than email, post-it notes, and spreadsheets.
It should enforce using unique passwords on different sites, give administrators more visibility and control over processes, provide strict security guarantees, and provide thorough auditing capabilities. Cryptography needs to be done on the client side so that the service provider does not need to be trusted. Widespread use of such a system will afford a number of other advances including pro-active fraud and suspicious activity detection. Products that address some of these problems exist today (LastPass, 1Password, etc.), but nothing has come close to solving all them.
As we’ve seen, the password problem is pervasive, serious, and unlikely to get better on its own. What’s needed is software that addresses the challenges listed above, and a shift in both user and developer mindset to take security more seriously. Ideally, the software is designed in a way to galvanize that shift. We’ve recently released a tool for organizations and individuals that starts down that path, but there’s a lot more work to be done. We’d welcome your input and support!
Mitro for Android is now available, allowing you to log in to all your accounts while you are on the go. We decided to release this as early as we could because mobile apps are by far our number one feature request since our article in TechCrunch. Maybe this means we are Luddites because we knew mobile was important, but we underestimated how important. iOS is up next. It was our top request, but we already had the Android app mostly finished thanks to Peter Jasko, who wrote most of it during his internship with us this summer.
Mitro for Android lets you view and copy passwords, but doesn’t yet let you edit or share them with others. You’ll have to use Mitro on your desktop to create your account and to manage access.
We’ve been busy fixing bugs and making behind the scenes improvements based on user feedback. We’ll have some exciting new features to show you in the next few weeks.
The long story: Using encryption correctly is not easy. If you configure things incorrectly, it may be completely useless (e.g. XML encryption can be bypassed using a padding oracle attack because they made the MAC optional). As a result, when we designed our secure password manager for groups and enterprises, we wanted a library designed by experts to make it harder for us to screw up. In the end, there are two worth considering: NaCl by Daniel J. Bernstein (aka DJB), or Keyczar by Google. We chose Keyczar for three reasons: First, Google uses it (in the Google Play Store Android app amongst other areas). Second, other people we trust recommend it. Finally, it uses algorithms that have been standardized by NIST and are widely used (AES, RSA, HMAC). While this does not mean that they are more secure than DJB’s algorithms used by NaCl (Curve25519, Salsa20, Poly1305), they are far more widely understood and studied.
- Forge didn’t support RSA-OAEP, the encryption mode used by Keyczar, so we implemented it (we would love experts to review the implementation).
- Password-protected keys are supported by the C++ implementation, but not others, and the key format was not well documented. We had to reverse-engineer it by reading the source code. We have implemented support in JS and Java, and are working on getting these changes upstream.
In the process of building our startup (we provide simple account management and sharing for teams), I’ve had to attend lots of meetings. We met people for fundraising, prospective candidates (we’re hiring engineers and business people—email us at at email@example.com if you’re interested), and customers all over the place. Throughout the process Google Calendar (and Google Now) has been invaluable in keeping me organized.
The one glaring flaw with Calendar is the fact that adding locations to events is not easy. I usually have to look up a location on Google Maps, Foursquare, or Yelp and then copy and paste the location into the Where box. I decided to solve this by writing a chrome extension to automatically fill in this form. It’s been super useful to us and some friends who’ve been trying out, so we decided to make this the first contribution to our Mitro.co’s labs page!
Caveat: Editing old events doesn’t work quite right
First off, (for complicated reasons we’ll get into later), the Extension doesn’t work properly if you try to edit old events. If you edit an old event, you will need to change another field in addition to editing the location (or do something like add a space to the location that gets filled in) otherwise your modification won’t be saved to Google Calendar. I’ll try to make this better in future releases.
This extension is powered by Foursquare’s cool Venue Search API. I wrote a server that (currently) runs on Google App Engine to proxy and cache these requests to reduce the number of queries that are sent to Foursquare.
The Chrome extension operates by finding the location of the Where box, and using JQueryUI’s autocomplete tool to handle the autocompletions. Doing this is actually substantially more difficult than it should be: it appears as if Google’s Closure library is caching the content of the forms, and only reads the data from an input element if the user has somehow interacted with it. So, simply changing the contents of the text box (as the autocomplete plugin does) is insufficient; subsequent requests to Google treat the field as if it had never changed. I tried sending various combinations of keyup, keydown, keypress, and textinput events to the textbox, but for some reason, it doesn’t trigger Google Calendar to refresh its data from the textbox.
I recruited the help of Julie Parent, a friend of mine who works on Chrome, and despite working on it for a while, we haven’t been able to figure out why those efforts failed. Our (her) best guess is that this might be related to this WebKit bug, but that remains to be seen.
At any rate, I was able to work around this by overriding XMLHttpRequest(XHR) and rewriting the post data to match the autocompleted location. The one problem (mentioned earlier) is that when editing an event, if the only modification is a new location created by this extension (and not human input) Google doesn’t think anything at all has changed, and doesn’t issue an XHR at all, rendering our hack useless. To get around this, changing anything (e.g. adding a space in the where box) or adding something in the memo, will allow everything to work.
The location autocomplete code is available on github. Check it out! We’d really appreciate any comments/suggestions/patches you might be willing to send our way.
And of course, if working with us sounds like fun, don’t hesitate to reach out: firstname.lastname@example.org!