Tag Archives: identity

Increasing user undeletion window to 20 days

A top ask from G Suite admins, we’re now increasing the window of time to restore a deleted user from five to 20 days. This extended window can be especially helpful for customers who manage user accounts through an API or other automated sync tools.

Please note, only those with super admin permissions can restore a deleted user’s account. For the steps on how to restore a user in the Admin console, check out this Help Center article.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release

Editions:
Available to all G Suite editions

Rollout pace:
Full rollout (1–3 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center: Restore a recently deleted user

Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates

8 swift steps G Suite admins can take to secure business data

(Cross-posted from The Keyword)

Security doesn’t have to be complicated. With G Suite, admins can manage and help protect their users with minimal effort because we've designed our tools to be intuitive—like Vault, which helps with eDiscovery and audit needs, and data loss prevention, which helps ensure that your “‘aha”’ moments stay yours. Here are some key security controls that you can deploy with just a few clicks to get more fine-grained control of your organization's security.

1. Enable Hangouts out-of-domain warnings
If your business allows employees to chat with external users on Hangouts, turn on a setting that will show warnings to your users if anyone outside of your domain tries to join a Hangout, and split existing group chats so external users can’t see previous internal conversations. This substantially reduces the risk of data leaks or falling prey to social engineering attacks. (Admin console > Apps > G Suite > Google Hangouts > Chat settings > Sharing options)


2. Disable email forwarding
Exercising this option will disable the automatic email forwarding feature for users, which in turn helps reduce the risk of data exfiltration in the event a user’s credentials are compromised. (Admin console > Apps > G Suite > Gmail > Advanced settings)



3. Enable early phishing detection
Enabling this option adds further checks on potentially suspicious emails prior to delivery. Early phishing detection utilizes a dedicated machine learning model that selectively delays messages to perform rigorous phishing analysis. Less than 0.05 percent of messages on average get delayed by a few minutes, so your users will still get their information fast. (Admin console > Apps > G Suite > Gmail > Advanced settings)


4. Examine OAuth-based access to third-party apps
OAuth apps whitelisting helps keep company data safe by letting you specifically select which third-party apps are allowed to access users’ G Suite data. Once an app is part of a whitelist, users can choose to grant authorized access to their G Suite apps data. This helps to prevent malicious apps from tricking people into accidentally granting access to corporate data. (Admin console > Security > G Suite API Permissions)


5. Check that unintended external reply warning for Gmail is turned on
Gmail can display unintended external reply warnings to users to help prevent data loss. You can enable this option to ensure that if your users try to respond to someone outside of your company domain, they’ll receive a quick warning to make sure they intended to send that email. Because Gmail has contextual intelligence, it knows if the recipient is an existing contact or someone your users interact with regularly, so it only displays relevant warnings. This option is on by default. (Admin console > Apps > G Suite > Gmail > Advanced settings)


6. Restrict external calendar
To reduce the incidence of data leaks, make sure that Google Calendar details aren’t shared outside your domain. Limiting sharing to “free” or “busy” information protects you from social engineering attacks that depend on gleaning information from meeting titles and attendees. (Admin console > Apps > G Suite > Calendar > Sharing settings)


7. Limit access to Google Groups
By setting default Google group access to private, you can limit external access to information channels that may contain confidential business information, like upcoming projects. (Admin console > Apps > G Suite > Groups for Business > Sharing settings)


8. Set Google+ access restrictions
Make the default sharing setting for Google+ restricted and disable discoverability of Google+ profiles outside your domain. Both of these actions can help you control access to critical business information. (Admin console > Apps > G Suite > Google+ > Advanced settings)





Every company has their own unique set of business requirements that need to work in rhythm with their security requirements. By evaluating and implementing some of these suggested security controls, you can make a marked difference in your company’s security posture—with just a few clicks. See this post for other security tips.


Launch release calendar
Launch detail categories
Get these product update alerts by email
Subscribe to the RSS feed of these updates

Enterprise Identity made easy in G Suite with Cloud Identity

Posted by Zack Ontiveros, Product Manager, Google Cloud Identity

As an IT administrator, you want to be confident that your users are secure when accessing online services. Millions of G Suite customers already rely on Google Cloud's identity services to secure their online identities with tools like single sign-on, multi-factor authentication, and mobile device management. However, many G Suite organizations have users who do not require G Suite but still need a secure, online identity.

Introducing Cloud Identity support in G Suite
Today we are happy to announce the availability of a new free Cloud Identity license for G Suite customers, which enables your non-G Suite users to get access to Google Cloud's identity services. Using Cloud Identity, you can easily create a unified sign-on for all your users across all enterprise cloud apps, set basic mobile device policies, and enforce multi-factor authentication with security keys.

Once you enable Cloud Identity in your Google Admin console, you will be able to create Cloud Identity users in all the ways you create G Suite users; the only difference is that you will not assign these users a G Suite license.



Try it today
To start using Cloud Identity, head to the Billing page in the Google Admin console. Here you will see a new Cloud Identity card under the "Enable Products" section. Once you enable the Cloud Identity subscription, you will be able to start creating free users without G Suite. For more information, check out our Getting Started Guide for G Suite admins.

Launch Details
Release track:
Launching to both Rapid Release and Scheduled Release
Note: If your domain has been provisioned or you have a billing relationship with a GSuite reseller, an onboarding flow is planned so that your reseller can add Cloud Identity subscriptions to your G Suite domain. This feature will launch in the coming weeks.

Editions:
Available to G Suite Basic, Business, and Enterprise edition domains

Rollout pace:
Gradual rollout (up to 7 days for feature visibility)

Impact:
Admins only

Action:
Admin action suggested/FYI

More Information
Help Center

Changes to Device Identifiers in Android O

Posted by Giles Hogben, Privacy Engineer

Android O introduces some improvements to help provide user control over the use of identifiers. These improvements include:

  • limiting the use of device-scoped identifiers that are not resettable
  • updating the Android O Wi-Fi stack in conjunction with changes to the Wi-Fi chipset firmware used by Pixel, Pixel XL and Nexus 5x phones to randomize MAC addresses in probe requests
  • updating the way that applications request account information and providing more user-facing control

Device identifier changes


Here are some of the device identifier changes for Android O:

Android ID


In O, Android ID (Settings.Secure.ANDROID_ID or SSAID) has a different value for each app and each user on the device. Developers requiring a device-scoped identifier, should instead use a resettable identifier, such as Advertising ID, giving users more control. Advertising ID also provides a user-facing setting to limit ad tracking.

Additionally in Android O:

  • The ANDROID_ID value won't change on package uninstall/reinstall, as long as the package name and signing key are the same. Apps can rely on this value to maintain state across reinstalls.
  • If an app was installed on a device running an earlier version of Android, the Android ID remains the same when the device is updated to Android O, unless the app is uninstalled and reinstalled.
  • The Android ID value only changes if the device is factory reset or if the signing key rotates between uninstall and reinstall events.
  • This change is only required for device manufacturers shipping with Google Play services and Advertising ID. Other device manufacturers may provide an alternative resettable ID or continue to provide ANDROID ID.

Build.SERIAL


To be consistent with runtime permissions required for access to IMEI, use of android.os.Build.SERIAL is deprecated for apps that target Android O or newer. Instead, they can use a new Android O API, Build.getSerial(), which returns the actual serial number, as long as the caller holds the PHONE permission. In a future version of Android, apps targeting Android O will see Build.SERIAL as "UNKNOWN". To avoid breaking legacy app functionality, apps targeting prior versions of Android will continue see the device's serial number, as before.

Net.Hostname


Net.Hostname provides the network hostname of the device. In previous versions of Android, the default value of the network hostname and the value of the DHCP hostname option contained Settings.Secure.ANDROID_ID. In Android O, net.hostname is empty and the DHCP client no longer sends a hostname, following IETF RFC 7844 (anonymity profile).

Widevine ID


For new devices shipping with O, the Widevine Client ID returns a different value for each app package name and web origin (for web browser apps).

Unique system and settings properties


In addition to Build.SERIAL, there are other settings and system properties that aren't available in Android O. These include:

  • ro.runtime.firstboot: Millisecond-precise timestamp of first boot after last wipe or most recent boot
  • htc.camera.sensor.front_SN: Camera serial number (available on some HTC devices)
  • persist.service.bdroid.bdaddr: Bluetooth MAC address property
  • Settings.Secure.bluetooth_address: Device Bluetooth MAC address. In O, this is only available to apps holding the LOCAL_MAC_ADDRESS permission.

MAC address randomization in Wi-Fi probe requests


We collaborated with security researchers1 to design robust MAC address randomization for Wi-Fi scan traffic produced by the chipset firmware in Google Pixel and Nexus 5X devices. The Android Connectivity team then worked with manufacturers to update the Wi-Fi chipset firmware used by these devices.

Android O integrates these firmware changes into the Android Wi-Fi stack, so that devices using these chipsets with updated firmware and running Android O or above can take advantage of them.

Here are some of the changes that we've made to Pixel, Pixel XL and Nexus 5x firmware when running O+:

  • For each Wi-Fi scan while it is disconnected from an access point, the phone uses a new random MAC address (whether or not the device is in standby).
  • The initial packet sequence number for each scan is also randomized.
  • Unnecessary Probe Request Information Elements have been removed: Information Elements are limited to the SSID and DS parameter sets.

Changes in the getAccounts API


In Android O and above, the GET_ACCOUNTS permission is no longer sufficient to gain access to the list of accounts registered on the device. Applications must use an API provided by the app managing the specific account type or the user must grant permission to access the account via an account chooser activity. For example, Gmail can access Google accounts registered on the device because Google owns the Gmail application, but the user would need to grant Gmail access to information about other accounts registered on the device.

Apps targeting Android O or later should either use AccountManager#newChooseAccountIntent() or an authenticator-specific method to gain access to an account. Applications with a lower target SDK can still use the current flow.

In Android O, apps can also use the AccountManager.setAccountVisibility()/ getVisibility() methods to manage visibility policies of accounts owned by those apps.

In addition, the LOGIN_ACCOUNTS_CHANGED_ACTION broadcast is deprecated, but still works in Android O. Applications should use addOnAccountsUpdatedListener() to get updates about accounts at runtime for a list of account types that they specify.

Check out Best Practices for Unique Identifiers for more information.


Notes


  1. Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven 

Registering OAuth clients for Google Sign-In

Posted by Isabella Chen, Software Engineer, and Laurence Moroney, Developer Advocate

Starting with Google Play services 8.3, we did a major revamp of the Google Sign-In APIs, supporting both client and server auth. Behind the scenes, these APIs use OAuth 2.0 tokens to ensure secure authentication and authorization. To maintain security, we provide tools in the Google Developers Console to register the clients using these tokens.

In this post, we’ll discuss the important task of registering OAuth clients for Google Sign-In, and the tools that we offer to make this as easy as possible.

Here are some scenarios that might apply to you:

  1. Start by creating a project in the Google Developers Console, which registers the client app on your behalf.
  2. If you have a backend server in your project, you’ll need an OAuth client ID for it, too.
  3. And don't forget to register OAuth clients for other test and release versions of your app, too!

In this post, we’ll cover some details on this process and address common pitfalls.

Getting Started - Create a Project in the Google Developers Console.

If you have not used Google Sign-In before, you can start integrating the API into your app by following the ‘Get a configuration file’ steps on this site. You’ll be taken to a setup wizard that will create an OAuth 2.0 client ID as shown in Figure 1.

Figure 1. Configuring your app

Once you’ve specified your app, you’ll be taken to a screen to choose and configure services such as Google Sign-In, Cloud Messaging or Google Analytics that you want your app to be able to use.

Choose Google Sign-In. In order to use it, you’ll need to get the SHA-1 of the signing certificate for your Android app. This can either be a debug or a release certificate, and for the purposes of this blog you’ll look at a debug one, but keep in mind that you’ll need to repeat this process for each package / certificate pair you end up using (described in the last section below).

You can get the debug SHA-1 using the keytool command like this:

keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android

Once you have your SHA-1, enter it as seen in Figure 2.

Figure 2. Enabling Google Sign-in

Now that your project is set up, you can get started with integrating the Sign-In API. But if you need to configure your project to work with a backend server or additional package name / keystores, keep reading the sections below.

Server Config - Ensure your server is registered within the same project.

If you have your own web or cloud server with data for your application, you’ll need OAuth credentials for your backend. Details on doing this can be found in the ID token and server auth code documentation.

Before using these flows, you’ll need to make sure you register your web server correctly in the Google Developers Console. Once there, you’ll be asked to select your project. See Figure 3.

Figure 3. Going directly to a project in the Google Developers Console.

Once you’ve selected your project, press the ‘Continue’ button, and you’ll go directly to the Credentials tab where all credential types are managed. Check the “OAuth 2.0 client IDs” section, and you will see the “Web client” and “Android client for com.my.package.name” that were created for you by the setup wizard. See Figure 4.

Figure 4. The Credentials Tab on the Developers Console - Web server OAuth client info

Take note of the Client ID for for your Web client, you’ll need it for both your app and server as illustrated below. (If you’ve created your project in the past and there’s no OAuth 2.0 client ID with Type “Web application”, then you will need to create one by selecting ‘New Credentials’ -> ‘OAuth client ID’.)

If you use an ID token flow for backend authentication, when you start developing your Android app, request an ID token in your GoogleSignInOptions, supplying the web client ID for your server:

GoogleSignInOptions gso =
    new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
        .requestIdToken(serverClientId)
  .requestEmail()
  .build();

And then on your server, set the same OAuth client ID for your web application to be the audience:

GoogleIdTokenVerifier verifier =
    new GoogleIdTokenVerifier.Builder(transport, jsonFactory)
        .setAudience(Arrays.asList(serverClientId))
        .setIssuer("https://accounts.google.com")
        .build();

Successful verification will allow you to authenticate and issue a session for this newly signed-in user.

Alternatively, if you are using the server auth code flow for backend access to Google APIs, request a server auth code in your GoogleSignInOptions on Android, again supplying the web client ID for your server:

GoogleSignInOptions gso =
    new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
        .requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))
  .requestServerAuthCode(serverClientId)
  .requestEmail()
  .build();

And then on the server, both the OAuth client ID and the “Client secret” will be useful. The server SDK from Google can directly consume a downloaded JSON configuration file. You can click the download icon to download the JSON file (as shown in Figure 4) and use below code to construct GoogleClientSecrets:

GoogleClientSecrets clientSecrets =
    GoogleClientSecrets.load(
        JacksonFactory.getDefaultInstance(),
        new FileReader(PATH_TO_CLIENT_SECRET_FILE));

At which point you can access authenticated Google APIs on behalf of the signed-in user. Note that the “client secret” is really a secret that you should never reveal in your Android client.

Handling multiple environments - Registering other client IDs for your project.

Note that it can be common for apps to have different package names as well as different certificates (and thus SHA-1 keys) for various types of environment (such for different developers or test and release environments). Google uses your package name together with SHA-1 signing-certificate fingerprint to uniquely identify your Android application. It’s important to register every package name + SHA1 fingerprint pair in Google Developers Console.

For example, to register the release version of this package, you can do so by selecting ‘New Credentials’ -> ‘OAuth client ID’, shown in Figure 5 below, and then following the steps to add the package name and production keystore SHA-1.

Figure 5. The Credentials Tab on the Developers Console - create additional OAuth client ID

Now you are ready to handle the different environments where your app might be running and release to your users!

Hopefully, this has been helpful to you in understanding how to register for OAuth keys to keep your apps and servers secure. For more information, check out the Google Developers homepage for Identity.

Coffee with Identity Platform Product Manager Steven Soneff

Posted by Laurence Moroney, Developer Advocate

Coffee with a Googler catches up with Steven Soneff, Product Manager for the Google Identity Platform to talk about Smart Lock for Passwords. If you’re not familiar with it, this is a terrific technology that takes the hassle out of signing in across devices to your favorite apps and websites. Smart Lock can save passwords to your Google account, and then help you use your passwords securely and conveniently on the websites you use in Chrome and the apps you use in your Android devices.

Steven demonstrates use of Smart Lock with Netflix, where at home he may sign in with the browser on his desktop, but over coffee he signs in using his smartphone. We discuss the great blog post that Steven wrote about Smart Lock, showing how it works, and how you can code your Android applications to use it. To learn more about the Google Identity Platform, check out the developers site here.