S3 Ep95: aeglane leke, Githubi rünnak ja postkvantkrüpto [heli + tekst]

Klõpsake ja lohistage allolevatel helilainetel mis tahes punkti hüppamiseks. Sa saad ka kuula otse Soundcloudis.

DOUG.  Nõrgad lekked, ulakas GitHubi kood ja postkvantkrüptograafia.

Kõik see ja palju muud, Naked Security taskuhäälingusaates.

[MUUSIKAMODEEM]

Tere tulemast podcasti, kõik.

Mina olen Doug Aamoth.

Minuga, nagu alati, on Paul Ducklin.

Paul, kuidas sul täna läheb?

---

PART.  Super-duper, nagu tavaliselt, Doug!

---

DOUG.  Olen ülimalt põnevil, et jõuan selle nädalani Tehnika ajalugu segment, sest…

... sa olid seal, mees!

Sel nädalal, 11. augustil…

---

PART.  Oh ei!

Ma arvan, et peni on just langenud…

---

DOUG.  Ma ei pea isegi aastat ütlema!

11. august 2003 – maailm märkas ussi Blaster, mis mõjutas Windows 2000 ja Windows XP süsteeme.

Blaster, tuntud ka kui Lovesan ja MsBlast, kasutas puhvri ületäitumist ja on ehk kõige tuntum sõnumi poolest, „Billy Gates, miks sa selle võimalikuks teed? Lõpetage raha teenimine ja parandage oma tarkvara.

Mis juhtus, Paul?

---

PART.  Noh, see oli aeg varem, võib-olla võtsime turvalisust nii tõsiselt.

Ja õnneks oleks sellist viga tänapäeval palju-palju keerulisem ära kasutada: see oli pinupõhine puhvri ületäitumine.

Ja kui ma õigesti mäletan, ehitati Windowsi serveriversioone juba nn virna kaitse.

Teisisõnu, kui täidate funktsiooni sees oleva pinu üle, tuvastab see enne, kui funktsioon naaseb ja rikutud virnaga kahju teeb, et juhtus midagi halba.

Seega peab see rikkuva programmi sulgema, kuid pahavara ei saa käivitada.

Kuid see kaitse ei olnud sel ajal Windowsi kliendiversioonides.

Ja nagu ma mäletan, oli see üks neist varajasetest pahavaradest, mis pidi ära arvama, milline operatsioonisüsteemi versioon teil on.

Kas sul on 2000? Kas sa oled NT-s? Kas teil on XP?

Ja kui see läheb valesti, jookseb süsteemi oluline osa kokku ja saate hoiatuse „Teie süsteem sulgub”.

---

DOUG.  Hah, ma mäletan neid!

---

PART.  Niisiis, seal oli kaasne kahju, mis oli paljude inimeste jaoks märk sellest, et teid on tabanud nakkused…

…mis võib olla väljastpoolt, näiteks kui olete lihtsalt kodukasutaja ja teil pole kodus ruuterit ega tulemüüri.

Kuid kui viibisite ettevõttes, tuli kõige tõenäolisem rünnak kelleltki teiselt ettevõtte sees, paiskades teie võrku pakette.

Nii et sarnaselt CodeRedi rünnakule, millest me rääkisime, mis toimus paar aastat enne seda, oli hiljutises podcastis probleemiks selle asja ulatus, maht ja kiirus.

---

DOUG.  Hea küll, see oli umbes 20 aastat tagasi.

Ja kui me keerame kella tagasi viie aasta tagusesse aega, siis see on siis Slack hakkas lekkima räsitud paroolid. [NAER]

---

PART.  Jah, Slack, populaarne koostöötööriist…

…sellel on funktsioon, mille abil saate saata teistele inimestele teie tööruumiga liitumise kutselingi.

Ja kujutate ette: klõpsate nuppu, mis ütleb "Loo link" ja see loob mingi võrgupaketi, millel on tõenäoliselt mõni JSON.

Kui olete kunagi saanud Zoomi koosolekukutse, teate, et sellel on kuupäev ja kellaaeg, isik, kes teid kutsub, ja URL, mida saate koosoleku jaoks kasutada, ja pääsukood ja kõik muu. asjad – seal on päris palju andmeid.

Tavaliselt ei süveneta algandmetesse, et näha, mis seal on – klient ütleb lihtsalt: „Hei, siin on koosolek, siin on üksikasjad. Kas soovite nõustuda / võib-olla / keelduda?"

Selgus, et kui te seda Slackiga tegite, nagu te ütlete, rohkem kui viis aastat, olid sellesse kutsesse pakitud kõrvalised andmed, mis ei olnud kutse enda jaoks rangelt seotud.

Niisiis, mitte URL, mitte nimi, kuupäev, mitte kellaaeg…

…aga *kutsuva kasutaja parooliräsi* [NAER]

---

DOUG.  Hmmmmm.

---

PART.  Ma ei tee sind!

---

DOUG.  See kõlab halvasti…

---

PART.  Jah, see on tõesti nii, kas pole?

Halb uudis on see, kuidas kurat see sinna sattus?

Ja kui see kord seal sees oli, kuidas kuradi pärast see viis aastat ja kolm kuud märkamisest kõrvale hiilis?

Tegelikult, kui külastate artiklit alasti turvalisuse kohta ja vaatate täielik URL artikli lõpus märkate, et blahblahblah-for-three-months.

Sest esimest korda aruannet lugedes ei tahtnud mu mõistus näha seda 2017. aastana! [NAER]

Aeg oli 17. aprillist 17. juulini ja seega oli seal palju 17-seid.

Ja mu mõistus kustutas 2017. aasta kui algusaasta – lugesin seda valesti kui „selle aasta aprillist juulini*” [2022].

Mõtlesin: "Vau, *kolm kuud* ja nad ei märganud."

Ja siis esimene kommentaar artiklile oli: "Ahm [KÖHA]. See oli tegelikult 17. aprill *2017*.

Wow!

Kuid keegi mõtles selle välja 17. juulil [2022] ja Slack, nende kiituseks, parandas selle samal päeval.

Nagu: "Oh, kullake, mida me mõtlesime?!"

Nii et see on halb uudis.

Hea uudis on see, et vähemalt olid *räsitud* paroolid.

Ja neid ei räsitud, vaid *soolati*, mis on koht, kus saate parooliga sisestada kordumatult valitud kasutaja kohta juhuslikud andmed.

Selle idee on kahekordne.

Esiteks, kui kaks inimest valivad sama parooli, ei saa nad sama räsi, seega ei saa te räsiandmebaasi vaadates järeldusi teha.

Ja teiseks ei saa te teadaolevate sisendite jaoks teadaolevate räside sõnastikku ette arvutada, kuna peate looma iga parooli jaoks eraldi sõnastiku *iga soola* jaoks.

Seega pole räsiparoolide murdmine tühine harjutus.

Seda öeldes on kogu idee selles, et need ei peaks olema avalikud registrid.

Neid räsitakse ja soolatakse *juhul, kui* need lekivad, mitte *lekkimise vältimiseks.

Niisiis, muna Slacki näkku!

Slack ütleb, et see mõjutas umbes ühte kasutajat 200-st ehk 0.5%.

Aga kui olete Slacki kasutaja, siis eeldaksin, et kui nad viie aasta jooksul ei mõistnud, et lekivad räsiparoole, siis võib-olla ei loetlenud nad ka täielikult mõjutatud inimeste loendit.

Nii et minge ja muutke oma parool igal juhul… võite sama hästi.

---

DOUG.  OK, me ütleme ka: kui te ei kasuta paroolihaldurit, kaaluge selle hankimist; ja lülitage 2FA sisse, kui saate.

---

PART.  Arvasin, et see meeldib sulle, Doug.

---

DOUG.  Jah!

Ja siis, kui olete Slack või see meeldib ettevõttele, valige a mainekas soola-räsi-ja venita-algoritm paroole ise käsitsedes.

---

PART.  Jah.

Suur asi Slacki vastuses ja asi, mis minu arvates puudus, on see, et nad lihtsalt ütlesid: "Ära muretse, me mitte ainult ei räsinud paroole, vaid ka soolasime need ära."

Minu nõuanne on, et kui teid tabatakse selliselt rikkumiselt, peaksite olema valmis deklareerima soolamise ja räsimise algoritmi või protsessi ning ideaalis ka nn. venitus, kus te ei räsi salasõna ainult üks kord, vaid võib-olla räsite seda 100,000 XNUMX korda, et aeglustada mis tahes sõnastikku või toore jõu rünnakut.

Ja kui ütlete, millist algoritmi te kasutate ja milliste parameetritega... PBKDF2, bcrypt, scrypt, Argon2 – need on seal kõige tuntumad parooli „soola-räsi-venitamise” algoritmid.

Kui ütlete tegelikult, millist algoritmi te kasutate, siis: [A] olete avatum ja [B] annate probleemi potentsiaalsetele ohvritele võimaluse ise hinnata, kui ohtlik see nende arvates võis olla. .

Ja selline avatus võib tegelikult palju aidata.

Slack seda ei teinud.

Nad lihtsalt ütlesid: "Oh, need olid soolatud ja räsitud."

Aga mida me ei tea, on see, kas nad panid kaks baiti soola ja räsisid need siis üks kord SHA-1-ga…

…või oli neil midagi pragunemiskindlamat?

---

DOUG.  Halbade asjade teema juurde jäädes märkame suundumust, kus inimesed on GitHubi halbade asjade süstimine, lihtsalt selleks, et näha, mis juhtub, paljastades riski…

…meil on veel üks neist lugudest.

---

PART.  Jah, keegi, kes on nüüd väidetavalt Twitteris välja tulnud ja öelnud: "Ärge muretsege, poisid, kahju pole tehtud. See oli lihtsalt uurimiseks. Ma kirjutan aruande, paistan Blue Alert'ist välja.

Nad lõid sõna otseses mõttes tuhandeid võltsitud GitHubi projekte, mis põhinesid olemasoleva seadusliku koodi kopeerimisel, sihilikult mõne pahavarakäskluse sisestamisel, näiteks "helistage koju, et saada täiendavaid juhiseid" ja "tõlgendage vastuse sisu käivitatava tagaukse koodina" ja nii edasi.

Niisiis, asjad, mis võivad tõesti kahjustada, kui installite ühe neist pakettidest.

Neile õigete nimede andmine …

...laenates ilmselt tõelise projekti elluviimise ajalugu, nii et asi nägi palju legitiimne välja, kui te muidu eeldaksite, kui see lihtsalt ilmuks: "Hei, laadige see fail alla. Sa tead, et tahad!”

Kas tõesti?! Uuring?? Me ei teadnud seda juba?!!?

Nüüd võite vaielda: "Noh, Microsoft, kes omab GitHubi, mida nad teevad, et inimestel oleks sedalaadi kraami üleslaadimine nii lihtne?"

Ja selles on oma tõde.

Võib-olla suudaksid nad paremini pahavara eemal hoida.

Kuid see on veidi üle võlli öelda: "Oh, see kõik on Microsofti süü."

Minu arvates on veelgi hullem öelda: „Jah, see on tõeline uurimus; see on tõesti oluline; Peame inimestele meelde tuletama, et see võib juhtuda.

Noh, [A] me juba teame seda, tänan teid väga, sest paljud inimesed on seda varem teinud; saime sõnumi valjult ja selgelt kätte.

Ja [B] see *ei ole* uurimus.

Sellega üritatakse sihilikult meelitada inimesi alla laadima koodi, mis annab potentsiaalsele ründajale kaugjuhtimispuldi, vastutasuks aruande kirjutamise võimaluse eest.

See kõlab minu jaoks pigem "suure paksu vabandusena" kui uurimistöö seadusliku motivaatorina.

Ja seega on minu soovitus: kui arvate, et see *on* uurimustöö ja olete otsustanud midagi sellist uuesti teha, *ärge oodake suurt kaastunnet*, kui vahele jääte.

---

DOUG.  Olgu – me tuleme selle juurde tagasi ja lugeja kommenteerib saate lõpus, nii et pidage kinni.

Aga kõigepealt räägime sellest valgusfooridja mis neil küberturvalisusega pistmist on.

---

PART.  Ahhh, jah! [NAER]

Noh, seal on asi, mida nimetatakse TLP-ks Valgusfoori protokoll.

Ja TLP on see, mida võite nimetada "inimese küberjulgeoleku uurimisprotokolliks", mis aitab teil märgistada dokumente, mida teistele inimestele saadate, et anda neile vihje selle kohta, mida te loodate (ja mis veelgi olulisem, mida te loodate teha *). mitte*) teha andmetega.

Täpsemalt, kui laialt peaksid nad seda ümber jagama?

Kas see on midagi nii olulist, et võiksite seda maailmale kuulutada?

Või on see potentsiaalselt ohtlik või võib see sisaldada asju, mida me veel ei taha avalikustada... nii et hoidke see enda teada?

Ja see algas sellega: TLP:RED, mis tähendas: "Hoia see endale"; TLP:AMBER, mis tähendas "Saate seda levitada oma ettevõttes või oma klientidele, kellel on teie arvates vaja seda kiiresti teada saada"; TLP:GREEN, mis tähendas: "OK, võite lasta sellel küberjulgeoleku kogukonnas laialdaselt levida."

And TLP:WHITE, mis tähendas: "Võite seda kellelegi öelda."

Väga kasulik, väga lihtne: PUNANE, MEREVAIK, ROHELINE… metafoor, mis töötab globaalselt, muretsemata selle pärast, mis vahe on "salajane" ja "konfidentsiaalse" ning mis vahe on "konfidentsiaalsel" ja "salastatud" vahel, kõik see keeruline värk, mis vajab selle ümber palju seadusi.

Noh, TLP sai just mõned muudatused.

Seega, kui tegelete küberturvalisusega seotud uuringutega, veenduge, et olete neist teadlik.

TLP:WHITE on muudetud minu arvates palju paremaks terminiks, sest valge sellel on kõik need mittevajalikud kultuurilised varjundid, ilma milleta saame nüüdisajal hakkama.

Niisiis, TLP:WHITE on just saanud TLP:CLEAR, mis on minu arvates palju parem sõna, sest see ütleb: "Teil on selge, et neid andmeid kasutate" ja see kavatsus on väga selgelt öeldud. (Vabandust, ma ei suutnud sõnamängule vastu panna.)

Ja seal on täiendav kiht (nii et see on metafoori veidi rikkunud - see on nüüd *viievärviline valgusfoor!).

Seal on spetsiaalne tase, mida nimetatakse TLP:AMBER+STRICTja see tähendab: "Saate seda oma ettevõttes jagada."

Nii et teid võidakse kutsuda koosolekule, võib-olla töötate küberjulgeoleku ettevõttes ja on täiesti selge, et peate seda näitama programmeerijatele, võib-olla oma IT-meeskonnale, võib-olla oma kvaliteedi tagamise inimestele, et saaksite uurida probleemi või tegelege selle parandamisega.

Kuid TLP:AMBER+STRICT tähendab, et kuigi saate seda oma organisatsiooni sees levitada, *ärge rääkige sellest oma klientidele või klientidele* ega isegi mitte ettevõttevälistele inimestele, keda teie arvates võiks olla vaja teada.

Alustuseks hoidke seda tihedamas kogukonnas.

TLP:AMBER, nagu varemgi, tähendab "OK, kui tunnete, et peate oma klientidele sellest rääkima, saate seda teha."

Ja see võib olla oluline, sest mõnikord võite soovida oma kliente teavitada: „Hei, meil on parandus tulemas. Enne paranduse saabumist peate võtma mõned ettevaatusabinõud. Aga kuna see on omamoodi tundlik, siis võib paluda, et te sellest maailmale veel ei räägi?"

Mõnikord mängib maailmale liiga vara rääkimine tegelikult rohkem kelmide kui kaitsjate kätte.

Seega, kui olete küberturvalisusele reageerija, soovitan teil teha järgmist. https://www.first.org/tlp

---

DOUG.  Ja saate ka loe selle kohta lähemalt meie saidil, nakedsecurity.sophos.com.

Ja kui otsite mõnda muud kerget lugemist, unustage kvantkrüptograafia ... me liigume edasi postkvantkrüptograafia, Paul!

---

PART.  Jah, me oleme sellest podcastis paar korda varem rääkinud, kas pole?

Kvantarvuti idee, eeldades, et arvuti on piisavalt võimas ja töökindel, seisneb selles, et teatud tüüpi algoritme saaks kiirendada üle tänapäevase tehnika taseme, kas ruutjuure häälestuse järgi… või mis veelgi hullem, Tänase probleemi ulatuse *logaritm*.

Teisisõnu, selle asemel, et võtta 2²⁵⁶ püüab leida konkreetse räsiga faili, võib-olla saate seda teha vaid ("just"!) 2¹²⁸ proovib, mis on ruutjuur.

Ilmselgelt palju kiiremini.

Kuid algarvude faktoriseerimisega on seotud terve rida probleeme, mida teooria kohaselt võib praeguse aja *logaritmiga* lõdvalt öeldes murda.

Nii et selle asemel, et võtta näiteks 2¹²⁸ päevade purustamiseks [KAUAL PIKEM KUI PRAEGU KÄESOLEVA VANUS], võib purunemiseks kuluda vaid 128 päeva.

Või võite asendada "päevad" sõnaga "minutid" või mis iganes.

Ja kahjuks see logaritmiline aja algoritm (nn Shori kvantfaktoriseerimise algoritm)… mida võiks teoreetiliselt rakendada mõnede tänapäevaste krüptotehnikate puhul, eriti nende puhul, mida kasutatakse avaliku võtme krüptograafias.

Ja igaks juhuks, kui need kvantarvutusseadmed saavad lähiaastatel teostatavaks, peaksime võib-olla hakkama kohe valmistuma krüpteerimisalgoritmide jaoks, mis ei ole nende kahe konkreetse rünnakuklassi suhtes haavatavad?

Eelkõige logaritm, kuna see kiirendab potentsiaalseid rünnakuid nii palju, et krüptovõtmed, mille kohta me praegu arvame: "Noh, keegi ei saa sellest kunagi aru", võivad mõnel hilisemal etapil paljastada.

Igatahes, NIST, Riiklik standardite ja tehnoloogia instituut USA-s on juba mitu aastat korraldanud konkurssi, et proovida standardida avalikke, patenteerimata ja põhjalikult kontrollitud algoritme, mis on nende maagiliste kvantarvutite suhtes vastupidavad, kui need kunagi ilmuvad.

Ja hiljuti valisid nad neli algoritmi, mida nad on nüüd valmis standardima.

Neil on lahedad nimed, Doug, nii et ma pean need ette lugema: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONja SPHINCS+. [NAER]

Nii et neil on lahedad nimed, kui mitte midagi muud.

Kuid samal ajal arvas NIST: "Noh, see on ainult neli algoritmi. Valime veel neli potentsiaalset teisejärgulist kandidaati ja vaatame, kas mõni neist peaks samuti läbi minema.

Seega on praegu neli standardiseeritud algoritmi ja neli algoritmi, mida võidakse tulevikus standardida.

Või oli neid 5. juulil 2022 neli ja üks neist oli SIKE, lühike üliainsuse isogenees võtme kapseldamine.

(Me vajame mitut taskuhäälingusaadet, et selgitada üliainsuse isogeene, nii et me ei viitsi. [NAER])

Kuid kahjuks näib see, mis seal rippus, et standardiseerida, nagu oleks see pöördumatult katki läinud, hoolimata sellest, et see on juba vähemalt viis aastat olnud avalikkusele kontrolli all.

Õnneks mõtlesid kaks Belgia krüptograafi just enne selle standardiseerimist või saamist: "Tead mida? Arvame, et oleme saanud sellest mööda, kasutades arvutusi, mis võtavad üsna keskmisel protsessoril, kasutades ainult ühte tuuma, umbes tund.

---

DOUG.  Ma arvan, et parem on see teada saada kohe, kui pärast selle standardimist ja loodusest välja toomist?

---

PART.  Tõepoolest!

Ma arvan, et kui see oleks olnud üks juba standarditud algoritmidest, peaksid nad standardi kehtetuks tunnistama ja uue välja pakkuma?

Tundub imelik, et seda ei märgatud viie aasta jooksul.

Kuid ma arvan, et see on kogu avaliku kontrolli idee: kunagi ei tea, millal keegi võib lihtsalt tabada vajalikku pragu või väikest kiilu, mille abil nad saavad sisse murda ja tõestada, et algoritm pole nii tugev, kui algselt arvati.

Hea meeldetuletus, et kui olete * kunagi* mõelnud oma krüptograafia kududa ...

---

DOUG.  [NAERAB] Ma ei ole!

---

PART.  ..hoolimata sellest, et oleme teile Naked Security taskuhäälingusaates N korda öelnud: "Ära tee seda!"

See peaks olema ülim meeldetuletus, et isegi kui tõelised eksperdid panevad välja algoritmi, mis on viie aasta jooksul ülemaailmses konkurentsis avaliku kontrolli all, ei anna see tingimata piisavalt aega, et paljastada vigu, mis osutuvad üsna halbadeks.

Seega ei näe see selle jaoks kindlasti hea välja SIKE algoritm.

Ja kes teab, äkki võetakse tagasi?

---

DOUG.  Hoiame sellel silma peal.

Ja kuna päike loojub aeglaselt meie selle nädala saatele, on aeg kuulda ühelt meie lugejalt GitHubi loost, mida varem arutasime.

Röövima kirjutab:

"Kommentaarides on kriit ja juust ning ma ei taha seda öelda, kuid ma tõesti näen vaidluse mõlemat poolt. Kas see on ohtlik, tülikas, aega raiskav ja ressursimahukas? Jah, loomulikult on. Kas see on see, mida kriminaalselt mõtlevad tüübid teeksid? Jah, jah, see on. Kas see on meeldetuletus kõigile, kes kasutavad GitHubi või mõnda muud koodihoidla süsteemi, et Internetis turvaline reisimine nõuab tervet küünilisust ja paranoiat? Jah. Süsteemi administraatorina soovib osa minust tunnustada olemasoleva riski paljastamist. Paljude arendajate süsteemiadministraatorina pean nüüd veenduma, et kõik on hiljuti uurinud, kas tõmbenumbrid on küsitavad.

---

PART.  Jah, tänan teid, RobB, selle kommentaari eest, sest arvan, et on oluline näha argumendi mõlemat poolt.

Oli kommentaare, kes lihtsalt ütlesid: "Mis kuradi probleem selles on? See on hea!"

Üks inimene ütles, "Ei, tegelikult on see pliiatsi testimine hea ja kasulik. Olge rõõmus, et need nüüd paljastatakse, selle asemel, et tegeliku ründaja eest oma inetut pead tõsta."

Ja minu vastus sellele on: "Tegelikult on see rünnak."

Lihtsalt keegi on nüüd tagantjärele välja tulnud ja öelnud: "Oh, ei, ei. Kahju pole tehtud! Ausalt, ma ei olnud ulakas."

Ma arvan, et te ei ole kohustatud seda vabandust ostma!

Kuid igatahes pole see läbitungimiskatse.

Minu vastuseks oli öelda väga lihtsalt: "Vastutustundlikud läbitungimise testijad tegutsevad [A] ainult pärast selgesõnalise loa saamist ja [B] käitumispiirangute piires, mis on eelnevalt selgesõnaliselt kokku lepitud."

Te ei tööta lihtsalt välja oma reegleid ja me oleme seda varem arutanud.

Niisiis, nagu ütles teine ​​kommentaator, mis on minu arvates minu lemmikkommentaar… ütles Ecurb, "Ma arvan, et keegi peaks kõndima majast majja ja purustama aknad, et näidata, kui ebaefektiivsed ukselukud tegelikult on. See tähtaeg on möödas. Palun hüpake keegi selle peale."

Ja siis, inimesed, juhuks, kui te ei saanud aru, et see on satiir, ütleb ta: "Mitte!"

---

PART.  Ma saan aru, et see on hea meeldetuletus, ja ma saan aru, et kui olete GitHubi kasutaja nii tootja kui ka tarbijana, on asju, mida saate teha.

Loetleme need kommentaarides ja artiklis.

Näiteks pange kõikidele kohustustele digiallkiri, et oleks ilmne, et muudatused tulid teie poolt ja et oleks mingisugune jälgitavus.

Ja ärge lihtsalt tarbige asju pimesi, sest tegite otsingu ja tundus, et see võib olla õige projekt.

Jah, me kõik saame sellest õppida, aga kas see loeb meid tegelikult õpetamiseks või on see lihtsalt midagi, mida peaksime õppima?

Ma arvan, et see *ei ole* õpetus.

See lihtsalt *pole piisavalt kõrge standardiga*, et seda teadustööna lugeda.

---

DOUG.  Suurepärane arutelu selle artikli ümber ja täname selle saatmise eest, Rob.

Kui teil on huvitav lugu, kommentaar või küsimus, mille soovite esitada, loeksime seda hea meelega taskuhäälingusaates.

Saate meili teel saata tips@sophos.com; saate kommenteerida mis tahes meie artiklit; või võite meile sotsiaalvõrgustikus helistada: @NakedSecurity.

See on meie tänane saade – suur tänu kuulamast.

Paul Ducklini jaoks olen Doug Aamoth, kes tuletab teile kuni järgmise korrani meelde, et…

---

MÕlemad.  Ole turvaline!

[MUUSIKAMODEEM]