Google will block sign-ins from CEF browsers in June 2019

[salvadordf]

https://security.googleblog.com/2019/04 ... iddle.html

Better protection against Man in the Middle phishing attacks
April 18, 2019
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.

[salvadordf]

I'm sorry but I don't work for Google and I only know what's said in the article.

We'll have to wait and see...

[salvadordf]

I just checked and you can still log in to Google using CEF browsers but they plan to stop this in June.

[thefunkyjoint]

If you change the user agent, how can Google know if we are using CEF or Chrome ?

[salvadordf]

I'm not an expert in web browser fingerprinting but there are many blog articles describing several techniques to identify each user, computer and browser.

These are just a few search results about it :

https://medium.com/@ravielakshmanan/web ... ac3c381805
http://www.cs.tufts.edu/comp/116/archiv ... havens.pdf
http://publications.lib.chalmers.se/rec ... 163728.pdf

[thefunkyjoint]

I just checked and you can still log in to Google using CEF browsers but they plan to stop this in June.

That's really bad news... so any app using CEF (like Briskbard) basically won't be able to access any google service (gmail, docs etc) ?

[salvadordf]

The CEF maintainer started a conversation with the Google sign-in team about all this in the "Chromium Embedders" forum :
https://groups.google.com/a/chromium.or ... j1v_cqBgAJ

I also mentioned BriskBard in that thread.

[thefunkyjoint]

Do you know details about that 'browser-based OAuth authentication' the guy mention ? Can it be adapted to use with CEF4Delphi ?

[salvadordf]

Do you know details about that 'browser-based OAuth authentication' the guy mention ? Can it be adapted to use with CEF4Delphi ?

I can only guess what he really means. I received an email from someone in that forum that is in contact with the Google team in charge of that change and I'm waiting for more information.

I'll keep you informed as soon as I receive that information.

[salvadordf]

The author of the blog post said this in the "Chromium Embedders" forum :

Firstly apologies for any anxiety or confusion caused by my blog post last month. To clarify, as of June we will start blocking sign-ins that are obviously automated; existing apps will not be affected. In hindsight the blog post is definitely unclear as to the scope of the June launch, and it would have been better to reach out to this group in advance.

The signals we use to detect automation are sensitive, so unfortunately we can’t share the raw data, but they have shown us clearly that a significant amount of malicious automation comes from CEF and other embedded frameworks. Over time this means that we can’t guarantee we won’t block a legitimate app from signing in if it implements sign-in using the same tools as a malicious app. Regardless as to whether an app appears suspicious or not, as part of efforts to make the web a safer place and better educate users, we want to eventually stop supporting any sign-in to Google from an environment that hides the URL.

Applications that require a Google sign-in should authenticate using OAuth via the system browser, even if they are embedding a browser engine, or consider migrating to Progressive Web Apps. We will be publishing more guidance and a timeline for migrating existing applications later this month. Meanwhile please reach out to me if you have questions or concerns about changes you need to make or the timeframe you’ll be able to make them in.

Jonathan

We'll have to wait and see what they publish later this month.