O Chrome começará a bloquear recursos HTTP em páginas HTTPS e a verificar a força das senhas

Google avisado sobre como mudar a abordagem para processar conteúdo misto em páginas abertas via HTTPS. Anteriormente, se houvesse componentes em páginas abertas via HTTPS que fossem carregadas sem criptografia (através do protocolo http://), um indicador especial era exibido. No futuro, foi decidido bloquear o carregamento de tais recursos por padrão. Assim, será garantido que as páginas abertas via “https://” conterão apenas recursos baixados por meio de um canal de comunicação seguro.

Observa-se que atualmente mais de 90% dos sites são abertos por usuários do Chrome usando HTTPS. A presença de inserções carregadas sem criptografia cria ameaças à segurança através da modificação de conteúdo desprotegido se houver controle sobre o canal de comunicação (por exemplo, ao conectar-se via Wi-Fi aberto). O indicador de conteúdo misto foi considerado ineficaz e enganoso para o usuário, pois não fornece uma avaliação clara da segurança da página.

Atualmente, os tipos mais perigosos de conteúdo misto, como scripts e iframes, já estão bloqueados por padrão, mas imagens, arquivos de áudio e vídeos ainda podem ser baixados via http://. Através da falsificação de imagens, um invasor pode substituir cookies de rastreamento do usuário, tentar explorar vulnerabilidades em processadores de imagens ou cometer falsificações substituindo as informações fornecidas na imagem.

A introdução do bloqueio está dividida em várias etapas. O Chrome 79, previsto para 10 de dezembro, contará com uma nova configuração que permitirá desativar o bloqueio para sites específicos. Esta configuração será aplicada a conteúdos mistos já bloqueados, como scripts e iframes, e será acessada através do menu suspenso ao clicar no símbolo de cadeado, substituindo o indicador proposto anteriormente para desabilitar o bloqueio.

O Chrome começará a bloquear recursos HTTP em páginas HTTPS e a verificar a força das senhas

O Chrome 80, previsto para 4 de fevereiro, usará um esquema de bloqueio suave para arquivos de áudio e vídeo, implicando na substituição automática de links http:// por https://, o que preservará a funcionalidade caso o recurso problemático também seja acessível via HTTPS . As imagens continuarão sendo carregadas sem alterações, mas se baixadas via http://, as páginas https:// exibirão um indicador de conexão insegura para a página inteira. Para mudar automaticamente para https ou bloquear imagens, os desenvolvedores do site poderão usar as propriedades CSP upgrade-insecure-requests e block-all-mixed-content. O Chrome 81, programado para 17 de março, corrigirá automaticamente http:// para https:// para uploads de imagens mistas.

O Chrome começará a bloquear recursos HTTP em páginas HTTPS e a verificar a força das senhas

Além disso, o Google anunciou o sobre a integração em uma das próximas versões do navegador Chome do novo componente Password Checkup, anteriormente em desenvolvimento como adição externa. A integração levará ao aparecimento no gerenciador de senhas normal do Chrome de ferramentas para analisar a confiabilidade das senhas utilizadas pelo usuário. Ao tentar fazer login em qualquer site, seu login e senha serão verificados em um banco de dados de contas comprometidas, com um aviso exibido caso sejam detectados problemas. A verificação é realizada em um banco de dados que cobre mais de 4 bilhões de contas comprometidas que apareceram em bancos de dados de usuários vazados. Um aviso também será exibido se você tentar usar senhas triviais como "abc123" (por estatísticas Google (23% dos americanos usam senhas semelhantes) ou quando usam a mesma senha em vários sites.

Para manter a confidencialidade, ao acessar uma API externa, apenas os dois primeiros bytes do hash do login e senha são transmitidos (é utilizado o algoritmo de hash argonxnumx). O hash completo é criptografado com uma chave gerada pelo usuário. Os hashes originais no banco de dados do Google também são criptografados adicionalmente e apenas os dois primeiros bytes do hash são deixados para indexação. A verificação final dos hashes que se enquadram no prefixo de dois bytes transmitido é realizada por parte do usuário por meio de tecnologia criptográfica “cegueira“, em que nenhuma das partes conhece o conteúdo dos dados que estão sendo verificados. Para proteger contra a determinação do conteúdo de um banco de dados de contas comprometidas por força bruta com uma solicitação de prefixos arbitrários, os dados transmitidos são criptografados em conexão com uma chave gerada com base em uma combinação verificada de login e senha.

Fonte: opennet.ru

Adicionar um comentário