Advanced sign-in security for your Google account

(Cross-posted on the Gmail Blog)

Has anyone you know ever lost control of an email account and inadvertently sent spam—or worse—to their friends and family? There are plenty of examples (like the classic "Mugged in London" scam) that demonstrate why it's important to take steps to help secure your activities online. Your Gmail account, your photos, your private documents—if you reuse the same password on multiple sites and one of those sites gets hacked, or your password is conned out of you directly through a phishing scam, it can be used to access some of your most closely-held information.

Most of us are used to entrusting our information to a password, but we know that some of you are looking for something stronger. As we announced to our Google Apps customers a few months ago, we've developed an advanced opt-in security feature called 2-step verification that makes your Google Account significantly more secure by helping to verify that you're the real owner of your account. Now it's time to offer the same advanced protection to all of our users.

2-step verification requires two independent factors for authentication, much like you might see on your banking website: your password, plus a code obtained using your phone. Over the next few days, you'll see a new link on your Account Settings page that looks like this:

Take your time to carefully set up 2-step verification—we expect it may take up to 15 minutes to enroll. A user-friendly set-up wizard will guide you through the process, including setting up a backup phone and creating backup codes in case you lose access to your primary phone. Once you enable 2-step verification, you'll see an extra page that prompts you for a code when you sign in to your account. After entering your password, Google will call you with the code, send you an SMS message or give you the choice to generate the code for yourself using a mobile application on your Android, BlackBerry or iPhone device. The choice is up to you. When you enter this code after correctly submitting your password we'll have a pretty good idea that the person signing in is actually you.

It's an extra step, but it's one that significantly improves the security of your Google Account because it requires the powerful combination of both something you know—your username and password—and something that only you should have—your phone. A hacker would need access to both of these factors to gain access to your account. If you like, you can always choose a "Remember verification for this computer for 30 days" option, and you won't need to re-enter a code for another 30 days. You can also set up one-time application-specific passwords to sign in to your account from non-browser based applications that are designed to only ask for a password, and cannot prompt for the code.

To learn more about 2-step verification and get started, visit our Help Center. And for more about staying safe online, see our ongoing security blog series or visit http://www.staysafeonline.org/. Be safe!

Posted by Nishit Shah, Product Manager, Google Security

National Cyber Security Awareness Month 2010: Stop. Think. Connect.

Governments, industry and everyday people have been abuzz this year about online security to a larger extent than ever before. People are talking about their information, how they share it with others and how they secure it. With more information moving online, and with cyber attacks on the rise, we think it’s important that we keep the conversation about security flowing.

Google has renewed its commitment to security this year and has pushed industry boundaries to help people better protect their information in new ways. Here are just a few examples: We became the first major email provider to offer default HTTPS encryption for the entire email session, and we introduced an encrypted search option for Google.com. We designed a new system to make Google Accounts more secure, and added suspicious activity detection for our users. Google Apps became the first suite of cloud computing applications to receive Federal Information Security Management Act (FISMA) certification from the U.S. government. We also published new security products, tools and research to help web developers and network administrators make the rest of the web more secure.


I sit on the board of the National Cyber Security Alliance (NCSA) to promote work that encourages safer online habits. Together with that organization, the U.S. Department of Homeland Security (DHS) and a host of other companies, Google is taking the month of October to recognize National Cyber Security Awareness Month. As we did in a blog post series last year, we’ll explore simple ways that people can make use of Google’s technologies and tools, as well other freely available resources and advice, to better protect themselves and their information.

We will post links here throughout the month, so be sure to check back often:

Tips and Tricks: Sharing Google Docs Like a Pro
Protect your data in the cloud
This Internet is Your Internet: Digital Citizenship from California to Washtenaw County

Understanding the omnibox for better security (Google Chrome Blog)

Safe browsing on Blogger

Stop. Think. Connect. To protect yourself from fake Checkout invoices.

Tips for a more secure orkut experience

Remember these tips for safer shopping

Remember, even with so many people and groups focused on creating a safer web experience for everyone, we all have a responsibility to take steps to protect ourselves online. The NCSA recommends that we keep our wits about us and think carefully about our online actions before we take them. In that spirit, we encourage you to: Stop. Think. Connect.


Posted by Eric Davis, Public Policy Manager, Security

Three million businesses have gone Google: celebrating growth, innovation and security

Today we’re hosting more than 300 CIOs and IT professionals from around the world in Paris at Google Atmosphere, our annual European event dedicated to cloud computing—web-based applications that are built on shared infrastructure and delivered through the browser. This year, the discussion at Atmosphere is focused on how companies can benefit from the breakthroughs in productivity and security that cloud-based applications are uniquely capable of delivering.

This event also marks some major milestones:

• As of today, more than 3 million businesses have gone Google, and over 30 million users within businesses, schools and organizations now depend on our messaging and collaboration tools.
• We’re launching new cloud-powered capabilities: two-step verification to help enhance security and soon, mobile editing in Google Docs on Android and the iPad™.

First, Google Apps Premier, Education and Government Edition administrators can now have users sign in with the combination of their password (something they know) and a one-time verification code provided by a mobile phone (something they have). Users can continue to access Google Apps from Internet-connected devices, but with stronger protections to help fend off risks like phishing scams and password reuse. For the first time, we’re making this technology accessible to organizations large and small without the costs and complexities that have historically limited two-step verification to large enterprises with deep pockets. Furthermore, in the coming months, Standard Edition and hundreds of millions of individual Google users will be able to enjoy this feature as well.


Second, today we demonstrated new mobile editing capabilities for Google Docs on the Android platform and the iPad. In the next few weeks, co-workers around the world will soon be able to co-edit files simultaneously from an even wider array of devices.

Only cloud computing is able to deliver the whole package of productivity-enhancing collaboration, superior reliability and virtually unlimited scale at a price that’s affordable for any size organization. Our Atmosphere event is a nice opportunity to step back and fully appreciate the power of the cloud with customers and future customers alike.

Posted by Dave Girouard, President, Google Enterprise

Simpler sign-ups for Yahoo! users with OpenID

How many times have you created a new account at a website and seen a message that said: “Thank you for creating an account. To activate your new account, please access your email and click the verification URL provided.”

Even though you just want to start using the website, this lengthy process requires you to manually perform a whole bunch of steps—including switching to your mailbox, trying to find the message the website sent you (which might be in your Spam folder), opening the message, clicking the link, etc. Until recently, we also required people to follow these steps if they wanted to sign up for a Google Account using their existing email address, such as a @yahoo.com, @hotmail.com, or other address.

To make this process simpler, we’re now using an Internet standard called OpenID which is supported by several email providers, including Yahoo!. Instead of the process above, Yahoo! users who sign up with Google see the page below with a button that sends them to Yahoo! for verification.

Once you click that button, Yahoo! shows you a page to get your consent to share your email address with Google.

After you agree, you’re done and can start using any Google service, such as Google Groups, Docs, Reader, AdWords, etc. We have found that a much larger number of people complete the email verification process when this method is used.

In the future we hope to expand this feature to other email providers, and we also hope other website operators will read more on the Google Code Blog about how they can implement a similar feature.

Posted by Eric Sachs, Senior Product Manager, Google Security

Search more securely with encrypted Google web search

Update June 25, 2010: Since we introduced our encrypted search option last month, we’ve been listening closely to user feedback. Many users appreciate the capability to perform searches with better protection against snooping from third parties. We’ve also heard about some challenges faced by various school districts, and today, we want to inform you that we’ve moved encrypted search from https://www.google.com to https://encrypted.google.com. The site functions in the same way. For more information on this change, please read on here.

As people spend more time on the Internet, they want greater control over who has access to their online communications. Many Internet services use what are known as Secure Sockets Layer (SSL) connections to encrypt information that travels between your computer and their service. Usually recognized by a web address starting with “https” or a browser lock icon, this technology is regularly used by online banking sites and e-commerce websites. Other sites may also implement SSL in a more limited fashion, for example, to help protect your passwords when you enter your login information.

Years ago Google added SSL encryption to products ranging from Gmail to Google Docs and others, and we continue to enable encryption on more services. Like banking and e-commerce sites, Google’s encryption extends beyond login passwords to the entire service. This session-wide encryption is a significant privacy advantage over systems that only encrypt login pages and credit card information. Early this year, we took an important step forward by making SSL the default setting for all Gmail users. And today we’re gradually rolling out a new choice to search more securely at https://www.google.com.

When you search on https://www.google.com, an encrypted connection is created between your browser and Google. This secured channel helps protect your search terms and your search results pages from being intercepted by a third party on your network. The service includes a modified logo to help indicate that you’re searching using SSL and that you may encounter a somewhat different Google search experience, but as always, remember to check the start of the address bar for “https” and your browser lock indicators:

Today’s release comes with a “beta” label for a few reasons. First, it currently covers only the core Google web search product. To help avoid misunderstanding, when you search using SSL, you won’t see links to offerings like Image Search and Maps that, for the most part, don’t support SSL at this time. Also, since SSL connections require additional time to set up the encryption between your browser and the remote web server, your experience with search over SSL might be slightly slower than your regular Google search experience. What won’t change is that you will still get the same great search results.

A few notes to remember: Google will still maintain search data to improve your search quality and to provide better service. Searching over SSL doesn’t reduce the data sent to Google — it only hides that data from third parties who seek it. And clicking on any of the web results, including Google universal search results for unsupported services like Google Images, could take you out of SSL mode. Our hope is that more websites and services will add support for SSL to help create a better and more consistent experience for you.

We think users will appreciate this new option for searching. It’s a helpful addition to users’ online privacy and security, and we’ll continue to add encryption support for more search offerings. To learn more about using the feature, refer to our help article on search over SSL.

Posted by Evan Roseman, Software Engineer

WiFi data collection: An update

Update June 9, 2010: 

When we announced three weeks ago that we had mistakenly included code in our software that collected samples of payload data from WiFi networks, we said we would ask a third party to review the software at issue, how it worked, and what data it gathered. That report, by the security consulting firm Stroz Friedberg, is now complete and was sent to the interested data protection authorities today. In short, it confirms that Google did indeed collect and store payload data from unencrypted WiFi networks, but not from networks that were encrypted. You can read the report here. We are continuing to work with the relevant authorities to respond to their questions and concerns.

Update May 17, 2010:

On Friday May 14 the Irish Data Protection Authority asked us to delete the payload data we collected in error in Ireland. We can confirm that all data identified as being from Ireland was deleted over the weekend in the presence of an independent third party. We are reaching out to Data Protection Authorities in the other relevant countries about how to dispose of the remaining data as quickly as possible.


You can read the letter from the independent third party, confirming deletion, here.


[original post]
Nine days ago the data protection authority (DPA) in Hamburg, Germany asked to audit the WiFi data that our Street View cars collect for use in location-based products like Google Maps for mobile, which enables people to find local restaurants or get directions. His request prompted us to re-examine everything we have been collecting, and during our review we discovered that a statement made in a blog post on April 27 was incorrect.

In that blog post, and in a technical note sent to data protection authorities the same day, we said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data from open (i.e. non-password-protected) WiFi networks, even though we never used that data in any Google products.

However, we will typically have collected only fragments of payload data because: our cars are on the move; someone would need to be using the network as a car passed by; and our in-car WiFi equipment automatically changes channels roughly five times a second. In addition, we did not collect information traveling over secure, password-protected WiFi networks.

So how did this happen? Quite simply, it was a mistake. In 2006 an engineer working on an experimental WiFi project wrote a piece of code that sampled all categories of publicly broadcast WiFi data. A year later, when our mobile team started a project to collect basic WiFi network data like SSID information and MAC addresses using Google’s Street View cars, they included that code in their software—although the project leaders did not want, and had no intention of using, payload data.

As soon as we became aware of this problem, we grounded our Street View cars and segregated the data on our network, which we then disconnected to make it inaccessible. We want to delete this data as soon as possible, and are currently reaching out to regulators in the relevant countries about how to quickly dispose of it.

Maintaining people’s trust is crucial to everything we do, and in this case we fell short. So we will be:

• Asking a third party to review the software at issue, how it worked and what data it gathered, as well as to confirm that we deleted the data appropriately; and
• Internally reviewing our procedures to ensure that our controls are sufficiently robust to address these kinds of problems in the future.

In addition, given the concerns raised, we have decided that it’s best to stop our Street View cars collecting WiFi network data entirely.

This incident highlights just how publicly accessible open, non-password-protected WiFi networks are today. Earlier this year, we encrypted Gmail for all our users, and next week we will start offering an encrypted version of Google Search. For other services users can check that pages are encrypted by looking to see whether the URL begins with “https”, rather than just “http”; browsers will generally show a lock icon when the connection is secure. For more information about how to password-protect your network, read this.

The engineering team at Google works hard to earn your trust—and we are acutely aware that we failed badly here. We are profoundly sorry for this error and are determined to learn all the lessons we can from our mistake.

Posted by Alan Eustace, Senior VP, Engineering & Research