SÉRÉSEK, FOLTOK, SZIVÁRGÁSOK ÉS CÍPÍTÉSEK
Legújabb epizód – hallgasd meg most.
Kattintson és húzza az alábbi hanghullámokat, hogy bármelyik pontra ugorjon. Te is hallgatni közvetlenül a Soundcloudon.
Doug Aamoth-tal és Paul Ducklinnal
Intro és outro zene szerzője Edith Mudge.
Tovább hallgathatsz minket Soundcloudon, Apple Podcastok, Google Podcastok, Spotify, Fűzőgép és bárhol, ahol jó podcastok találhatók. Vagy csak dobd le a RSS hírfolyamunk URL-je a kedvenc podcatcheredbe.
OLVASSA EL AZ ÍRÁST
DOUG. Szabálysértések, jogsértések, javítások és elírások.
Mindez, és még sok más, a Naked Security podcastban.
[ZENEI MODEM]
Üdvözlünk mindenkit a podcastban.
Doug Aamoth vagyok; ő Daul Pucklin…
…Sajnálom, Paul!
KACSA. Azt hiszem, sikerült megoldanom, Doug.
A „Typios” egy hang elírás.
DOUG. Pontosan!
KACSA. Igen… jól sikerült, az az ember!
DOUG. Szóval, mi közük van a gépelési hibáknak a kiberbiztonsághoz?
Ebbe belemegyünk…
De először – szeretjük a sajátunkkal kezdeni Ezen a héten a technikatörténetben szegmensben.
Ezen a héten, 23. január 1996-án a Java Development Kit 1.0-s verziója ezt mondta: „Hello, world.
"
Mantrája, az „Írj egyszer, fuss bárhol”, és a megjelenése éppen akkor, amikor a web népszerűsége valóban lázba lépett, kiváló platformmá tette a webalapú alkalmazások számára.
Gyorsan előre a mai napra, és a 19-es verziónál tartunk, Paul.
KACSA. Mi vagyunk!
Java, mi?
Vagy „tölgy”.
Azt hiszem, ez volt az eredeti neve, mert annak, aki feltalálta a nyelvet, egy tölgyfa nőtt az irodája előtt.
Használjuk ki az alkalmat, Doug, hogy egyszer s mindenkorra tisztázzuk a zavar hogy sok embernek a Java és a JavaScript között van.
DOUG. Óóóóó…
KACSA. Sokan azt hiszik, hogy rokonok.
Nem rokonok, Doug.
*Pontosan ugyanazok* – az egyik csak a lerövidítés… NEM, TELJESEN KIVICSÉLEK!
DOUG. Azt kérdeztem: "Hova megy ez?" [NEvet]
KACSA. A JavaScript alapvetően azért kapta ezt a nevet, mert a Java szó klassz volt…
…és a programozók kávén dolgoznak, akár Java vagy JavaScript nyelven programoznak.
DOUG. Rendben, nagyon jó.
Köszönöm, hogy tisztáztad.
A dolgok tisztázásával kapcsolatban pedig a GoTo, az olyan termékek mögött álló cég, mint a GoToMyPC, GoToWebinar, LogMeIn és mások (köhögés, köhögés) azt mondja, hogy „szokatlan tevékenységet észleltek fejlesztői környezetünkben és harmadik féltől származó felhőalapú tárolási szolgáltatásunkban”.
Paul, mit tudunk?
GoTo elismeri: Az ügyfelek felhőalapú biztonsági másolatait a visszafejtő kulccsal együtt ellopták
KACSA. Ez még 2022 novemberének utolsó napján volt.
A korábban említett (köhögés, köhögés) pedig természetesen a GoTo leányvállalata/leányvállalata, vagy a csoportjukhoz tartozó cég, a LastPass.
Természetesen a karácsony nagy története az volt LastPass megsértése.
Nos, ez a jogsértés másnak tűnik, mint amit Goto most kiadott és elmondott.
Elismerik, hogy a felhőszolgáltatás, amely végül feltört, ugyanaz, amelyet a LastPass is megosztott.
De a feltört cuccok – legalábbis abból, ahogyan írták – másképp hangzanak.
És egészen ezen a héten – csaknem két hónappal később – kellett ahhoz, hogy a GoTo értékelje, hogy mit talált.
És a hír egyáltalán nem jó, Doug.
Mert rengeteg termék… Felolvasom őket: Central, Pro, join.me, Hamachi és RemotelyAnywhere.
Az összes ilyen termék esetében ellopták az ügyféladatok titkosított biztonsági másolatait, beleértve a fiókadatokat is.
És sajnos legalább néhány biztonsági másolat visszafejtési kulcsát ellopták velük.
Tehát ez azt jelenti, hogy lényegében *nem* titkosítva vannak, miután a szélhámosok kezében vannak.
És volt még két másik termék, a Rescue és a GoToMyPC, ahol az úgynevezett „MFA beállításokat” ellopták, de még titkosítva sem.
Tehát mindkét esetben nyilvánvalóan hiányoznak a kivonatolt jelszavak, és megvannak ezek a titokzatos „MFA (multifactor authentication)” beállításaink.
Tekintettel arra, hogy ezek fiókhoz kapcsolódó adatoknak tűnnek, nem világos, hogy mik ezek az „MFA-beállítások”, és kár, hogy a GoTo egy kicsit sem volt egyértelműbb.
És az égető kérdésem…
.. ezek a beállítások tartalmaznak olyan dolgokat, mint például a telefonszám, amelyre az SMS 2FA kódokat küldhetik?
A kezdő mag az alkalmazásalapú 2FA kódokhoz?
És/vagy azok a biztonsági kódok, amelyekből számos szolgáltatás létrehozhat néhányat, arra az esetre, ha elveszítené a telefonját vagy a telefonját SIM-et cserélnek?
Börtönbe küldték a SIM-cserélőt 2 millió dollár feletti kriptovaluta-rablás miatt
DOUG. Ó, igen – jó pont!
KACSA. Vagy a hitelesítő program meghibásodik.
DOUG. Igen.
KACSA. Tehát, ha ezek valamelyike, az nagy baj lehet.
Reméljük, ezek nem az „MFA-beállítások” voltak…
…de a részletek elhagyása azt jelenti, hogy valószínűleg érdemes feltételezni, hogy az ellopott adatok között voltak, vagy lehettek.
DOUG. És ha már az esetleges kihagyásokról beszélünk, megvan a szükséges követelmény: „A jelszavai kiszivárogtak. De ne aggódj, megsózták és kimosták."
De nem az összes sózás-kivonat-nyújtás ugyanaz, ugye?
Komoly biztonság: Hogyan tárolhatja biztonságosan felhasználói jelszavait
KACSA. Hát nem említették a nyújtó részt!
Itt nem csak egyszer kell kivonatolni a jelszót.
Nem is tudom... 100,100 5000-szor, 50-szer, XNUMX-szer vagy milliószor, csak hogy egy kicsit megnehezítse a szélhámosok dolgát.
És ahogy mondod… igen., nem minden sózás és kivonat egyenlő.
Azt hiszem, a közelmúltban beszélt a podcastban egy olyan incidensről, amikor néhány kivont jelszót loptak el, és kiderült, hogy a só egy kétjegyű kód, „00” és „99” között!
Tehát 100 különböző szivárványasztalra van minden, amire szüksége van…
…nagy kérdés, de megoldható.
És ahol a hash az MD5 *egy köre* volt, amit másodpercenként több milliárd kivonattal megtehetsz, még szerény berendezéseken is.
Szóval, félretéve, ha szerencsétlenül saját maga is elszenved egy ilyen jellegű jogsértést, amikor elveszíti az ügyfelek kivonatolt jelszavát, azt javaslom, tegyen meg mindent annak érdekében, hogy meghatározza, milyen algoritmust és paramétereket állít be. használják.
Mert egy kicsit megnyugtatja a felhasználókat, hogy mennyi ideig tarthat a szélhámosoknak a feltörés, és ezért milyen őrülten kell minden jelszavát megváltoztatni!
DOUG. Rendben.
Természetesen van néhány tanácsunk, kezdve: Módosítsa az összes olyan jelszót, amely a korábban említett szolgáltatásokhoz kapcsolódik.
KACSA. Igen, ezt meg kell tennie.
Általában ezt javasoljuk kivonatolt jelszavak ellopásakor, még akkor is, ha azok rendkívül erősen kivonatolva vannak.
DOUG. OK.
És nekünk van: Állítsa vissza a fiókjaiban használt alkalmazásalapú 2FA kódsorozatokat.
KACSA. Igen, szerintem te is megteheted.
DOUG. OK.
És nekünk van: Új biztonsági kódok generálása.
KACSA. Ha a legtöbb szolgáltatásnál ezt teszi, és a biztonsági kódok szolgáltatást jelentenek, akkor a rendszer automatikusan kidobja a régieket, és az újak teljesen lecserélik őket.
DOUG. És végül, de nem utolsósorban: Ha teheti, fontolja meg az alkalmazásalapú 2FA kódokra való váltást.
KACSA. Az SMS kódok előnye, hogy nincs közös titok; nincs mag.
Ez csak egy valóban véletlen szám, amelyet a másik vég minden alkalommal generál.
Ez a jó az SMS-alapú dolgokban.
Mint mondtuk, a rossz dolog a SIM-csere.
És ha módosítania kell akár az alkalmazásalapú kódsorozatot, akár az SMS-kódok helyét…
…sokkal, de sokkal egyszerűbb elindítani egy új 2FA alkalmazássorozatot, mint megváltoztatni a mobiltelefonszámát! [NEvet]
DOUG. OK.
És ahogy már többször mondtam (lehet, hogy ezt valahol a mellkasomra tetoválják), figyelni fogjuk ezt.
De egyelőre van egy szivárgó T-Mobile API-nk, amely felelős a…
(Hadd nézzem meg a jegyzeteimet itt: [HANGOS KI-MIKOR] HARMANDORHÉT MILLIÓ!?!??!)
...37 millió ügyfél nyilvántartás:
A T-Mobile elismerte, hogy 37,000,000 XNUMX XNUMX ügyfélrekordot loptak el „rossz színész”
KACSA. Igen.
Ez egy kicsit bosszantó, nem? [NEVETÉS]
Mert a 37 millió hihetetlenül nagy szám… és ironikus módon 2022 után jön, amikor a T-Mobile fizetett 500 millió $ a T-Mobile-t 2021-ben elszenvedett adatvédelmi incidenssel kapcsolatos kérdések rendezésére.
Nos, a jó hír, ha lehet annak nevezni, hogy legutóbb a feltört adatok közé tartoztak a társadalombiztosítási számok [SSN-ek] és a jogosítványok adatai.
Szóval ezt nevezhetjük „kiváló minőségű” személyazonosság-lopásnak.
Ezúttal a jogsértés nagy, de úgy tudom, hogy alapvető elektronikus kapcsolattartási adatokról van szó, beleértve a telefonszámát és a születési dátumot.
Ez bizonyos mértékben segít a csalóknak a személyazonosság-lopásban, de közel sem olyan messzire, mint egy SSN vagy egy beszkennelt fénykép a vezetői engedélyéről.
DOUG. Rendben, van néhány tippünk, ha ez érinti Önt, kezdve: Ne kattintson az e-mailekben vagy más üzenetekben található „hasznos” linkekre.
Fel kell tételeznem, hogy rengeteg spam és adathalász e-mail fog keletkezni ebből az incidensből.
KACSA. Ha elkerüli a linkeket, ahogy mindig mondjuk, és megtalálja a saját útját oda, akkor akár legitim e-mailről van szó, akár nem, valódi vagy hamis hivatkozással…
…ha nem kattintasz a jó linkekre, akkor a rossz linkekre sem kattintasz!
DOUG. És ez szépen illeszkedik a második tippünkhöz: Gondolkozz, mielőtt kattintasz.
És akkor természetesen az utolsó tippünk: Jelentse a gyanús e-maileket munkahelyi informatikai csapatának.
KACSA. Amikor a csalók adathalász támadásba kezdenek, a csalók általában nem küldik el egy személynek a vállalaton belül.
Tehát, ha az első személy, aki meglát egy adathalászat a társaságában, riaszt, akkor legalább van esélye figyelmeztetni a többi 49-et!
DOUG. Kiváló.
Nos, az iOS 12 felhasználóinak… ha úgy érzi, hogy kimaradt a legutóbbi nulladik napi javításokból, tegye van egy történetünk ma neked!
Megjelentek az Apple javításai – a régi iPhone-ok végre régi nulladik napi javítást kapnak!
KACSA. Megvan, Doug!
Nagyon boldog vagyok, mert mindenki tudja, hogy szeretem a régi iOS 12-es telefonomat.
Kiváló időket éltünk át, és hosszú és szupermenő kerékpározást tettünk együtt, amíg… [NEVETÉS]
…a végzetes, ahol elég jól megsérültem ahhoz, hogy felépüljek, a telefon pedig olyan jól megsérült, hogy már alig látni a képernyő repedésein, de így is működik!
Imádom, ha frissítést kap!
DOUG. Azt hiszem, ekkor tanultam meg a szót nagy tett.
KACSA. [SZÜNET] Mi?!
Ez egy szót sem neked?
DOUG. Nem!
KACSA. Azt hiszem, a Királyi Légierőtől származik a második világháborúban… ez egy „repülőgép lezuhanása” volt.
Szóval van egy zsong, majd jóval egy dörgés felett jön a nagy tett, bár mindkettőnek ugyanaz a hangja.
DOUG. Oké, van.
KACSA. Meglepetés, meglepetés – miután hosszú évek óta nem volt iOS 12-frissítés, az elromlott telefon frissítést kapott…
…egy nulladik napi hibára, amely a titokzatos hiba volt, amelyet valamikor korábban csak az iOS 16-ban javítottak ki… [SUTTOGÁS] nagyon titokban az Apple-től, ha emlékszel rá.
DOUG. Ó, erre emlékszem!
Az Apple kiadta az iOS biztonsági frissítését, amely minden eddiginél szűkszavúbb
KACSA. Volt ez az iOS 16-os frissítés, majd valamivel később frissítések jelentek meg az összes többi Apple platformok, beleértve az iOS 15-öt.
És az Apple azt mondta: „Ó, igen, valójában, most belegondolunk, ez egy nulladik nap volt. Most utánajártunk, bár az iOS 16 frissítését sietve kiadtuk, és nem tettünk semmit az iOS 15 esetében, kiderült, hogy a hiba csak az iOS 15 és korábbi verziókra vonatkozik.” [NEvet]
Az Apple mindent foltoz, végre felfedi az iOS 16.1.2 rejtélyét
Szóval, hú, milyen furcsa rejtély volt!
De legalább mindent befoltoztak a végén.
Most kiderült, hogy a régi nulladik napot az iOS 12 javította.
És ez a WebKit azon nulladik napjai közé tartozik, amely úgy hangzik, mintha a vadonban rosszindulatú programok beültetésére használnák.
És ennek, mint mindig, valami spyware szaga van.
Mellesleg, ez volt az egyetlen olyan hiba, amelyet az iOS 12-ben javítottak – csak az a 0 nap.
A többi platform rengeteg javítást kapott.
Szerencsére úgy tűnik, ezek mind proaktívak; egyiket sem sorolja fel az Apple „aktívan kihasználtként”.
[SZÜNET]
Rendben, térjünk át valami rendkívül izgalmasra, Doug!
Azt hiszem, a „typios”-ban vagyunk, nem?
DOUG. Igen!
A kérdés Felteszem magamnak a kérdést… [IRONIKUS] Nem emlékszem, meddig, és biztos vagyok benne, hogy mások is azt kérdezik: „Hogyan javíthatják a szándékos elírások a DNS biztonságát?”
Komoly biztonság: Hogyan javíthatják a KIFEJEZETT TYPOS-ok a DNS biztonságát
KACSA. [NEvet]
Érdekes módon ez egy olyan ötlet, amely először 2008-ban merült fel, körülbelül akkoriban, amikor a késői Dan Kaminsky, aki akkoriban jól ismert biztonságkutató volt, rájött, hogy a DNS-kiszolgálókkal kapcsolatban jelentős „válaszkitalálási” kockázatok rejlenek, amelyeket talán sokkal könnyebb volt kihasználni, mint azt az emberek gondolták.
Ahol egyszerűen csak a DNS-kiszolgálókra bökdösöd a válaszokat, remélve, hogy azok véletlenül megfelelnek egy olyan kimenő kérésnek, amelyre még nem érkezett hivatalos válasz.
Csak azt gondolja: „Nos, biztos vagyok benne, hogy valakit a hálózatában érdekelt a tartomány naksec.test
csak most. Hadd küldjem vissza egy csomó választ, mondván: „Hé, ezt kérdezted naksec.test
; itt van"…
…és küldenek egy teljesen fiktív szerver [IP] számot.
Ez azt jelenti, hogy az én szerveremre jössz, ahelyett, hogy a valódi üzletre mennél, tehát alapvetően feltörtem a szerveredet anélkül, hogy a szervered közelébe mentem volna!
És azt gondolod: „Nos, hogyan tudsz egyszerűen *bármilyen* választ küldeni? Biztosan van valami mágikus kriptográfiai cookie a kimenő DNS-kérésben?”
Ez azt jelenti, hogy a szerver észrevehette, hogy a következő választ csak valaki találta ki.
Nos, az ember ezt gondolná… de ne feledje, hogy a DNS először látott napvilágot 1987, Doug.
És nemhogy a biztonság nem volt akkora probléma, de a napi hálózati sávszélesség miatt nem is volt hely elég hosszú ideig tartó kriptográfiai cookie-knak.
Tehát DNS kérések, ha megy RFC 1035, egyedi azonosító szám védi (lazán szólva Doug), amelyet remélhetőleg véletlenszerűen generál a kérés küldője.
Találd ki, milyen hosszúak, Doug…
DOUG. Nem elég hosszú?
KACSA. 16 bit.
DOUG. Ohhhhhhh.
KACSA. Ez elég rövid… elég rövid volt, még 1987-ben is!
De a 16 bit *két egész bájt*.
Jellemzően az entrópia mennyisége, ahogy a szakzsargon mondja, ami egy DNS-kérésben lenne (más cookie-adatok hozzáadása nélkül – alapvető, eredeti stílusú, régi iskola DNS-kérés)…
…van egy 16 bites UDP forrás portszáma (bár nem használhatja mind a 16 bitet, ezért nevezzük 15 bitesnek).
És megvan az a 16 bites, véletlenszerűen kiválasztott azonosítószám… remélhetőleg a szervere véletlenszerűen választ, és nem használ kitalálható sorrendet.
Tehát 31 bites véletlenséged van.
És bár 231 [valamivel több mint 2 milliárd] egy csomó különböző kérés, amelyet el kell küldenie, ez manapság korántsem szokatlan.
Még az ősi laptopomon, Doug-on is 2-t küld16 [65,536 XNUMX] különböző UDP kérések egy DNS-kiszolgálóhoz szinte mérhetetlenül rövid ideig tartanak.
Tehát a 16 bit szinte azonnali, a 31 bit pedig megvalósítható.
Tehát az ötlet még 2008-ban az volt…
Mi lenne, ha a keresett domain nevet vesszük, mondjuk naksec.test
, és ahelyett, hogy azt tenné, amit a legtöbb DNS-feloldó csinál, és azt mondaná: „Utána akarok nézni n-a-k-s-e-c dot t-e-s-t
”, csupa kisbetűvel, mert a kisbetűk jól néznek ki (vagy, ha régimódiak szeretnél lenni, akkor NAGYBETŰVEL, mert a DNS nem tesz különbséget a kis- és nagybetűk között, emlékszel)?
Mi van, ha felnézünk nAKseC.tESt
, véletlenszerűen kiválasztott kisbetűs, NAGYBETŐS, NAGYBETŰS, kisbetűs stb. sorozattal, és emlékszünk, hogy milyen sorrendet használtunk, és várjuk, hogy visszajön a válasz?
Mivel a DNS-válaszok kötelezően tartalmazzák az eredeti kérés másolatát.
Mi van, ha a kérésben szereplő adatok egy részét egyfajta „titkos jelzésként” használhatjuk?
Az eset összekeverésével a csalóknak ki kell találniuk az UDP forrásportot; ki kell találniuk azt a 16 bites azonosító számot a válaszban; *és* ki kell találniuk, hogyan választottuk a miS-sPEll-t nAKsEc.TeST
.
És ha a három dolog közül bármelyiket elhibázzák, a támadás meghiúsul.
DOUG. Wow, rendben!
KACSA. És a Google úgy döntött: "Hé, próbáljuk meg ezt."
Az egyetlen probléma az, hogy a nagyon rövid domain nevekkel (így menők, könnyen írhatók és könnyen megjegyezhetőek), mint például a Twitter t.co
, csak három olyan karaktert kap, amelyek kis- és nagybetűjét megváltoztathatják.
Ez nem mindig segít, de lazán szólva minél hosszabb a domain neve, annál nagyobb biztonságban lesz! [NEvet]
És azt hittem, ez egy jó kis történet…
DOUG. Ahogy a nap kezd lenyugodni a mai műsorunkban, van egy olvasói megjegyzésünk.
Ez a megjegyzés a múlt heti podcast nyomán jött, S3 Ep118.
S3 Ep118: Találd ki a jelszavad? Nem kell, ha már ellopták! [Hang + szöveg]
István olvasó azt írja… lényegében azt mondja:
Mostanában sokat hallottam, hogy beszéltek a jelszókezelőkről – úgy döntöttem, hogy kiírom a sajátomat.
Én generálom ezeket a biztonságos jelszavakat; Tárolhatnám őket memóriakártyán vagy pendrive-on, csak akkor csatlakoztathatom a pendrive-ot, ha ki kell húznom és jelszót kell használnom.
A bot megközelítés ésszerűen alacsony kockázatot jelentene?
Azt hiszem, megismerkedhetek titkosítási technikákkal, amelyek segítségével kódolhatok és dekódolhatnának információk a pálcán, de nem tehetek róla, hogy ez messze túlmutat azon az egyszerű megközelítésen, amelyet keresek.
Szóval mit szólsz, Paul?
KACSA. Nos, ha ez messze túlmutat az „egyszerű” megközelítésen, akkor ez azt jelenti, hogy bonyolult lesz.
És ha bonyolult, akkor ez egy nagyszerű tanulási gyakorlat…
…de lehet, hogy nem a jelszavas titkosítás az a dolog, ahol ezeket a kísérleteket szeretné elvégezni. [NEVETÉS]
DOUG. Azt hiszem, hallottam már, hogy ezt mondtad erről a programról több alkalommal is: „Nem kell saját titkosítást görgetni; Számos jó titkosítási könyvtár létezik, amelyeket kihasználhat."
KACSA. Igen… ne köss, horgolj, tűszúrj vagy ne varrj saját titkosítást, ha csak tudsz segíteni!
A probléma, amit Stephen próbál megoldani, a következő: „Szeretnék egy cserélhető USB-meghajtót kijelölni, hogy jelszavak legyenek rajta – hogyan tudom kényelmesen titkosítani a meghajtót?”
És azt javaslom, hogy valami olyasmit válassz, ami teljes eszköz titkosítást végez [FDE] *az operációs rendszeren belül*.
Így lesz egy dedikált USB-meghajtó; bedugod, és az operációs rendszer azt mondja: „Ez kódolt – szükségem van a jelszóra.”
Az operációs rendszer pedig a teljes meghajtó visszafejtésével foglalkozik.
Mostantól lehetnek titkosított *fájlok* a titkosított *eszközben*, de ez azt jelenti, hogy ha elveszíti az eszközt, az egész lemez, amíg le van szerelve és le van húzva a számítógépről, felaprított káposzta.
És ahelyett, hogy saját eszközillesztőt próbálna összehozni ehhez, miért ne használna az operációs rendszerbe beépített illesztőprogramot?
Ez az én ajánlásom.
És ez az a pont, ahol egyszerre válik könnyűvé és kissé bonyolulttá.
Ha Linuxot futtatsz, akkor használd luxus [Linux Unified Key Setup].
Mac gépeken ez nagyon egyszerű: van egy technológiája, az úgynevezett FileVault ami be van építve a Macbe.
Windows rendszeren a FileVault vagy a LUKS megfelelője kerül hívásra BitLocker; valószínűleg hallottál már róla.
A probléma az, hogy ha a Windows valamelyik Home verziójával rendelkezik, akkor nem tudja végrehajtani ezt a teljes lemezes titkosítási réteget a cserélhető meghajtókon.
Ki kell költenie a pluszt a Pro verzió vagy az üzleti típusú Windows beszerzésére, hogy használni tudja a BitLocker teljes lemezes titkosítását.
Szerintem ez kár.
Szeretném, ha a Microsoft csak annyit mondana: „Arra bátorítjuk, hogy ott és ahol csak tudja – minden eszközén használja, ha akarja.”
Mert ha a legtöbben nem is, legalább néhányan megteszik.
Szóval ez a tanácsom.
A kiugró tény az, hogy ha Windows rendszered van, és vettél egy laptopot, mondjuk egy háztartási boltban a Home verzióval, akkor egy kis plusz pénzt kell költened.
Mert nyilvánvalóan a cserélhető meghajtók titkosítása, ha Ön Microsoft-ügyfél, nem elég fontos ahhoz, hogy az operációs rendszer Home verziójába beépüljön.
DOUG. Rendben, nagyon jó.
Köszönöm, István, hogy elküldted.
Ha van egy érdekes története, megjegyzése vagy kérdése, amelyet fel szeretne tenni, azt szívesen olvassuk a podcastban.
Írhat e-mailt a tips@sophos.com címre, kommentálhatja bármelyik cikkünket, vagy felkereshet minket a közösségi oldalon: @NakedSecurity.
Ez a mai műsorunk – nagyon köszönjük, hogy meghallgatott.
Paul Ducklin számára én Doug Aamoth vagyok, és emlékeztetlek benneteket a következő alkalomig, hogy…
MINDKÉT. Maradjon biztonságban!
[ZENEI MODEM]
- SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
- Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
- Forrás: https://nakedsecurity.sophos.com/2023/01/26/s3-ep119-breaches-patches-leaks-and-tweaks-audio-text/
- 000
- 1
- 100
- 1996
- 2021
- 2022
- 2FA
- a
- Képes
- Rólunk
- erről
- felett
- Fiók
- Fiókok
- tevékenység
- tulajdonképpen
- hozzáadott
- beismerni
- Előny
- tanács
- Után
- Korosztály
- AIR
- Légierő
- riasztás
- algoritmus
- Minden termék
- Rendben
- Bár
- mindig
- között
- összeg
- Ősi
- és a
- válasz
- bárhol
- api
- app
- Apple
- megközelítés
- alkalmazások
- körül
- cikkek
- értékelés
- támadás
- Támadások
- hang-
- Hitelesítés
- szerző
- automatikusan
- vissza
- mentés
- mentések
- Rossz
- Sávszélesség
- alapvető
- Alapvetően
- mert
- válik
- előtt
- mögött
- hogy
- Hisz
- lent
- között
- Túl
- Nagy
- Billió
- milliárd
- Bit
- megvett
- megsértése
- megsértésének
- Bogár
- épít
- épült
- hívás
- hívott
- eset
- esetek
- központi
- biztosan
- esély
- változik
- változó
- karakter
- ellenőrizze
- választotta
- választott
- Karácsony
- világos
- Klíring
- felhő
- felhő tárolási
- kód
- Kávé
- COM
- hogyan
- kényelem
- megjegyzés
- vállalat
- teljesen
- bonyolult
- számítógép
- Csatlakozó
- fogyasztó
- kapcsolat
- Kényelmes
- keksz
- Hűvös
- tudott
- Tanfolyam
- Összeomlik
- teremt
- cryptocurrency
- kriptográfiai
- vevő
- Kiberbiztonság
- dátum
- adatok megsértése
- találka
- nap
- Nap
- üzlet
- Ajánlatok
- határozott
- elszánt
- elszánt
- végleges
- részletek
- Fejlesztés
- eszköz
- Eszközök
- különböző
- dns
- Nem
- Ennek
- domain
- Domain név
- DOMAIN NEVEK
- ne
- DOT
- hajtás
- gépkocsivezető
- vezetés
- Csepp
- minden
- Korábban
- könnyebb
- bármelyik
- Elektronikus
- e-mailek
- ösztönzése
- titkosított
- titkosítás
- elég
- Egész
- teljesen
- Környezet
- felszerelés
- Egyenértékű
- lényegében
- Még
- EVER
- mindenki
- minden
- kiváló
- Exploit
- Hasznosított
- külön-
- kivonat
- szem
- nem sikerül
- meglehetősen
- ismerős
- Funkció
- kevés
- mintás
- Végül
- Találjon
- vezetéknév
- Rögzít
- rögzített
- Kényszer
- talált
- ból ből
- általában
- generál
- generált
- generál
- kap
- Ad
- adott
- Go
- Goes
- megy
- jó
- Menj
- nagy
- Csoport
- Növekvő
- csapkodott
- kezek
- történik
- megtörténik
- boldog
- hash
- hash
- tekintettel
- hallott
- hallás
- rablás
- segít
- segít
- itt
- Találat
- Kezdőlap
- remény
- remélhetőleg
- remélve
- Hogyan
- How To
- HTTPS
- BETEG
- ötlet
- Azonosítás
- Identitás
- fontos
- javul
- in
- incidens
- tartalmaz
- beleértve
- Beleértve
- hihetetlenül
- információ
- helyette
- érdekelt
- érdekes
- Feltalált
- iOS
- IP
- Ironikusan
- kérdés
- kérdések
- IT
- január
- zsargon
- Jáva
- JavaScript
- csatlakozik
- Tart
- Kulcs
- Kedves
- kötött
- Ismer
- nyelv
- hordozható számítógép
- nagy
- keresztnév
- LastPass
- Késő
- réteg
- Szivárgás
- tanult
- tanulás
- Tőkeáttétel
- könyvtárak
- Engedély
- fény
- LINK
- linkek
- linux
- Listázott
- Kihallgatás
- kis
- kiszámításának
- terhelések
- Hosszú
- hosszabb
- néz
- nézett
- keres
- MEGJELENÉS
- veszít
- Sok
- szerelem
- Elő/Utó
- esőkabát
- készült
- mágia
- csinál
- Gyártás
- malware
- Menedzserek
- Mantra
- sok
- Mérkőzés
- MD5
- eszközök
- Memory design
- említett
- üzenetek
- microsoft
- esetleg
- millió
- hiányzó
- Mobil
- mobiltelefon
- pénz
- hónap
- több
- a legtöbb
- mozog
- többtényezős hitelesítés
- zene
- zenei
- titokzatos
- Rejtély
- Meztelen biztonság
- Meztelen biztonsági podcast
- név
- nevek
- Közel
- közel
- Szükség
- hálózat
- Új
- hír
- következő
- rendszerint
- Megjegyzések
- november
- szám
- számok
- tölgy
- Office
- hivatalos
- Régi
- ONE
- üzemeltetési
- operációs rendszer
- Alkalom
- érdekében
- rendes
- eredeti
- Más
- Egyéb
- kívül
- saját
- fizetett
- paraméter
- rész
- párt
- Jelszó
- jelszavak
- Patches
- Paul
- Emberek (People)
- talán
- időszak
- person
- adathalászat
- Adathalászat
- adathalász támadások
- telefon
- Hangmagasság
- emelvény
- Platformok
- Plató
- Platón adatintelligencia
- PlatoData
- podcast
- Podcastek
- pont
- Bök
- népszerűség
- lehetséges
- Hozzászólások
- börtön
- per
- proaktív
- valószínűleg
- Probléma
- Termékek
- Program
- program
- programozók
- Programozás
- védett
- kérdés
- emel
- véletlen
- véletlenszerűen generált
- véletlenszerűség
- Olvass
- Olvasó
- igazi
- valódi üzlet
- új
- nemrég
- ajánl
- Ajánlást
- nyilvántartások
- Meggyógyul
- összefüggő
- engedje
- eszébe jut
- TÖBBSZÖR
- cserélni
- válasz
- kérni
- kéri
- szükséges
- mentés
- kutató
- felelős
- felfedi
- Kockázat
- kockázatok
- Tekercs
- Szoba
- királyi
- rss
- futás
- futás
- biztonságosabb
- Mondott
- só
- azonos
- Képernyő
- Második
- Titkos
- biztonság
- biztonság
- mag
- keres
- Úgy tűnik,
- lát
- részes
- elküldés
- Sorozat
- Szerverek
- szolgáltatás
- Szolgáltatások
- készlet
- beállítások
- felépítés
- számos
- megosztott
- rövid
- kellene
- előadás
- jelentős
- Egyszerű
- egyszerűen
- SMS
- So
- Közösség
- SOLVE
- néhány
- Valaki
- valami
- valahol
- hang
- forrás
- spam
- beszélő
- költ
- Spotify
- spyware
- kezdet
- Kezdve
- tartózkodás
- István
- Még mindig
- lopott
- tárolás
- tárolni
- Történet
- tárgy
- beküldése
- későbbi
- ilyen
- nap
- biztosan
- meglepetés
- gyanús
- rendszer
- T-Mobile
- Vesz
- tart
- Beszél
- csapat
- tech
- technikák
- Technológia
- A
- lopás
- azok
- ebből adódóan
- dolog
- dolgok
- Harmadik
- ezen a héten
- gondoltam
- három
- Keresztül
- idő
- alkalommal
- típus
- tippek
- nak nek
- Ma
- együtt
- felé
- baj
- Fordult
- Végül
- megértés
- szerencsétlen
- egységes
- egyedi
- unplugged
- Frissítések
- Frissítés
- URL
- us
- usb
- használ
- Felhasználók
- változat
- várjon
- figyelmeztetés
- web-alapú
- webkészlet
- hét
- jól ismert
- Mit
- vajon
- ami
- míg
- Suttogás
- WHO
- Wikipedia
- Vadon
- lesz
- ablakok
- belül
- nélkül
- szó
- Munka
- dolgozott
- világ
- érdemes
- lenne
- ír
- Rossz
- év
- te
- A te
- magad
- zephyrnet
- nulladik napi hiba