Wednesday, July 22, 2009

Improving web browser security



Malware is the source of a large number of reported security incidents on the Internet. Since Internet users can become infected in many different ways, the proliferation of malware is a very hard problem to solve. One part of the solution is to improve the robustness of web browsers such that security compromises due to browser bugs are minimized. We work hard to scrutinize our own code for potential vulnerabilities. We also contribute to research in this area with projects like the Browser Security Handbook and open source releases of the fuzzers involved in our software testing.

Some of you may have noticed that while working on Google Chrome, we have also discovered and responsibly reported a number of security issues in other browsers. Various scenarios lead us to report these bugs:

  • Some browsers share code bases with Google Chrome, and we collaborate with those browser vendors.
  • We develop generic fuzzers that are applicable to most browsers and that we want to share with others.
  • We spend time analyzing behavior in different browsers, and we sometimes discover bugs in the process.
  • It benefits our users and the Internet as a whole if we work collaboratively on better web browser security.

A few of the more interesting bugs we've researched recently include: this one in Opera uncovered by Michal Zalewski's <canvas> fuzzer; a HTTP 449 response code issue in IE found by Tavis Ormandy; contributions to Safari 4's security by Robert Swiecki, SkyLined, and Dean McNamee (and others); an XMLHttpRequest leak in Firefox discovered by Marius Schilder; and a cross-domain leak in Chrome / Safari (the two share a common base) unearthed by Chris Evans.

The collaboration works both ways. We'd like to thank the following browser vendors:
Microsoft for helping with SSL interactions with HTTP proxies, Mozilla for sharing fuzzers, and Apple for sharing and coordinating Webkit-based bugs.

Together as a security community, our combined efforts to find vulnerabilities in browsers, practice responsible disclosure, and get problems fixed before criminals exploit them help make the Internet an overall safer place for everyone. We'd also like to thank all those who have helped us by contributing to Google Chrome.

Wednesday, July 15, 2009

Password strength and account recovery options



There's been some discussion today about the security of online accounts, so we wanted to share our perspective. These are topics that we take very seriously because we know how important they are to our users. We run our own business on Google Apps, and we're highly invested in providing a high level of security in our products. While we can't discuss individual user or customer cases, we thought we'd try to clear up any confusion by taking some time to explain how account recovery works with various types of Google accounts and by revisiting some tips on how users can help keep their account data secure.

One of the more common requests for assistance that we receive from regular Gmail users is to help them regain access to their accounts after they have misplaced or forgotten their password. We know that it can be frustrating when you can't access your account, and we've worked hard to come up with a system designed to help our users regain access to their accounts as smoothly as possible while taking appropriate precautions to protect their account security. When you select a password as you create an account, we recommend that you also choose a security question and provide a secondary email address. Recently, we also added a field where you can input a mobile phone number to assist with later account recovery. We regularly provide tips about how you can choose good passwords and security questions, and we also share our best ideas for what to do when you can't access your account. It's important to keep your password, security question, and secondary email address up to date. It's not enough to just tell us your email address to try to change your password. The security question helps us identify you, but if you want to initiate a password reset, we'll only send that information to the secondary address or the mobile phone number you provide.

We handle password recovery differently for our Google Apps customers. There is no password recovery process for individual Google Apps users. Instead, users must communicate directly with their domain administrator to initiate password changes on their individual accounts. Earlier this year we added new password security tools for Google Apps that allow administrators to set password length requirements and view password strength indicators to identify sufficiently long passwords that may still not be strong enough. For businesses that desire additional authentication security, since 2006 we have supported SAML Single Sign On, a protocol that allows organizations to use two factor authentication solutions such as certificates, smartcards, biometrics, one time password devices, and other stronger tokens.

If you're a regular Gmail user and you haven't updated your account information in a while, we recommend you do so by visiting your Google Account settings page now.