Chrome Galvanizer–Generate Chrome Enterprise Policies

Chrome Galvanizer is a tool for creating an enterprise policy for Chrome.

Chrome Galvanizer is a tool to generate Chrome enterprise policies to help users harden their browser security. Currently, the main support is for generating policies to restrict extension access from sites explicitly marked as sensitive (e.g. your email, bank, cryptocurency, and other sites). This allows you to prevent extensions from accessing these specific sites even if you’ve already granted them permission to do so when first installing them.

Blaming Users for Stupid Security Schemes

CNN’s Scott Andrew wrote a story advising people to not share old photos on Facebook.

In an act of social media solidarity with high school seniors who are finishing out their final semester at home, Facebook users are sharing their own senior photos with the hashtag #ClassOf2020.

It’s a sweet sentiment, sure, but beware: Your post could help potential hackers crack into your private accounts, according to the Better Business Bureau, a nonprofit that tracks, among other things, internet scams.

Malevolent scammers can scan sites for this hashtag and find the name of your high school and your graduating year — two common online security questions. And if your social media account isn’t locked up, they can find out a lot more about you.

So before you share, the bureau suggests you tighten your security settings so strangers can’t find your information as easily and regularly change the security questions you use to access online banking and other services.

This gets the issue completely backwards.

The problem is not that people share photos of senior photos online. That is a completely normal, human thing to do. For many of us, our senior photos have been online for years due to other people uploading scans of our yearbooks.

No, the problem here–and the one that really deserves more coverage–is that banks and other businesses continue to insist on using security questions to protect accounts in 2020.

There is zero security in security questions, and it should be a scandal that so many institutions still force customers to use them.

Firefox Enables DNS over HTTPS

Mozilla created a bit of controversy today by enabling DNS over HTTPS by default in the United States.

DoH will encrypt DNS traffic from clients (browsers) to resolvers through HTTPS so that users’ web browsing can’t be intercepted or tampered with by someone spying on the network. The resolvers we’ve chosen to work with so far – Cloudflare and NextDNS – have agreed to be part of our Trusted Recursive Resolver program. The program places strong policy requirements on the resolvers and how they handle data. This includes placing strict limits on data retention so providers- including internet service providers – can no longer tap into an unprotected stream of a user’s browsing history to build a profile that can be sold, or otherwise used in ways that people have not meaningfully consented to. We hope to bring more partners into the TRR program.

I agree with Bruce Schneier that this “is a great idea, and long overdue.”

A lot of the criticism of DNS over HTTPS is reminiscent of the criticism over TLS 1.3. Enterprises took advantage of poor security in DNS and TLS 1.2 to manage their networks, which is understandable. But we shouldn’t kneecap the security of the 3.2 billion people worldwide who use the Internet in favor of special interests.

A lot of that criticism also involves “experts” talking out of both sides of their mouths. For example, Caitlin Cimpanu offers contradictory complaints in ZDNet that, on the one hand, DoH doesn’t prevent ISPs or other network providers from tracking users.

But, in the same article, Cimpanu argues that DoH bypasses enterprise policies because it makes it impossible for those enterprises to track users.

Google Creates an Open Source FIDO/U2F Project

On January 30, 2020, Google announced it was creating OpenSK, an open source FIDO/U2F implementation, in the hopes of spurring broader research and implementation of the security technology.

Today, FIDO security keys are reshaping the way online accounts are protected by providing an easy, phishing-resistant form of two-factor authentication (2FA) that is trusted by a growing number of websites, including Google, social networks, cloud providers, and many others. To help advance and improve access to FIDO authenticator implementations, we are excited, following other open-source projects like Solo and Somu, to announce the release of OpenSK, an open-source implementation for security keys written in Rust that supports both FIDO U2F and FIDO2 standards.

By opening up OpenSK as a research platform, our hope is that it will be used by researchers, security key manufacturers, and enthusiasts to help develop innovative features and accelerate security key adoption.

80% of Android Apps Use TLS to Encrypt Traffic

Back in 2018, Google announced that beginning with Android 9, it would prevent apps from using unencrypted connections by default. As of December 2019, Google notes that 80 percent of all apps in the Google Play store use TLS, and that rises to 90 percent of all apps targeting Android 9 and higher.

Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.

Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.

That last sentence is a bit concerning. If app developers want to explicitly make their apps communicate through unencrypted connections, that’s fine, but as far as I can tell there is no way that consumers are made aware of this.

Just as modern browsers warn me that the website I’m visiting doesn’t use encryption, Google should inform users when they are using apps that do so as well. I’d be happy with a notification on the Google Play store page for such apps that “This app sends network traffic over unencrypted channels” or something like that.

(Yes, users could set up a packet analysis tool to look at the data their phone is sending, but they shouldn’t have to do so).

WordPress WPS Hide Login Plugin

WPS Hide Login is a WordPress plugin that obfuscates the login page for a WordPress install.

It doesn’t literally rename or change files in core, nor does it add rewrite rules. It simply intercepts page requests and works on any WordPress website. The wp-admin directory and wp-login.php page become inaccessible, so you should bookmark or remember the url. Deactivating this plugin brings your site back exactly to the state it was before.

Honestly, I did this more to stop an annoyance than anything. There are tons of bots out there that try to do credential stuffing and dictionary attacks against even tiny sites like mine.

They’re unlikely to get past my strong password and 2FA, but it was getting annoying to see the constant stream of “user X has been locked out for 4 hours.”

I used the WPS Hide Login to set my login page to a random 16 character alphanumeric string that would be essentially impossible to guess.