Chrome comenzará a bloquear recursos HTTP en páginas HTTPS y a comprobar la seguridad de las contraseñas

Google advertido sobre cambiar el enfoque para procesar contenido mixto en páginas abiertas a través de HTTPS. Anteriormente, si había componentes en páginas abiertas a través de HTTPS que se cargaban sin cifrado (a través del protocolo http://), se mostraba un indicador especial. En el futuro, se decidió bloquear la carga de dichos recursos de forma predeterminada. Por lo tanto, se garantizará que las páginas abiertas a través de “https://” contengan únicamente recursos descargados a través de un canal de comunicación seguro.

Cabe señalar que actualmente los usuarios de Chrome abren más del 90% de los sitios mediante HTTPS. La presencia de insertos cargados sin cifrado crea amenazas a la seguridad al modificar contenido desprotegido si hay control sobre el canal de comunicación (por ejemplo, cuando se conecta a través de Wi-Fi abierto). Se consideró que el indicador de contenido mixto era ineficaz y engañoso para el usuario, ya que no proporciona una evaluación clara de la seguridad de la página.

Actualmente, los tipos más peligrosos de contenido mixto, como scripts e iframes, ya están bloqueados de forma predeterminada, pero aún se pueden descargar imágenes, archivos de audio y vídeos a través de http://. Mediante la suplantación de imágenes, un atacante puede sustituir las cookies de seguimiento del usuario, intentar explotar vulnerabilidades en los procesadores de imágenes o cometer falsificación reemplazando la información proporcionada en la imagen.

La introducción del bloqueo se divide en varias etapas. Chrome 79, programado para el 10 de diciembre, incluirá una nueva configuración que le permitirá desactivar el bloqueo de sitios específicos. Esta configuración se aplicará al contenido mixto que ya está bloqueado, como scripts e iframes, y se abrirá a través del menú desplegable al hacer clic en el símbolo de candado, reemplazando el indicador propuesto anteriormente para deshabilitar el bloqueo.

Chrome comenzará a bloquear recursos HTTP en páginas HTTPS y a comprobar la seguridad de las contraseñas

Chrome 80, que se espera para el 4 de febrero, utilizará un esquema de bloqueo suave para archivos de audio y video, lo que implica el reemplazo automático de enlaces http:// con https://, lo que preservará la funcionalidad si el recurso problemático también es accesible a través de HTTPS. . Las imágenes seguirán cargándose sin cambios, pero si se descargan a través de http://, las páginas https:// mostrarán un indicador de conexión insegura para toda la página. Para cambiar automáticamente a https o bloquear imágenes, los desarrolladores del sitio podrán utilizar las propiedades CSP de solicitudes de actualización inseguras y bloquear todo el contenido mixto. Chrome 81, programado para el 17 de marzo, corregirá automáticamente http:// a https:// para cargas de imágenes mixtas.

Chrome comenzará a bloquear recursos HTTP en páginas HTTPS y a comprobar la seguridad de las contraseñas

Además, Google anunció el sobre la integración en una de las próximas versiones del navegador Chome del nuevo componente de verificación de contraseña, anteriormente desarrollando como adición externa. La integración conducirá a la aparición en el administrador de contraseñas habitual de Chrome de herramientas para analizar la confiabilidad de las contraseñas utilizadas por el usuario. Cuando intenta iniciar sesión en cualquier sitio, su nombre de usuario y contraseña se compararán con una base de datos de cuentas comprometidas y se mostrará una advertencia si se detectan problemas. La verificación se lleva a cabo en una base de datos que cubre más de 4 mil millones de cuentas comprometidas que aparecieron en bases de datos de usuarios filtradas. También se mostrará una advertencia si intenta utilizar contraseñas triviales como "abc123" (por estadísticas Google (23% de los estadounidenses usa contraseñas similares) o cuando usa la misma contraseña en varios sitios.

Para mantener la confidencialidad, al acceder a una API externa, solo se transmiten los dos primeros bytes del hash del inicio de sesión y la contraseña (se utiliza el algoritmo hash argonxnumx). El hash completo se cifra con una clave generada por parte del usuario. Los hashes originales en la base de datos de Google también se cifran adicionalmente y solo se dejan para la indexación los dos primeros bytes del hash. La verificación final de los hashes que se encuentran bajo el prefijo de dos bytes transmitido se lleva a cabo por parte del usuario utilizando tecnología criptográfica "ceguera“, en el que ninguna de las partes conoce el contenido de los datos que se están verificando. Para protegerse contra el contenido de una base de datos de cuentas comprometidas que se determina por fuerza bruta con una solicitud de prefijos arbitrarios, los datos transmitidos se cifran en conexión con una clave generada sobre la base de una combinación verificada de nombre de usuario y contraseña.

Fuente: opennet.ru

Añadir un comentario