Posted by Jonathan Skelker, Product Manager, Account Security

We’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

However, one form of phishing, known as “man in the middle” (MITM), is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the restriction on webview sign-ins announced in April 2016.

What developers need to know

The solution for developers currently using CEF for authentication is the same: browser-based OAuth authentication. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today.

Posted by Jeff Vander Stoep, Android Security & Privacy Team

Each Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that demonstrates the effectiveness of these improvements. But how do these features map to an overall strategy?
Last week, we released a whitepaper describing The Android Platform Security Model. Specifically we discuss:

• The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.
• The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.
• The complex threat model Android must address.
• How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.
• How Android’s security systems have evolved over time to address the threat model.

Android is fundamentally based on a multi-party consent¹ model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem.
We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading!
Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich

Notes

Posted by Nicolas Lidzborski, Senior Staff Software Engineer, Google Cloud and Nicolas Kardas, Senior Product Manager, Google Cloud 

We’re excited to announce that Gmail will become the first major email provider to follow the new SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 and SMTP TLS Reporting RFC 8460 internet standards. Those new email security standards are the result of three years of collaboration within IETF, with contributions from Google and other large email providers.

SMTP alone is vulnerable to man-in-the-middle attacks

Like all mail providers, Gmail uses Simple Mail Transfer Protocol (SMTP) to send and receive mail messages. SMTP alone only provides best-effort security with opportunistic encryption, and many SMTP servers do not prevent certain types of malicious attacks intercepting email traffic in transit.

SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle is an attack where communication between two servers is intercepted and possibly changed without detection. Real attacks and prevention were highlighted in our research published in November 2015. MTA-STS will help prevent these types of attacks.

MTA-STS uses encryption and authentication to reduce vulnerabilities

A MTA-STS policy for your domain means that you request external mail servers sending messages to your domain to verify the SMTP connection is authenticated with a valid public certificate and encrypted with TLS 1.2 or higher. This can be combined with TLS reporting, that means your domain can request daily reports from external mail servers with information about the success or failure of emails sent to your domain according to MTA-STS policy.

Gmail is starting MTA-STS adherence. We hope others will follow

Gmail the first major provider to follow the new standard, initially launching in Beta on April 10th 2019. This means Gmail will honor MTA-STS and TLS reporting policies configured when sending emails to domains that have defined these policies. We hope many other email providers will soon adopt these new standards that make email communications more secure.

Email domain administrators should set up DNS records and web server endpoint to configure MTA-STS and TLS reporting policies for incoming emails. Use our Help Center to find out how to set up an MTA-STS policy with your DNS server. G Suite admins can use the G Suite Updates blog to see what MTA-STS means for G Suite domains.