DET ER HÅRDERE, END DU TROR
Ingen lydafspiller nedenfor? Hør efter direkte på Soundcloud.
Med Doug Aamoth og Paul Ducklin. Intro og outro musik af Edith Mudge.
Du kan lytte til os på Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher og overalt, hvor gode podcasts findes. Eller bare drop URL til vores RSS-feed til din yndlings podcatcher.
LÆS TRANSCRIPTET
DOUG. Password manager cracks, login-fejl og Queen Elizabeth I versus Mary Queen of Scots... selvfølgelig!
Alt det, og mere, på Naked Security-podcasten.
[MUSIK MODEM]
Velkommen til podcasten, alle sammen.
Jeg er Doug Aamoth; han er Paul Ducklin.
Paul, hvordan har du det?
AND. Wow!
16-tallets informationsteknologiske skullduggery møder Naked Security-podcasten, Douglas.
Jeg kan ikke vente!
DOUG. Det er klart, ja... vi kommer til det snart.
Men først, som altid, This Week in Tech History, den 28. maj 1987, udgav online-tjenesteudbyderen CompuServe noget, der hedder Graphics Interchange Format eller GIF [HARD G].
Det blev udviklet af afdøde Steve Wilhite, en ingeniør hos CompuServe (som i øvrigt svor op og ned, at det blev udtalt "jif") som et middel til at understøtte farvebilleder på den begrænsede båndbredde og lagerkapacitet i tidlige computernetværk.
Den oprindelige version, GIF 87a, understøttede maksimalt 256 farver; det vandt hurtigt popularitet på grund af dets evne til at vise simple animationer og dets udbredte støtte på tværs af forskellige computersystemer.
Tak, hr. Wilhite.
AND. Og hvad har det efterladt os, Douglas?
Webanimationer og kontroverser om, hvorvidt ordet udtales "grafik" [HARD G] eller "giraffer" [SOFT G].
DOUG. Nemlig. [griner]
AND. Jeg kan bare ikke kalde det "giff" [HARD G].
DOUG. Samme!
Lad os stemple det, og gå videre til vores spændende historie...
…om dronning Elizabeth I, Mary Queen of Scots og en mand spiller begge sider mellem ransomware-skurke og hans arbejdsgiver, Paul.
Ransomware-fortællinger: MitM-angrebet, der virkelig havde en mand i midten
AND. Lad os starte i slutningen af historien.
Grundlæggende var det et ransomware-angreb mod et teknologifirma i Oxfordshire i England.
(Ikke denne … det var et firma i Oxford, 15 km op ad floden fra Abingdon-on-Thames, hvor Sophos er baseret.)
Efter at være blevet ramt af ransomware blev de, som du kan forestille dig, ramt af et krav om at betale Bitcoin for at få deres data tilbage.
Og ligesom den historie havde vi en et par uger siden, et af deres egne defensive hold, som skulle hjælpe med at håndtere dette, fandt ud af, "Jeg skal køre en MiTM", et Man-in-the-Middle-angreb.
Jeg ved det, for at undgå kønsbestemt sprogbrug og for at afspejle det faktum, at det ikke altid er en person (det er ofte en computer i midten) i disse dage...
…om Naked Security skriver jeg nu "Manipulator-in-the-Middle."
Men dette var bogstaveligt talt en mand i midten.
Kort sagt, Doug, lykkedes det ham at begynde at sende en e-mail til sin arbejdsgiver hjemmefra ved at bruge en slags skrivefejl-e-mail-konto, der var ligesom skurkens e-mailadresse.
Han kaprede tråden og ændrede Bitcoin-adressen i de historiske e-mail-spor, fordi han havde adgang til ledende medarbejderes e-mail-konti...
...og han begyndte dybest set at forhandle som en midtvejsmand.
Så du forestiller dig, at han nu forhandler individuelt med skurken, og så sender han den forhandling videre til sin arbejdsgiver.
Vi ved ikke, om han håbede på at stikke af med al dusøren og så bare sige til sin arbejdsgiver: "Hey, gæt hvad, skurkene snød os", eller om han ville forhandle skurkene ned på sin ende, og hans arbejdsgiver oppe i den anden ende.
Fordi han vidste alle de rigtige/forkerte ting at sige for at øge frygten og terroren inde i virksomheden.
Så hans mål var dybest set at kapre ransomware-betalingen.
Nå, Doug, det hele gik en lille smule pæreformet, fordi virksomheden, uheldigvis for ham og heldigvis for hans arbejdsgiver og for retshåndhævelsen, besluttede ikke at betale.
DOUG. [GRIN] Hmmmm!
AND. Så der var ingen Bitcoin for ham at stjæle og derefter cut-and-run.
Det ser også ud til, at han ikke skjulte sine spor særlig godt, og hans ulovlige adgang til e-mail-logfilerne kom så ud i vasken.
Han vidste åbenbart, at politiet lukkede sig om ham, fordi han forsøgte at slette de useriøse data fra sine egne computere og telefoner derhjemme.
Men de blev beslaglagt, og dataene blev gendannet.
På en eller anden måde trak sagen ud i fem år, og til sidst, lige da han skulle i retten, besluttede han åbenbart, at han ikke rigtig havde et ben at stå på, og han erkendte sig skyldig.
Så der har du det, Doug.
Et bogstaveligt mand-i-midten-angreb!
DOUG. OK, så det er godt og vel i 2023...
…men tag os tilbage til 1580'erne, Paul.
Hvad med Mary, Queen of Scots og Queen Elizabeth I?
AND. Nå, for at være ærlig, så tænkte jeg bare, at det var en god måde at forklare et mand-i-midten-angreb på ved at gå tilbage alle de år.
Fordi, berømt, dronning Elizabeth og hendes kusine Mary, Queen of Scots, var religiøse og politiske fjender.
Elizabeth var dronning af England; Mary var tronprætendent.
Så Mary blev faktisk tilbageholdt i husarrest.
Mary levede i en vis luksus, men begrænset til et slot, og planlagde faktisk mod sin kusine, men de kunne ikke bevise det.
Og Mary sendte og modtog beskeder, der var proppet i øltønderne, der blev leveret til slottet.
Tilsyneladende, i dette tilfælde, var manden-i-midten en kompatibel ølleverandør, som ville fjerne beskederne, før Mary fik dem, så de kunne kopieres.
Og han ville indsætte erstatningsbeskeder, krypteret med Marys chiffer, med subtile ændringer, der løst sagt til sidst overtalte Mary til at skrive mere, end hun nok burde have.
Så hun oplyste ikke kun navnene på andre sammensvorne, hun indikerede også, at hun godkendte planen om at myrde dronning Elizabeth.
De var hårdere tider dengang ... og England havde bestemt dødsstraf i de dage, og Mary blev retsforfulgt og henrettet.
DOUG. OK, så for alle, der lytter, er elevatorpitch for denne podcast: "Cybersikkerhedsnyheder og -råd, og et lille drys historie".
Tilbage til vores mand-i-midten i den nuværende dag.
vi talte om endnu en insidertrussel bare sådan for ikke så længe siden.
Så det ville være interessant at se, om dette er et mønster, eller om det bare er en tilfældighed.
Men vi talte om nogle ting, du kan gøre for at beskytte dig selv mod disse typer angreb, så lad os gennemgå dem hurtigt igen.
Starter med: Opdele og erobre, hvilket dybest set betyder: "Giv ikke én person i virksomheden uhindret adgang til alt," Paul.
AND. Ja.
DOUG. Og så har vi: Hold uforanderlige logfiler, som så ud som om det skete i dette tilfælde, ikke?
AND. Ja.
Det lader til, at et centralt beviselement i denne sag var det faktum, at han havde gravet i ledende medarbejderes e-mails og ændret dem, og det var han ikke i stand til at skjule.
Så du forestiller dig, selv uden de andre beviser, at det faktum, at han rodede med e-mails, der specifikt var relateret til ransomware-forhandlinger og Bitcoin-adresser, ville være ekstra-super mistænkeligt.
DOUG. OK, endelig: Mål altid, antag aldrig.
AND. Ja!
DOUG. De gode fyre vandt til sidst... det tog fem år, men vi gjorde det.
Lad os gå videre til vores næste historie.
Websikkerhedsfirma finder en login-fejl i en app-bygningsværktøjskasse.
Fejlen er rettet hurtigt og gennemsigtigt, så det er rart... men der er lidt mere til historienselvfølgelig, Paul.
Seriøs sikkerhed: Bekræftelse er afgørende – undersøgelse af en OAUTH-loginfejl
AND. Ja.
Dette er et webkodningssikkerhedsanalysefirma (jeg håber, jeg har valgt den rigtige terminologi der) kaldet SALT, og de fandt en autentificeringssårbarhed i et app-bygningsværktøjssæt kaldet Expo.
Og velsigne deres hjerter, Expo støtter en ting, der hedder OAUTH, den Åben autorisation system.
Det er den slags system, der bruges, når du går til et websted, der har besluttet, "Ved du hvad, vi vil ikke have besværet med at prøve at lære, hvordan vi laver adgangskodesikkerhed for os selv. Det, vi skal gøre, er, at vi vil sige, 'Log ind med Google, log ind med Facebook',” sådan noget.
Og ideen er, at du løst sagt kontakter Facebook eller Google, eller hvad den almindelige tjeneste er, og du siger: "Hej, jeg vil gerne give example.com
tilladelse til at gøre X."
Så Facebook eller Google, eller hvad som helst, autentificerer dig og siger så: "OK, her er en magisk kode, som du kan give til den anden ende, der siger: 'Vi har tjekket dig ud; du har autentificeret hos os, og dette er dit autentificeringstoken."
Derefter kan den anden ende uafhængigt tjekke med Facebook eller Google eller hvad som helst for at sikre, at det token blev udstedt på vegne af dig.
Så hvad det betyder, er, at du aldrig behøver at aflevere nogen adgangskode til webstedet ... du er, hvis du vil, med Facebook eller Google til at udføre den faktiske godkendelsesdel for dig.
Det er en god idé, hvis du er et boutique-websted, og du tænker: "Jeg har ikke tænkt mig at strikke min egen kryptografi."
Så dette er ikke en fejl i OAUTH.
Det er blot en forglemmelse; noget der blev glemt i Expos implementering af OAUTH-processen.
Og løst sagt, Doug, går det sådan her.
Expo-koden opretter en kæmpe URL, der inkluderer alle de parametre, der er nødvendige for at godkende med Facebook, og derefter beslutte, hvor det sidste magiske adgangstoken skal sendes.
Derfor, i teorien, hvis du konstruerede din egen URL eller var i stand til at ændre URL'en, kunne du ændre det sted, hvor denne magiske godkendelsestoken endelig blev sendt.
Men du ville ikke være i stand til at narre brugeren, fordi der vises en dialogboks, der siger: "Appen kl URL-here
beder dig om at logge ind på din Facebook-konto. Har du fuld tillid til dette og vil du lade det gøre det? Ja eller nej?"
Men når det kom til punktet at modtage autorisationskoden fra Facebook, eller Google eller hvad som helst, og videregive den til denne "retur-URL", ville Expo-koden ikke kontrollere, at du faktisk havde klikket Yes
på godkendelsesdialogen.
Hvis du aktivt så dialogen og klikkede No
, så ville du forhindre angrebet i at ske.
Men i det væsentlige "mislykkedes dette".
Hvis du aldrig så dialogen, så du ikke engang ville vide, at der var noget at klikke på, og du gjorde bare ingenting, og så udløste angriberne simpelthen det næste URL-besøg af sig selv med mere JavaScript...
… så ville systemet virke.
Og grunden til, at det virkede, er, at den magiske "retur-URL", det sted, hvor den superhemmelige autorisationskode skulle sendes, blev sat i en webcookie, som Expo kunne bruge senere *før du klikkede Yes
på dialogen*.
Senere blev eksistensen af denne "retur-URL"-cookie i det væsentlige taget, hvis du vil, som bevis på, at du skal have set dialogboksen, og du må have besluttet at gå videre.
Hvorimod det faktisk ikke var tilfældet.
Så det var en kæmpe slip 'twixt kop og læbe, Douglas.
DOUG. OK, vi har nogle tips, der starter med: Når det kom til at rapportere og afsløre denne fejl, var dette en lærebogssag.
Det er næsten præcis sådan du skal gøre det, Paul.
Alt fungerede bare som det skulle, så dette er et godt eksempel på, hvordan man gør det bedst muligt.
AND. Og det er en af hovedårsagerne til, at jeg ville skrive det op på Naked Security.
SALT, de mennesker, der fandt fejlen...
..de fandt det; de afslørede det ansvarligt; de arbejdede med Expo, som ordnede det, bogstaveligt talt inden for få timer.
Så selvom det var en fejl, selvom det var en kodefejl, førte det til, at SALT sagde: "Ved du hvad, Expo-folkene var en absolut fornøjelse at arbejde med."
Så gik SALT i gang med at få en CVE, og i stedet for at sige: "Hey, fejlen er rettet nu, så to dage senere kan vi lave et stort PR-sprøjt om det," satte de alligevel en dato tre måneder frem, hvor de faktisk ville skrive op deres resultater og skrive deres meget lærerige rapport.
I stedet for at haste det ud til øjeblikkelige PR-formål, i tilfælde af at de blev scoopet i sidste øjeblik, rapporterede de ikke kun dette ansvarligt, så det kunne rettes, før skurke fandt det (og der er ingen beviser for, at nogen havde misbrugt denne sårbarhed), de også derefter gav Expo lidt råderum til at gå derud og kommunikere med deres kunder.
DOUG. Og så snakkede vi selvfølgelig lidt om dette: Sørg for, at din godkendelseskontrol mislykkes lukket.
Sørg for, at det ikke bare bliver ved med at fungere, hvis nogen ignorerer eller annullerer det.
Men det større problem her er: Antag aldrig, at din egen kode på klientsiden vil have kontrol over verifikationsprocessen.
AND. Hvis du fulgte den nøjagtige proces af JavaScript-koden leveret af Expo for at tage dig gennem denne OAUTH-proces, ville du have haft det fint.
Men hvis du undgik deres kode og faktisk bare udløste dine egne links med JavaScript, inklusive omgåelse eller annullering af pop op-vinduet, så vandt du.
At omgå din klientkode er den første ting, som en angriber kommer til at tænke på.
DOUG. Ok, sidst men ikke mindst: Log ud af webkonti, når du ikke aktivt bruger dem.
Det er et godt råd hele vejen rundt.
AND. Vi siger det hele tiden på Naked Security-podcasten, og vi har til mange år.
Det er et upopulært råd, fordi det er ret ubelejligt, på samme måde som at fortælle folk, "Hey, hvorfor ikke indstille din browser til at rydde alle cookies ved afslutning?"
Hvis du tænker over det, i dette særlige tilfælde... lad os sige, at login foregik via din Facebook-konto; OAUTH via Facebook.
Hvis du var logget ud af Facebook, så ville godkendelsesprocessen med Facebook ikke lykkes, uanset hvilket JavaScript-forræderi en angriber forsøgte (at dræbe Expo-pop-op-vinduet og alt det der), fordi Facebook ville sige: "Hey, denne persons beder mig om at autentificere dem. De er ikke logget ind i øjeblikket."
Så du vil altid og uundgåeligt se Facebook-login pop op på det tidspunkt: "Du skal logge ind nu."
Og det ville give underskud væk med det samme.
DOUG. Okay, meget godt.
Og vores sidste historie på dagen: Gå ikke i panik, men der er tilsyneladende en måde at knække hovedadgangskoden til open source password manager KeePass.
Men igen, gå ikke i panik, for det er en meget mere kompliceret end det ser ud til, Paul.
Du er virkelig nødt til at have kontrol over nogens maskine.
Seriøs sikkerhed: At KeePass "master password crack", og hvad vi kan lære af det
AND. Du gør.
Hvis du vil spore dette, er det CVE-2023-32784.
Det er en fascinerende fejl, og jeg skrev en slags magnum opus stilartikel om Naked Security om det, med titlen: At KeePass 'master password crack' og hvad vi kan lære af det.
Så jeg vil ikke ødelægge den artikel, som går ind på C-type hukommelsesallokering, scriptingsprog-type hukommelsesallokering og til sidst C# eller .NET administrerede strenge... administreret hukommelsesallokering af systemet.
Jeg vil bare beskrive, hvad forskeren i dette tilfælde opdagede.
Det, de gjorde, var... de ledte i KeePass-koden og i KeePass-hukommelsesdumps efter bevis på, hvor nemt det kunne være at finde hovedadgangskoden i hukommelsen, om end midlertidigt.
Hvad hvis det er der minutter, timer eller dage senere?
Hvad hvis hovedadgangskoden stadig ligger rundt, måske i din swap-fil på disken, selv efter du har genstartet din computer?
Så jeg konfigurerede KeePass, og jeg gav mig selv en adgangskode på 16 tegn med store bogstaver, så det ville være nemt at genkende, hvis jeg fandt det i hukommelsen.
Og se og se, på intet tidspunkt fandt jeg mit hovedkodeord liggende i hukommelsen: ikke som en ASCII-streng; ikke som en Windows widechar (UTF-16)) streng.
Alle tiders!
Men det, denne forsker bemærkede, er, at når du indtaster din adgangskode i KeePass, vises den... Jeg vil kalde det "Unicode-blob-karakteren", bare for at vise dig, at ja, du trykkede på en tast og derfor for at vise dig hvor mange tegn du har indtastet.
Så mens du indtaster din adgangskode, ser du strengen klat [●], klat-blob [●●], klat-blob-blob [●●●], og i mit tilfælde, alt op til 16 klatter.
Nå, disse klatstrenge ser ikke ud til at være en sikkerhedsrisiko, så måske blev de bare overladt til .NET runtime for at administrere som "administrerede strenge", hvor de kunne ligge rundt i hukommelsen bagefter...
…og ikke få ryddet op, fordi "Hey, de er bare klatter."
Det viser sig, at hvis du laver et hukommelsesdump af KeePass, som giver dig hele 250 MB ting, og du leder efter strenge som blob-blob, blob-blob-blob og så videre (et vilkårligt antal klatter), er der et stykke hukommelsesdump, hvor du vil se to klatter, så tre klatter, så fire klatter, så fem klatter... og i mit tilfælde helt op til 16 klatter.
Og så får du bare denne tilfældige samling af "blob-karakterer, der sker ved en fejl", hvis du vil.
Med andre ord, bare at lede efter disse klatstrenge, selvom de ikke afslører dit faktiske kodeord, vil lække længden af dit kodeord.
Det bliver dog endnu mere interessant, fordi det, denne forsker undrede sig over, er: "Hvad nu hvis dataene i nærheden af disse klatstrenge i hukommelsen på en eller anden måde kan være knyttet til de individuelle tegn, som du indtaster i adgangskoden?"
Så hvad nu hvis du går gennem hukommelsesdump-filen og i stedet for bare at søge efter to klatter, tre klatter/fire klatter, mere...
…du søger efter en streng af klatter efterfulgt af et tegn, som du tror er i adgangskoden?
Så i mit tilfælde søgte jeg bare efter tegnene A til Z, fordi jeg vidste, at det var det, der stod i adgangskoden.
Jeg søger efter en hvilken som helst streng af klatter, efterfulgt af et ASCII-tegn.
Gæt hvad der skete, Doug?
Jeg får to klatter efterfulgt af det tredje tegn i mit kodeord; tre klatter efterfulgt af det fjerde tegn i mit kodeord; helt op til 15 klatter umiddelbart efterfulgt af det 16. tegn i min adgangskode.
DOUG. Ja, det er et vildt billede i denne artikel!
Jeg fulgte med... det blev lidt teknisk, og lige pludselig ser jeg bare, "Wow! Det ligner et kodeord!"
AND. Det er dybest set, som om de individuelle tegn i dit kodeord er spredt rigeligt gennem hukommelsen, men dem, der repræsenterer de ASCII-tegn, der faktisk var en del af dit kodeord, da du skrev det ind...
…det er som om, de har en selvlysende matrice knyttet til sig.
Så disse strenge af klatter fungerer utilsigtet som en tagging-mekanisme til at markere tegnene i din adgangskode.
Og i virkeligheden er historiens moral, at ting kan sive ud i hukommelsen på måder, som du simpelthen aldrig havde forventet, og som selv en velinformeret kodeanmelder måske ikke bemærker.
Så det er fascinerende læsning, og det er en god påmindelse om, at det kan være meget sværere at skrive sikker kode, end du tror.
Og endnu vigtigere, det kan være sværere at gennemgå, kvalitetssikre og teste sikker kode...
…fordi du skal have øjne foran, bagpå og på siderne af dit hoved, og du skal virkelig tænke som en angriber og prøve at lede efter utætte hemmeligheder overalt, hvor du kan.
DOUG. I orden, tjek det ud, det er på makedsecurity.sophos.com.
Og når solen begynder at gå ned på vores show, er det tid til at høre fra en af vores læsere.
På den forrige podcast (dette er en af mine yndlingskommentarer endnu, Paul), kommenterer Naked Security-lytteren Chang:
Der. Jeg har gjort det. Efter næsten to år med binge-lytning blev jeg færdig med at lytte til alle Naked Security-podcast-episodene. Jeg er helt fanget.
Jeg nød det fra begyndelsen, begyndende med den langvarige Chet Chat; derefter til det britiske mandskab; "Åh nej! Det er Kim” var den næste; så nåede jeg endelig frem til nutidens "This Week in Tech History."
Hvilken tur!
Tak, Chang!
Jeg kan ikke fatte, at du overdøvede alle episoderne, men vi sætter alle stor pris på det (håber jeg ikke taler udefra).
AND. Rigtig meget, Doug!
Det er rart at vide, ikke kun at folk lytter, men også at de finder podcasts nyttige, og at det hjælper dem med at lære mere om cybersikkerhed og løfte deres spil, selvom det kun er en lille smule.
For jeg tror, som jeg har sagt mange gange før, hvis vi alle løfter vores cybersikkerhedsspil en lille smule, så gør vi meget mere for at holde skurkene på afstand, end hvis en eller to virksomheder, en eller to organisationer, en eller to to personer yder en enorm indsats, men vi andre halter bagefter.
DOUG. Nøjagtig!
Nå, mange tak igen, Chang, fordi du sendte det ind.
Vi værdsætter det virkelig.
Og hvis du har en interessant historie, kommentar eller spørgsmål, du gerne vil indsende, så læser vi det gerne i podcasten.
Du kan sende en e-mail til tips@sophos.com, du kan kommentere på en af vores artikler, eller du kan kontakte os på socialt: @nakedsecurity.
Det er vores show for i dag; mange tak fordi du lyttede.
For Paul Ducklin er jeg Doug Aamoth, og minder dig om, indtil næste gang, at...
BEGGE. Hold dig sikker!
[MUSIK MODEM]
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoAiStream. Web3 Data Intelligence. Viden forstærket. Adgang her.
- Udmøntning af fremtiden med Adryenn Ashley. Adgang her.
- Køb og sælg aktier i PRE-IPO-virksomheder med PREIPO®. Adgang her.
- Kilde: https://nakedsecurity.sophos.com/2023/06/01/s3-ep137-16th-century-crypto-skullduggery/
- :har
- :er
- :ikke
- :hvor
- $OP
- 10
- 15 %
- 28
- a
- evne
- I stand
- Om
- om det
- absolutte
- absolut
- adgang
- Konto
- Konti
- tværs
- Lov
- aktivt
- faktiske
- faktisk
- adresse
- adresser
- rådgivning
- Efter
- igen
- mod
- siden
- forude
- Alle
- allokering
- I orden
- også
- altid
- am
- beløb
- an
- analyse
- ,
- animationer
- enhver
- nogen
- overalt
- app
- Apple
- værdsætter
- godkendelse
- godkendt
- ER
- omkring
- arrestere
- artikel
- artikler
- AS
- At
- angribe
- Angreb
- lyd
- autentificere
- autentificeret
- godkender
- Godkendelse
- forfatter
- tilladelse
- undgå
- undgås
- væk
- tilbage
- båndbredde
- tønder
- baseret
- I bund og grund
- Bugt
- BE
- fordi
- været
- øl
- før
- Begyndelse
- bag
- være
- Tro
- jf. nedenstående
- BEDSTE
- mellem
- Big
- større
- Bit
- Bitcoin
- bitcoin-adresse
- både
- Bounty
- browser
- Bug
- bugs
- men
- by
- ringe
- kaldet
- kom
- CAN
- kapaciteter
- tilfælde
- fanget
- Århundrede
- sikkert
- chang
- lave om
- ændret
- Ændringer
- skiftende
- karakter
- tegn
- kontrollere
- afkrydset
- Kontrol
- cipher
- klar
- klik
- kunde
- lukning
- kode
- Kodning
- sammentræf
- samling
- KOM
- KOMMENTAR
- kommentarer
- kommunikere
- Virksomheder
- selskab
- kompatibel
- computer
- computere
- kontakt
- kontrol
- kontroverser
- cookie
- cookies
- betjente
- kunne
- kursus
- sprække
- revnet
- skaber
- Crooks
- krypto
- kryptografi
- Kop
- Nuværende
- For øjeblikket
- Kunder
- CVE
- Cybersecurity
- data
- Dato
- dag
- Dage
- deal
- Død
- besluttede
- Beslutter
- defensiv
- leveret
- Efterspørgsel
- beskrive
- tilbageholdt
- udviklet
- dialog
- Dialog
- DID
- Die
- forskellige
- Offentliggørelse
- opdaget
- Skærm
- do
- Er ikke
- færdig
- Dont
- ned
- Drop
- grund
- dumpe
- Tidligt
- let
- uddannelsesmæssige
- effektivt
- indsats
- element
- Elevatorplads
- emails
- krypteret
- ende
- fjender
- håndhævelse
- ingeniør
- England
- Med titlen
- Episoder
- væsentlige
- Endog
- til sidst
- NOGENSINDE
- at alt
- bevismateriale
- præcist nok
- Undersøgelse
- eksempel
- spændende
- henrettet
- Udgang
- forventet
- forklarer
- Expo
- Øjne
- Faktisk
- FAIL
- berømt
- fascinerende
- Favorit
- frygt
- regnede
- File (Felt)
- endelige
- Endelig
- Finde
- finde
- fund
- fund
- ende
- Fornavn
- fast
- efterfulgt
- efter
- Til
- glemt
- format
- Heldigvis
- fundet
- fire
- Fjerde
- fra
- forsiden
- fuldt ud
- vundet
- spil
- få
- få
- kæmpe
- gif
- Giv
- giver
- Go
- mål
- Goes
- gå
- godt
- grafik
- stor
- skyldig
- havde
- hånd
- ske
- skete
- Happening
- Hård Ost
- Have
- he
- hoved
- høre
- hjælpe
- hende
- link.
- Skjule
- hijack
- ham
- hans
- historisk
- historie
- Hit
- Home
- håber
- håber
- HOURS
- hus
- Hvordan
- How To
- HTTPS
- kæmpe
- i
- SYG
- idé
- if
- billeder
- billede
- umiddelbar
- straks
- uforanderlige
- implementering
- in
- omfatter
- Herunder
- Forøg
- uafhængigt
- angivet
- individuel
- Individuelt
- enkeltpersoner
- oplysninger
- informationsteknologi
- initial
- Insider
- i stedet
- interessant
- ind
- spørgsmål
- Udstedt
- IT
- ITS
- JavaScript
- lige
- Holde
- Nøgle
- strikke
- Kend
- Sprog
- Efternavn
- Sent
- senere
- Lov
- retshåndhævelse
- lække
- LÆR
- mindst
- Led
- til venstre
- Længde
- ligesom
- Limited
- links
- lytter
- Lytte
- lidt
- levende
- log
- logget
- Logge på
- Lang
- kiggede
- leder
- UDSEENDE
- Lot
- kærlighed
- Luksus Boliger
- maskine
- Magic
- Main
- Mainstream
- lave
- mand
- administrere
- lykkedes
- leder
- mange
- Master
- Matter
- maksimal
- Kan..
- midler
- måle
- mekanisme
- opfylder
- Hukommelse
- beskeder
- Mellemøsten
- måske
- minut
- minutter
- fejltagelse
- MITM
- ændre
- måned
- moralsk
- mere
- bevæge sig
- mr
- meget
- Musik
- musical
- skal
- my
- Naked Security
- Podcast for nøgen sikkerhed
- navne
- I nærheden af
- Behov
- behov
- forhandlinger
- netto
- net
- aldrig
- Ikke desto mindre
- nyheder
- næste
- rart
- ingen
- intet
- Varsel..
- nu
- nummer
- oauth
- of
- off
- tit
- on
- ONE
- dem
- online
- kun
- open source
- or
- organisatorisk
- Andet
- vores
- os selv
- ud
- i løbet af
- Tilsyn
- egen
- Oxford
- Panic
- parametre
- del
- særlig
- Passing
- Adgangskode
- Password Manager
- Mønster
- paul
- Betal
- betaling
- Mennesker
- tilladelse
- person,
- overtalt
- telefoner
- plukket
- Pitch
- Place
- plato
- Platon Data Intelligence
- PlatoData
- spiller
- glæde
- podcast
- Podcasts
- Punkt
- politisk
- pop
- popularitet
- mulig
- Indlæg
- pr
- præsentere
- trykke
- forhindre
- tidligere
- sandsynligvis
- behandle
- udtalt
- bevis
- beskytte
- Bevise
- forudsat
- udbyder
- formål
- sætte
- sætter
- Dronning Elizabeth
- spørgsmål
- hurtigt
- tilfældig
- ransomware
- Ransomware angreb
- hellere
- nået
- Læs
- læsere
- virkelig
- grund
- årsager
- modtagende
- genkende
- afspejler
- relaterede
- frigivet
- Fjern
- udskiftning
- indberette
- rapporteret
- Rapportering
- repræsentere
- forsker
- REST
- gennemgå
- højre
- Risiko
- rss
- Kør
- kører
- Said
- salt
- samme
- siger
- siger
- siger
- spredt
- Søg
- søgning
- sikker
- sikkerhed
- se
- synes
- synes
- set
- beslaglagt
- afsendelse
- senior
- sendt
- tjeneste
- Tjenesteudbyder
- sæt
- hun
- Inden længe
- bør
- Vis
- side
- sider
- underskrive
- Simpelt
- ganske enkelt
- So
- Social
- Soft
- nogle
- Nogen
- noget
- Soundcloud
- taler
- specifikt
- Spotify
- stå
- starte
- påbegyndt
- Starter
- forblive
- Steps
- Steve
- Stadig
- opbevaring
- Story
- String
- stil
- indsende
- lykkes
- pludselige
- Sol
- support
- Understøttet
- formodes
- mistænksom
- bytte
- systemet
- Systemer
- Tag
- taget
- hold
- tech
- Teknisk
- Teknologier
- fortælle
- terminologi
- Test
- lærebog
- end
- takke
- tak
- at
- UK
- deres
- Them
- selv
- derefter
- teori
- Der.
- derfor
- Disse
- de
- ting
- ting
- tror
- Tredje
- denne
- denne uge
- dem
- selvom?
- tænkte
- tre
- trone
- Gennem
- Tied
- tid
- gange
- tips
- til
- i dag
- token
- også
- tog
- toolkit
- top
- Top 10
- spor
- gennemskueligt
- retssag
- forsøgte
- udløst
- Stol
- prøv
- TUR
- vender
- to
- typen
- typer
- Uk
- ude af stand
- under
- desværre
- unicode
- indtil
- URL
- us
- brug
- anvendte
- Bruger
- ved brug af
- Verifikation
- udgave
- versus
- meget
- via
- Besøg
- afgørende
- sårbarhed
- ønsker
- ønskede
- var
- Vej..
- måder
- we
- web
- Hjemmeside
- uge
- uger
- GODT
- gik
- var
- Hvad
- uanset
- hvornår
- hvorvidt
- som
- WHO
- hvorfor
- udbredt
- Wild
- vilje
- vinduer
- tørre
- med
- inden for
- uden
- Vandt
- ord
- ord
- Arbejde
- arbejdede
- arbejder
- ville
- ville give
- skriver
- skrivning
- X
- år
- Ja
- endnu
- dig
- Din
- dig selv
- zephyrnet