Mitro is joining Twitter and is now open source
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
Mission impossible: protecting against social engineering
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.
Your password management strategy stinks: Here’s why
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.
Possible Solutions
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.
Wrapping up
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!
Location autocomplete for Google Calendar™
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 jobs@lectorius.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.
Details
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: jobs@lectorius.com!
Vijay Pandurangan
Follow @vijayp
