Chrome will start blocking HTTP resources on HTTPS pages and checking the strength of passwords

Google company warned about changing the approach to handling mixed content on pages opened via HTTPS. Previously, if there were components on pages opened via HTTPS that were loaded from without encryption (using the http:// protocol), a special indicator was displayed. In the future, it was decided to block the loading of such resources by default. Thus, pages opened via "https://" will be guaranteed to contain only resources downloaded via a secure communication channel.

It is noted that currently more than 90% of sites are opened by Chrome users using HTTPS. The presence of inserts loaded without encryption creates security risks through the modification of unprotected content when there is control over the communication channel (for example, when connected via open Wi-Fi). The mixed content indicator is considered ineffective and misleading to the user, as it does not provide an unambiguous assessment of the page's safety.

Currently, the most dangerous types of mixed content, such as scripts and iframes, are already blocked by default, but images, sound files, and videos can still be downloaded from http://. Through image spoofing, an attacker can substitute cookies for tracking user actions, try to exploit vulnerabilities in image processors, or commit fraud by replacing the information presented in the image.

The introduction of blocking is divided into several stages. In Chrome 79, scheduled for December 10, there will be a new setting that will allow you to turn off blocking for specific sites. This setting will apply to mixed content that is already blocked, such as scripts and iframes, and will be invoked through the drop-down menu when clicking on the lock symbol, replacing the previously proposed indicator for disabling blocking.

Chrome will start blocking HTTP resources on HTTPS pages and checking the strength of passwords

Chrome 80, which is due February 4, will implement a soft sound and video blocking scheme that automatically replaces http:// with https:// links, which will keep working if the problematic resource is also available via HTTPS. Images will continue to load as is, but when loaded via http:// on https:// pages, an insecure connection indicator will be displayed for the entire page. Site developers can use the upgrade-insecure-requests and block-all-mixed-content CSP properties to autocorrect to https or block images. In the March 81 release of Chrome 17, mixed image uploads will autocorrect http:// to https://.

Chrome will start blocking HTTP resources on HTTPS pages and checking the strength of passwords

In addition, Google announced about integrating the new Password Checkup component into one of the next releases of the Chome browser, previously developing as external addition. Integration will lead to the appearance in the regular Chrome password manager of tools for analyzing the strength of passwords used by the user. When you try to log in to any site, the login and password will be checked against the database of compromised accounts with a warning in case of problems. The check is carried out against a database covering more than 4 billion compromised accounts that appeared in leaks of user databases. A warning will also be displayed when attempting to use trivial passwords such as "abc123" (according to Statistics Google 23% of Americans use similar passwords), or when using the same password on multiple sites.

To maintain confidentiality, when accessing an external API, only the first two bytes of the hash from the combination of login and password are transmitted (the algorithm is used for hashing Argon2). The full hash is encrypted with a user-generated key. The original hashes in the Google database are also additionally encrypted and only the first two bytes of the hash are left for indexing. The final verification of hashes that fall under the transmitted two-byte prefix is ​​performed on the user side using the cryptographic technique "blinding“, in which neither party knows the content of the data being checked. To protect against determining the contents of the database of compromised accounts by brute force with a request for arbitrary prefixes, the given data is encrypted in relation to a key generated based on the login and password being checked.

Source: opennet.ru

Add a comment