Chrome sal begin om HTTP-bronne op HTTPS-bladsye te blokkeer en die sterkte van wagwoorde na te gaan

Google gewaarsku oor die verandering van die benadering tot die verwerking van gemengde inhoud op bladsye wat via HTTPS oopgemaak word. Voorheen, as daar komponente was op bladsye wat via HTTPS oopgemaak is wat van sonder enkripsie (via die http://-protokol) gelaai is, is 'n spesiale aanwyser vertoon. Daar is in die toekoms besluit om die laai van sulke hulpbronne by verstek te blokkeer. Dus, bladsye wat via "https://" oopgemaak word, sal gewaarborg word om slegs hulpbronne te bevat wat via 'n veilige kommunikasiekanaal afgelaai is.

Daar word opgemerk dat tans meer as 90% van werwe deur Chrome-gebruikers wat HTTPS gebruik, oopgemaak word. Die teenwoordigheid van insetsels wat sonder enkripsie gelaai is, skep sekuriteitsbedreigings deur die wysiging van onbeskermde inhoud as daar beheer oor die kommunikasiekanaal is (byvoorbeeld wanneer u via oop Wi-Fi verbind). Daar is gevind dat die gemengde inhoud-aanwyser ondoeltreffend en misleidend vir die gebruiker is, aangesien dit nie 'n duidelike beoordeling van die sekuriteit van die bladsy verskaf nie.

Tans is die gevaarlikste tipes gemengde inhoud, soos skrifte en iframes, reeds by verstek geblokkeer, maar beelde, oudiolêers en video's kan steeds via http:// afgelaai word. Deur beeldbedrog kan 'n aanvaller gebruikernasporingskoekies vervang, probeer om kwesbaarhede in beeldverwerkers uit te buit, of vervalsing pleeg deur die inligting wat in die beeld verskaf word, te vervang.

Die bekendstelling van die blokkering word in verskeie fases verdeel. Chrome 79, wat vir 10 Desember beplan word, sal 'n nuwe instelling hê wat jou sal toelaat om blokkering vir spesifieke werwe te deaktiveer. Hierdie instelling sal toegepas word op gemengde inhoud wat reeds geblokkeer is, soos skrifte en iframes, en sal opgeroep word deur die spyskaart wat afval wanneer jy op die sluitsimbool klik, wat die voorheen voorgestelde aanwyser vir die deaktivering van blokkering vervang.

Chrome sal begin om HTTP-bronne op HTTPS-bladsye te blokkeer en die sterkte van wagwoorde na te gaan

Chrome 80, wat op 4 Februarie verwag word, sal 'n sagte blokkeerskema vir oudio- en videolêers gebruik, wat outomatiese vervanging van http://-skakels met https:// impliseer, wat funksionaliteit sal behou as die problematiese hulpbron ook toeganklik is via HTTPS . Prente sal voortgaan om sonder veranderinge te laai, maar as dit via http:// afgelaai word, sal die https://-bladsye 'n onveilige verbindingsaanwyser vir die hele bladsy vertoon. Om outomaties na https te verander of beelde te blokkeer, sal werfontwikkelaars die CSP-eienskappe upgrade-insecure-requests en block-all-mixed-content kan gebruik. Chrome 81, geskeduleer vir 17 Maart, sal outokorrigeer http:// na https:// vir gemengde beeld-oplaaie.

Chrome sal begin om HTTP-bronne op HTTPS-bladsye te blokkeer en die sterkte van wagwoorde na te gaan

Boonop Google aangekondig oor die integrasie in een van die volgende vrystellings van die Chome-blaaier van die nuwe Wagwoordkontrole-komponent, voorheen ontwikkel in die vorm eksterne toevoeging. Integrasie sal lei tot die verskyning in die gewone Chrome-wagwoordbestuurder van nutsgoed vir die ontleding van die betroubaarheid van die wagwoorde wat deur die gebruiker gebruik word. Wanneer jy probeer om by enige webwerf aan te meld, sal jou aanmelding en wagwoord teen 'n databasis van gekompromitteerde rekeninge gekontroleer word, met 'n waarskuwing wat vertoon word as probleme opgespoor word. Die kontrole word uitgevoer teen 'n databasis wat meer as 4 miljard gekompromitteerde rekeninge dek wat in uitgelekte gebruikersdatabasisse verskyn het. 'n Waarskuwing sal ook vertoon word as jy probeer om onbenullige wagwoorde soos "abc123" (deur statistieke Google 23% van Amerikaners gebruik soortgelyke wagwoorde), of wanneer dieselfde wagwoord op verskeie werwe gebruik word.

Om vertroulikheid te handhaaf, wanneer toegang tot 'n eksterne API verkry word, word slegs die eerste twee grepe van die hash van die login en wagwoord versend (die hashing-algoritme word gebruik Argon 2). Die volledige hash word geïnkripteer met 'n sleutel wat aan die gebruiker se kant gegenereer word. Die oorspronklike hashes in die Google-databasis word ook addisioneel geïnkripteer en slegs die eerste twee grepe van die hash word oorgebly vir indeksering. Die finale verifikasie van hashes wat onder die versende twee-grepe voorvoegsel val, word aan die gebruiker se kant uitgevoer met behulp van kriptografiese tegnologie "blindheid“, waarin nie een van die partye weet wat die inhoud is van die data wat nagegaan word nie. Om te beskerm teen die inhoud van 'n databasis van gekompromitteerde rekeninge wat deur brute geweld bepaal word met 'n versoek vir arbitrêre voorvoegsels, word die oorgedrade data geïnkripteer in verband met 'n sleutel wat gegenereer word op grond van 'n geverifieerde kombinasie van aanmelding en wagwoord.

Bron: opennet.ru

Voeg 'n opmerking