We're constantly working to secure our users and their data. Earlier this year, we detailed some of our latest anti-phishing tools and rolled-out developer-focused updates to our app publishing processes, risk assessment systems, and user-facing consent pages. Most recently, we introduced OAuth apps whitelisting in G Suite to enable admins to choose exactly which third-party apps can access user data.
Over the past few months, we've required that some new web applications go through a verification process prior to launch based upon a dynamic risk assessment.
Today, we're expanding upon that foundation, and introducing additional protections: bolder warnings to inform users about newly created web apps and Apps Scripts that are pending verification. Additionally, the changes we're making will improve the developer experience. In the coming months, we will begin expanding the verification process and the new warnings to existing apps as well.
Beginning today, we're rolling out an "unverified app" screen for newly created web applications and Apps Scripts that require verification. This new screen replaces the "error" page that developers and users of unverified web apps receive today.
The "unverified app" screen precedes the permissions consent screen for the app and lets potential users know that the app has yet to be verified. This will help reduce the risk of user data being phished by bad actors.
This new notice will also help developers test their apps more easily. Since users can choose to acknowledge the 'unverified app' alert, developers can now test their applications without having to go through the OAuth client verification process first (see our earlier post for details).
Developers can follow the steps laid out in this help center article to begin the verification process to remove the interstitial and prepare your app for launch.
We're also extending these same protections to Apps Script. Beginning this week, new Apps Scripts requesting OAuth access to data from consumers or from users in other domains may also see the "unverified app" screen. For more information about how these changes affect Apps Script developers and users, see the verification documentation page.
Apps Script is proactively protecting users from abusive apps in other ways as well. Users will see new cautionary language reminding them to "consider whether you trust" an application before granting OAuth access, as well as a banner identifying web pages and forms created by other users.
In the coming months, we will continue to enhance user protections by extending the verification process beyond newly created apps, to existing apps as well. As a part of this expansion, developers of some current apps may be required to go through the verification flow.
To help ensure a smooth transition, we recommend developers verify that their contact information is up-to-date. In the Google Cloud Console, developers should ensure that the appropriate and monitored accounts are granted either the project owner or billing account admin IAM role. For help with granting IAM roles, see this help center article.
In the API manager, developers should ensure that their OAuth consent screen configuration is accurate and up-to-date. For help with configuring the consent screen, see this help center article.
We're committed to fostering a healthy ecosystem for both users and developers. These new notices will inform users automatically if they may be at risk, enabling them to make informed decisions to keep their information safe, and will make it easier to test and develop apps for developers.
Last week, we took immediate action to protect users from a phishing attack that attempted to abuse the OAuth authorization infrastructure.
Today, we’re supplementing those efforts to help prevent these types of issues in the future. These changes may add some friction and require more time before you are able to publish your web application, so we recommend that you plan your work accordingly.
To further enforce this policy, we are updating our app publishing process, our risk assessment systems, and our user-facing consent page in order to better detect spoofed or misleading application identities. You may see an error message as you’re registering new applications or modifying existing application attributes in the Google API Console, Firebase Console, or Apps Script editor as a result of this change.
Based on this risk assessment, some web applications will require a manual review. Until the review is complete, users will not be able to approve the data permissions, and we will display an error message instead of the permissions consent page. You can request a review during the testing phase in order to open the app to the public. We will try to process those reviews in 3-7 business days. In the future, we will enable review requests during the registration phase as well.
You can continue to use your app for testing purposes before it is approved by logging in with an account registered as an owner/editor of that project in the Google API Console. This will enable you to add additional testers, as well as initiate the review process.
We also recommend developers review our earlier post outlining their responsibilities when requesting access to user data from their applications. Our teams will continue our constant efforts to support a powerful, useful developer ecosystem that keeps users and their data safe.
hd and/or login_hint p
hd
Posted by Michael Winser, Product Lead, Google Apps and Wesley Chun, Developer Advocate, Google Apps
Last week, we clarified the expectations and responsibilities when accessing Google user data via OAuth 2.0. Today, we’re announcing that in order to better protect users, we are increasing account security for enterprise Gmail users effective October 5, 2016. At this time, a new policy will take effect whereby users in a Google Apps domain, while changing their passwords on or after this date, will result in the revocation of the OAuth 2.0 tokens of apps that access their mailboxes using Gmail-based authorization scopes. Please note that users will not notice any specific changes on this date and their applications will continue to work. It is only when a user changes their password from that point moving forward that their Gmail-related tokens become invalid.
Developers should modify their applications to handle HTTP 400 or 401 error codes resulting from revoked tokens and prompt their users to go through the OAuth flow again to re-authorize those apps, such that they can access the user’s mailbox again (additional details below). Late last year, we announced a similar, planned change to our security policy that impacted a broader set of authorization scopes. We later decided not to move forward with that change for Apps customers and began working on a less impactful update as described above.
What is a revoked token?
A revoked OAuth 2.0 token no longer provides access to a user’s resources. Any attempt to use a revoked token in API calls will result in an error. Any existing token strings will no longer have any value and should be discarded. Applications accessing Google APIs should be modified to handle failed API calls.
Token revocation itself is not a new feature. Users have always been able to revoke access to applications in Security Checkup, and Google Apps admins have the ability to do the same in the Admin console. In addition, tokens that were not used for extended periods of time have always been subject to expiration or revocation. This change in our security policy will likely increase the rate of revoked tokens that applications see, since in some cases the process will now take place automatically.
What APIs and scopes are impacted?
To achieve the security benefits of this policy change with minimal admin confusion and end-user disruption, we’ve decided to limit its application to mail scopes only and to exclude Apps Script tokens. Apps installed via the Google Apps Marketplace are also not subject to the token revocation. Once this change is in effect, third-party mail apps like Apple Mail and Thunderbird―as well as other applications that use multiple scopes that include at least one mail scope―will stop accessing data upon password reset until a new OAuth 2.0 token has been granted. Your application will need to detect this scenario, notify the user that your application has lost access to their account data, and prompt them to go through the OAuth 2.0 flow again.
Mobile mail applications are also included in this policy change. For example, users who use the native mail application on iOS will have to re-authorize with their Google account credentials when their password has been changed. This new behavior for third-party mail apps on mobile aligns with the current behavior of the Gmail apps on iOS and Android, which also require re-authorization upon password reset.
How can I determine if my token was revoked?
Both short-lived access tokens and long-lived refresh tokens will be revoked when a user changes their password. Using a revoked access token to access an API or to generate a new access token will result in either HTTP 400 or 401 errors. If your application uses a library to access the API or handle the OAuth flow, then these errors will likely be thrown as exceptions. Consult the library’s documentation for information on how to catch these exceptions. NOTE: because HTTP 400 errors may be caused by a variety of reasons, expect the payload from a 400 due to a revoked token to be similar to the following:
{ "error_description": "Token has been revoked.", "error": "invalid_grant" }
How should my application handle revoked tokens?
This change emphasizes that token revocation should be considered a normal condition, not an error scenario. Your application should expect and detect the condition, and your UI should be optimized for restoring tokens.
To ensure that your application works correctly, we recommend doing the following:
If your application uses incremental authorization to accrue multiple scopes in the same token, you should track which features and scopes a given user has enabled. The end result is that if your app requested and obtained authorization for multiple scopes, and at least one of them is a mail scope, that token will be revoked, meaning you will need to prompt your user to re-authorize for all scopes originally granted.
Many applications use tokens to perform background or server-to-server API calls. Users expect this background activity to continue reliably. Since this policy change also affects those apps, this makes prompt notification requesting re-authorization even more important.
What is the timeline for this change?
To summarize, properly configured applications should be expected to handle invalid tokens in general, whether they be from expiration, non-existence, and revocation as normal conditions. We encourage developers to make any necessary changes to give their users the best experience possible. The policy change is planned to take effect on October 5, 2016.
Please see this Help Center article and FAQ for more details and the full list of mail scopes. Moving forward, any additional scopes to be added to the policy will be communicated in advance. We will provide those details as they become available.
Originally posted by the Webmaster Central Blog.
If you publish anything online, one of your top priorities should be security. Getting hacked can negatively affect your online reputation and result in loss of critical and private data. Over the past year Google has noticed a 180% increase in the number of sites getting hacked. While we are working hard to combat this hacked trend, there are steps you can take to protect your content on the web.
This week, Google Webmasters has launched a second #NoHacked campaign. We’ll be focusing on how to protect your site from hacking and give you better insight into how some of these hacking campaigns work. You can follow along with #NoHacked on Twitter and Google+. We’ll also be wrapping up with a Google Hangout focused on security where you can ask our security experts questions.
We’re kicking off the campaign with some basic tips on how to keep your site safe on the web.
Creating a password that’s difficult to guess or crack is essential to protecting your site. For example, your password might contain a mixture of letters, numbers, symbols, or be a passphrase. Password length is important. The longer your password, the harder it will be to guess. There are many resources on the web that can test how strong your password is. Testing a similar password to yours (never enter your actual password on other sites) can give you an idea of how strong your password is.
Also, it’s important to avoid reusing passwords across services. Attackers often try known username and password combinations obtained from leaked password lists or hacked services to compromise as many accounts as possible.
You should also turn on 2-Factor Authentication for accounts that offer this service. This can greatly increase your account’s security and protect you from a variety of account attacks. We’ll be talking more about the benefits of 2-Factor Authentication in two weeks.
One of the most common ways for a hacker to compromise your site is through insecure software on your site. Be sure to periodically check your site for any outdated software, especially updates that patch security holes. If you use a web server like Apache, nginx or commercial web server software, make sure you keep your web server software patched. If you use a Content Management System (CMS) or any plug-ins or add-ons on your site, make sure to keep these tools updated with new releases. Also, sign up to the security announcement lists for your web server software and your CMS if you use one. Consider completely removing any add-ons or software that you don't need on your website -- aside from creating possible risks, they also might slow down the performance of your site.
Your hosting provider’s policy for security and cleaning up hacked sites is in an important factor to consider when choosing a hosting provider. If you use a hosting provider, contact them to see if they offer on-demand support to clean up site-specific problems. You can also check online reviews to see if they have a track record of helping users with compromised sites clean up their hacked content.
If you control your own server or use Virtual Private Server (VPS) services, make sure that you’re prepared to handle any security issues that might arise. Server administration is very complex, and one of the core tasks of a server administrator is making sure your web server and content management software is patched and up to date. If you don't have a compelling reason to do your own server administration, you might find it well worth your while to see if your hosting provider offers a managed services option.
It’s important to have tools that can help you proactively monitor your site.The sooner you can find out about a compromise, the sooner you can work on fixing your site.
We recommend you sign up for Search Console if you haven’t already. Search Console is Google’s way of communicating with you about issues on your site including if we have detected hacked content. You can also set up Google Alerts on your site to notify you if there are any suspicious results for your site. For example, if you run a site selling pet accessories called www.example.com, you can set up an alert for [site:example.com cheap software] to alert you if any hacked content about cheap software suddenly starts appearing on your site. You can set up multiple alerts for your site for different spammy terms. If you’re unsure what spammy terms to use, you can use Google to search for common spammy terms.
We hope these tips will keep your site safe on the web. Be sure to follow our social campaigns and share any tips or tricks you might have about staying safe on the web with the #NoHacked hashtag.
If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26th.
Posted by Eric Kuan, Webmaster Relations Specialist and Yuan Niu, Webspam Analyst
Posted by Adam Dawes, Product Manager
Identity is an important building block to any app. Even if it’s not top of mind when you’re building out new features, authentication is critical to get right. We realize developers want their users to have an efficient and secure experience with their products rather than dealing with forgotten passwords that prevent app usage. The Google Identity Platform is a suite of developer tools that cuts friction out of every step of getting people signed in: Smart Lock for Passwords, Google Sign-in, and Identity Toolkit.
Smart Lock is a password manager built into your Google account. It can automatically sign you into an Android app, and autofills credentials on websites viewed with Chrome. It removes the need to remember and type in password credentials.
We're now extending Smart Lock as an API to app developers and publishers, starting with Android. Android developers can programmatically save and retrieve credentials, and automatically sign their users in across devices and websites in Chrome. Companies like Eventbrite, Orbitz, Netflix, Instacart, the New York Times, and soon — LinkedIn, are using Smart Lock for Passwords to get people automatically signed-in across their properties.
How does Smart Lock for Passwords work for your app or site? It recognizes and pre-fills login credentials across devices. When a user signs into or signs-up on your property, they’ll see a Smart Lock prompt to save their password for future use. If they accept, they’ll never have to enter a password again on your Android app or website on Chrome. In turn, this helps your app or site boost sign-up and sign-in rates for new and existing users.
This also means when your users buy and activate new devices, they can easily download and get logged right back into your app using the proper account. You don’t have to spend resources in re-acquiring them again, or encounter forgotten passwords along the way.
Here’s how early partners are using Smart Lock for Passwords, which you can see rolling out in their Android apps and websites on Chrome.
Later on this year, we’re planning to offer new features including support for sync passphrases and Smart Lock for Passwords API support on other platforms. Stay tuned!
Google Sign-in is the gateway to securely connecting Google’s users and services to your app or site. It reduces the burden of login for your users, by enabling them to sign in with their Google account—the same account they already use with Gmail, Play, Google+, and other Google services. The New York Times was able attribute a 20% lift in new registered user signups to the implementation of Google Sign-In, in the months immediately following launch.
Identity Toolkit gives you a robust, more secure authentication system that helps you do sign-in the right way, and can grow with your app. The toolkit supports email and password authentication as well as major identity providers including Google and Facebook. Even non-technical developers can add future sign-in options and migrate existing users with simple configuration changes. Getting started with Identity Toolkit lets you easily scale your auth system as you grow across platforms.
We hope that the Google Identity Platform makes it easy for your users to sign in, so that you can deliver them more personalized, engaging experiences. To view documentation, visit developers.google.com/identity
HTTP 403
Error=BadAuthenticationInfo=InvalidSecondFactor
Cross-posted from the Google Enterprise Blog
Google Apps is designed to provide a secure and reliable platform for your data. Until today, Google Apps administrators had to sign requests for calls to Google Apps APIs using their username and password (this is called ClientLogin Authorization).
Yet sharing passwords across sites can pose security risks. Furthering our commitment to make the cloud more secure for our users, today we are pleased to announce support for OAuth authorization on Google Apps APIs.
There are several advantages to using OAuth instead of the username/password model:
The Google Apps APIs that support the OAuth signing mechanism are:
OAuth support for Google Apps APIs is another step towards making Google Apps the most secure, reliable cloud based computing environment for organizations. To learn more about OAuth support and other administrative capacities launched in Google Apps this quarter, join us for a live webinar on Wednesday, September 29th at 9am PT / 12pm EST / 5pm GMT.
Administrators for Google Apps Premier, Education, and Government Editions can use OAuth authorization for Google Apps APIs starting today.For more information about the OAuth standard, visit http://oauth.net.
.png)
