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.
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.
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).
Someone has put up a post on imgur claiming to demonstrate unlocking a Galaxy S10 by 3d printing a fingerprint based on an image of the fingerprint,
First I simply took a photograph of my fingerprint on the side of a wine glass. I used my smartphone to take this picture, but it’s certainly not out of the question to use a long focal length DSLR camera to snag a fingerprint image from across a room…or further.
I then pulled the image into Photoshop and increased the contrast, and created an alpha mask.
I exported that over to 3ds Max and created a geometry displacement from the Photoshop image which gave me a raised 3d model of every last detail of the fingerprint.
I popped that model into the 3D printing software and began to print it. This was printed using an AnyCubic Photon LCD resin printer, which is accurate down to about 10 microns (in Z height, 45 microns in x/y), which is more than enough detail to capture all of the ridges in a fingerprint.
As the author of the post notes, if a smartphone is stolen, it is likely that a fingerprint of the owner will be found on the phone itself (especially if the user is repeatedly touching a specific area of the screen to unlock it, as someone using the ultrasonic fingerprint reader would be doing).
Why the f— is ESPN still not using TLS in 2019? This is extremely irresponsible behavior from a company owned by one of the largest media companies in the world (Disney). There are zero excuses for putting its users at risk this way.
Somebody made off with terabytes of data from Citrix, and one of the interesting tidbits from Citrix’s press release about the breach is speculation that the hackers used “password spraying,”
While not confirmed, the FBI has advised that the hackers likely used a tactic known as password spraying, a technique that exploits weak passwords. Once they gained a foothold with limited access, they worked to circumvent additional layers of security.
Traditional brute-force attacks attempt to gain unauthorized access to a single account by guessing the password. This can quickly result in the targeted account getting locked-out, as commonly used account-lockout policies allow for a limited number of failed attempts (typically three to five) during a set period of time. During a password-spray attack (also known as the “low-and-slow” method), the malicious actor attempts a single commonly used password (such as ‘Password1’ or ‘Summer2017’) against many accounts before moving on to attempt a second password, and so on. This technique allows the actor to remain undetected by avoiding rapid or frequent account lockouts.
Clever. With access to enough account usernames, somebody somewhere in an organization is likely to have practiced poor password hygiene.