![\"Hakerzy](\"https:\/\/www.europesays.com\/pl\/wp-content\/uploads\/2026\/05\/mercor-2.jpg\")
<\/a> ![\"PESEL](\"https:\/\/www.europesays.com\/pl\/wp-content\/uploads\/2026\/01\/mobywatel-asystent-1.jpg\")
<\/a> To nie magia <\/p>\nSamo istnienie czytelnych hase\u0142 w pami\u0119ci procesu nie oznacza, \u017ce ktokolwiek za chwil\u0119 w\u0142amie si\u0119 do Twojego komputera i wyci\u0105gnie sobie Twoje dane logowania: to tak nie dzia\u0142a. Scenariusz wymaga bezpo\u015bredniego dost\u0119pu do maszyny, uprawnie\u0144 pozwalaj\u0105cych zagl\u0105da\u0107 do pami\u0119ci procesu lub przynajmniej z\u0142o\u015bliwego oprogramowania dzia\u0142aj\u0105cego w odpowiednich warunkach. Nie jest to podatno\u015b\u0107 zdalna w klasycznym tego typu zagro\u017cenia, sensie.\u00a0<\/p>\n
Gorzej jednak jest ze wsp\u00f3\u0142dzielonymi komputerami, \u015brodowiskami firmowymi i systemami, na kt\u00f3rych administrator lub cho\u0107by przej\u0119te konto, ma szeroki dost\u0119p do proces\u00f3w innych u\u017cytkownik\u00f3w. Za\u0142\u00f3\u017cmy, \u017ce atakuj\u0105cy mo\u017ce wykona\u0107 zrzut pami\u0119ci dzia\u0142aj\u0105cego Edge\u2019a: wtedy ju\u017c, obecno\u015b\u0107 ca\u0142ego zestawu hase\u0142 w RAM-ie (i to w plaintek\u015bcie) zwi\u0119ksza warto\u015b\u0107 takiego zrzutu. Badacz wskazuje, \u017ce problem dotyczy procesu nadrz\u0119dnego Edge\u2019a, kt\u00f3ry trzyma odszyfrowane po\u015bwiadczenia tak, jakby „nic si\u0119 nie sta\u0142o”.\n<\/p>\n
Chrome i Brave: jak jest tutaj? <\/p>\n
Edge nie jest przegl\u0105dark\u0105 budowan\u0105 od zera: korzysta bowiem z tego samego silnika co Google Chrome, Brave, Opera oraz Vivaldi, ale zachowanie mened\u017cera hase\u0142 cz\u0119sto zale\u017cy tutaj od sposobu implementacji rozwi\u0105zania. Wed\u0142ug R\u00f8nninga testowane alternatywy, w tym Chrome i Brave, nie przechowywa\u0142y ca\u0142ego zestawu zapisanych hase\u0142 w pami\u0119ci w ten sam spos\u00f3b. Chrome odszyfrowuje po\u015bwiadczenia punktowo tylko wtedy gdy s\u0105 potrzebne. Wygl\u0105da wi\u0119c na to, \u017ce inni producenci, ju\u017c na etapie projektowania mened\u017cer\u00f3w hase\u0142, zdawali sobie spraw\u0119 z ryzyka tego konkretnego momentu w pracy programu i odpowiednio si\u0119 zabezpieczyli.<\/p>\n
To wszystko nie znaczy jednak, \u017ce przegl\u0105darki s\u0105 idealnymi kontenerami na po\u015bwiadczenia. Has\u0142a zapisane w przegl\u0105darce zawsze s\u0105 pewnym kompromisem mi\u0119dzy wygod\u0105, synchronizacj\u0105 i bezpiecze\u0144stwem. Ka\u017cdy mechanizm autouzupe\u0142niania musi przecie\u017c w pewnym momencie odszyfrowa\u0107 dane, bo inaczej nie m\u00f3g\u0142by ich wrzuci\u0107 do formularzy. Co innego jednak, gdy odszyfrowuje si\u0119 jedno has\u0142o na \u017c\u0105danie u\u017cytkownika, a co innego, gdy has\u0142a w postaci odszyfrowanej siedz\u0105 w RAM-ie: i to wszystkie, jak jeden m\u0105\u017c.<\/p>\n
Microsoft m\u00f3wi: „to mia\u0142o tak dzia\u0142a\u0107” <\/p>\n
To nie jest \u017cart. Microsoft odpowiedzia\u0142 odkrywcy b\u0142\u0119du, \u017ce opisane zachowanie jest zgodne z projektem, a nie klasyfikowane jako b\u0142\u0105d bezpiecze\u0144stwa. Nie jest to co\u015b niespotykanego w \u015bwiecie cyberbezpiecze\u0144stwa: producent mo\u017ce uzna\u0107, \u017ce je\u015bli napastnik ma ju\u017c odpowiedni dost\u0119p do systemu, z\u0142ama\u0142 wiele warstw ochrony i dopiero wykorzysta\u0142 element projektowy konkretnego programu, to owo sporne zachowanie nie jest luk\u0105 per se.\u00a0<\/p>\n
Ja z tym, osobi\u015bcie, nie zgadzam si\u0119 kompletnie. Oprogramowanie warto jest budowa\u0107 tak, by nie stwarza\u0107 ryzyka dalszych szk\u00f3d: nawet, gdy mury zabezpiecze\u0144 wyst\u0119puj\u0105cych w danym scenariuszu nieco wcze\u015bniej, ju\u017c zosta\u0142y pokonane. Powiedzcie mi, po co mieliby\u015bmy u\u0142atwia\u0107 przest\u0119pcy wykradanie danych u\u017cytkownika: nawet, je\u017celi ten ju\u017c zyska\u0142 spore uprawnienia w systemie? Microsoft wykazuje si\u0119 tu niesamowit\u0105 indolencj\u0105: pytanie tylko, czy jest ona w tym konkretnym przypadku intencjonalna, czy nie: a mo\u017ce wynika z podej\u015bcia ska\u017conego przez twarde procedury. Jakiekolwiek nie by\u0142oby dla tego wyt\u0142umaczenie, to i tak wiadomo jedno: inni producenci pomy\u015bleli o zabezpieczeniu po\u015bwiadcze\u0144 przed tak\u0105 ingerencj\u0105. Dlaczego Microsoft uzna\u0142, \u017ce mo\u017ce by\u0107 pod tym wzgl\u0119dem gorszy?!<\/p>\n
Ta sytuacja uczy nas zasadniczo jednego: najbardziej newralgicznych hase\u0142 lepiej nie trzyma\u0107 wy\u0142\u0105cznie w przegl\u0105darce, szczeg\u00f3lnie na komputerze u\u017cywanym do pracy, w warunkach wsp\u00f3\u0142dzielenia maszyn. Zewn\u0119trzny mened\u017cer hase\u0142, zupe\u0142nie inne has\u0142o g\u0142\u00f3wne, kawalkada z\u0142o\u017cona z 2FA i passkey\u00f3w, biometryki, itp., zawsze b\u0119d\u0105 przydawa\u0107 Wam dodatkowe warstwy ochrony. I oczywi\u015bcie, nie ma zabezpiecze\u0144 „absolutnych” i nikt nie da Wam gwarancji, \u017ce i tak nie zostaniecie zaatakowani. Zawsze tak mo\u017ce si\u0119 zdarzy\u0107, ale to do Was nale\u017cy obowi\u0105zek, aby takowe ryzyko zminimalizowa\u0107.\u00a0<\/p>\n