DET ER VANSKERE ENN DU TROR
Ingen lydspiller under? Lytte direkte på Soundcloud.
Med Doug Aamoth og Paul Ducklin. Intro- og outromusikk av Edith Mudge.
Du kan lytte til oss på Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher og hvor som helst hvor du finner gode podcaster. Eller bare dropp URL til RSS-feeden vår inn i din favoritt podcatcher.
LES TRANSKRIPTET
DOUG. Passordbehandler sprekker, påloggingsfeil og dronning Elizabeth I versus Mary Queen of Scots ... selvfølgelig!
Alt det, og mer, på Naked Security-podcasten.
[MUSIKK MODEM]
Velkommen til podcasten, alle sammen.
Jeg er Doug Aamoth; han er Paul Ducklin.
Paul, hvordan har du det?
AND. Wow!
Skullduggery fra 16-tallet møter podcasten Naked Security, Douglas.
Jeg gleder meg!
DOUG. Det er klart, ja ... vi kommer til det snart.
Men først, som alltid, This Week in Tech History, 28. mai 1987, ga den nettbaserte tjenesteleverandøren CompuServe ut noe som heter Graphics Interchange Format, eller GIF [HARD G].
Den ble utviklet av avdøde Steve Wilhite, en ingeniør ved CompuServe (som forresten sverget opp og ned at det ble uttalt "jif") som et middel til å støtte fargebilder på den begrensede båndbredden og lagringskapasiteten til tidlige datanettverk.
Den første versjonen, GIF 87a, støttet maksimalt 256 farger; den ble raskt populær på grunn av dens evne til å vise enkle animasjoner og dens utbredte støtte på tvers av forskjellige datasystemer.
Takk, Mr. Wilhite.
AND. Og hva har det etterlatt oss, Douglas?
Nettanimasjoner og kontroverser om ordet uttales "grafikk" [HARD G] eller "giraffer" [SOFT G].
DOUG. Nøyaktig. [LETER]
AND. Jeg kan bare ikke kalle det "giff" [HARD G].
DOUG. Samme!
La oss stemple det, og gå videre til vår spennende historie...
…om dronning Elizabeth I, Mary Queen of Scots og en mann spiller begge sider mellom løsepengevare-skurker og hans arbeidsgiver, Paul.
Ransomware-historier: MitM-angrepet som virkelig hadde en mann i midten
AND. [LAUGGER] La oss starte på slutten av historien.
I utgangspunktet var det et løsepenge-angrep mot et teknologiselskap i Oxfordshire, i England.
(Ikke denne... det var et selskap i Oxford, 15 km oppover elven fra Abingdon-on-Thames, hvor Sophos er basert.)
Etter å ha blitt rammet av løsepengevare, ble de, som du kan forestille deg, rammet av et krav om å betale Bitcoin for å få tilbake dataene sine.
Og som den historien hadde vi en et par uker siden, en av deres egne defensive lag, som skulle hjelpe til med å håndtere dette, fant ut: "Jeg skal kjøre en MiTM", et Man-in-the-Middle-angrep.
Jeg vet det, for å unngå kjønnet språk og for å reflektere det faktum at det ikke alltid er en person (det er ofte en datamaskin i midten) i disse dager...
…om Naked Security skriver jeg nå "Manipulator-in-the-Middle."
Men dette var bokstavelig talt en mann i midten.
Enkelt sagt, Doug, klarte han å begynne å sende e-post til arbeidsgiveren hjemmefra, ved å bruke en slags skrivefeil-e-postkonto som var som skurkens e-postadresse.
Han kapret tråden og endret Bitcoin-adressen i de historiske e-postsporene, fordi han hadde tilgang til ledende ansattes e-postkontoer...
…og han begynte i utgangspunktet å forhandle som en mellommann.
Så du forestiller deg at han forhandler individuelt nå med skurken, og så sender han forhandlingen videre til arbeidsgiveren sin.
Vi vet ikke om han håpet å stikke av med all dusøren og så bare si til arbeidsgiveren sin: "Hei, gjett hva, skurkene lurte oss", eller om han ønsket å forhandle skurkene ned på sin ende, og hans arbeidsgiver oppe i den andre enden.
Fordi han visste alle de riktige/gale tingene å si for å øke frykten og redselen innad i selskapet.
Så målet hans var i utgangspunktet å kapre løsepenge-betalingen.
Vel, Doug, det hele ble litt pæreformet fordi, dessverre for ham og heldigvis for hans arbeidsgiver og for rettshåndhevelse, bestemte selskapet seg for ikke å betale.
DOUG. [LATER] Hmmmm!
AND. Så det var ingen Bitcoin for ham å stjele og deretter kutte og løpe.
Dessuten ser det ut til at han ikke skjulte sporene sine så godt, og hans ulovlige tilgang til e-postloggene kom da ut i vask.
Han visste tydeligvis at politiet nærmet seg ham, fordi han prøvde å tørke de useriøse dataene fra sine egne datamaskiner og telefoner hjemme.
Men de ble beslaglagt, og dataene ble gjenfunnet.
På en eller annen måte trakk saken ut i fem år, og til slutt, akkurat da han var i ferd med å gå til rettssak, bestemte han seg åpenbart for at han egentlig ikke hadde et bein å stå på, og han erkjente straffskyld.
Så der har du det, Doug.
Et bokstavelig talt mann-i-midten-angrep!
DOUG. OK, så det er vel og bra i 2023...
…men ta oss tilbake til 1580-tallet, Paul.
Hva med Mary, Queen of Scots og Queen Elizabeth I?
AND. Vel, for å være ærlig, jeg tenkte bare at det var en fin måte å forklare et mann-i-midten-angrep på ved å gå tilbake alle disse årene.
Fordi, berømt, dronning Elizabeth og hennes kusine Mary, Queen of Scots var religiøse og politiske fiender.
Elizabeth var dronningen av England; Mary var tronpretendent.
Så Mary ble faktisk arrestert under husarrest.
Mary levde i en viss luksus, men begrenset til et slott, og planla faktisk mot kusinen hennes, men de kunne ikke bevise det.
Og Mary sendte og mottok meldinger stappet inn i øltønnene som ble levert til slottet.
Tilsynelatende, i dette tilfellet, var mannen-i-midten en kompatibel ølleverandør som ville fjerne meldingene før Mary fikk dem, slik at de kunne kopieres.
Og han ville sette inn erstatningsmeldinger, kryptert med Marys chiffer, med subtile endringer som, løst sagt, til slutt overtalte Mary til å skrive mer enn hun sannsynligvis burde ha gjort.
Så hun ga ikke bare bort navnene på andre konspiratorer, hun indikerte også at hun godkjente planen om å myrde dronning Elizabeth.
De var tøffere tider da ... og England hadde absolutt dødsstraff i de dager, og Mary ble stilt for retten og henrettet.
DOUG. OK, så for alle som lytter, heisen for denne podcasten er "Nyheter og råd om nettsikkerhet, og et lite dryss av historie".
Tilbake til vår mann-i-midten i dagens dag.
Vi snakket om en annen innsidetrussel akkurat slik for ikke så lenge siden.
Så det ville vært interessant å se om dette er et mønster, eller om dette bare er en tilfeldighet.
Men vi snakket om noen ting du kan gjøre for å beskytte deg mot denne typen angrep, så la oss gå raskt over dem igjen.
Starter med: Splitt og hersk, som i utgangspunktet betyr: "Ikke gi én person i selskapet uhindret tilgang til alt," Paul.
AND. Ja.
DOUG. Og så har vi: Hold uforanderlige logger, som så ut som det skjedde i dette tilfellet, ikke sant?
AND. Ja.
Det ser ut til at et sentralt beviselement i denne saken var det faktum at han hadde gravd i e-poster til toppledere og endret dem, og han klarte ikke å skjule det.
Så du forestiller deg, selv uten de andre bevisene, at det faktum at han rotet med e-poster som spesifikt var relatert til løsepengevareforhandlinger og Bitcoin-adresser ville være ekstra mistenkelig.
DOUG. OK, til slutt: Mål alltid, anta aldri.
AND. Faktisk!
DOUG. De gode gutta vant til slutt ... det tok fem år, men vi klarte det.
La oss gå videre til vår neste historie.
Nettsikkerhetsselskap finner en påloggingsfeil i et verktøysett for appbygging.
Feilen fikses raskt og gjennomsiktig, så det er fint... men det er litt mer til historienselvfølgelig, Paul.
Seriøs sikkerhet: Verifisering er viktig – undersøke en OAUTH-påloggingsfeil
AND. Ja.
Dette er et sikkerhetsanalyseselskap for nettkoding (jeg håper jeg har valgt riktig terminologi der) kalt SALT, og de fant en autentiseringssårbarhet i et app-byggingsverktøysett kalt Expo.
Og velsigne deres hjerter, Expo støtter en ting som heter OAUTH Åpen autorisasjon system.
Det er den typen system som brukes når du går til et nettsted som har bestemt seg: «Vet du hva, vi vil ikke ha bryet med å prøve å lære hvordan vi gjør passordsikkerhet for oss selv. Det vi skal gjøre er at vi skal si «Logg på med Google, logg på med Facebook», noe sånt.
Og ideen er at du løst sett kontakter Facebook, eller Google, eller hva den vanlige tjenesten er, og du sier: "Hei, jeg vil gi example.com
tillatelse til å gjøre X."
Så, Facebook, eller Google, eller hva som helst, autentiserer deg og sier så: «OK, her er en magisk kode du kan gi til den andre enden som sier: 'Vi har sjekket deg ut; du har autentisert med oss, og dette er autentiseringstokenet ditt.»
Deretter kan den andre enden uavhengig sjekke med Facebook, eller Google, eller hva som helst for å sikre at det tokenet ble utstedt på vegne av deg.
Så hva det betyr er at du aldri trenger å overlevere noe passord til nettstedet ... du samarbeider, om du vil, Facebook eller Google for å gjøre selve autentiseringsdelen for deg.
Det er en god idé hvis du er et boutiquenettsted og tenker: "Jeg kommer ikke til å strikke min egen kryptografi."
Så dette er ikke en feil i OAUTH.
Det er bare en forglemmelse; noe som ble glemt i Expos implementering av OAUTH-prosessen.
Og løst sagt, Doug, går det slik.
Expo-koden lager en gigantisk URL som inkluderer alle parameterne som er nødvendige for å autentisere med Facebook, og deretter bestemme hvor det endelige magiske tilgangstokenet skal sendes.
Derfor, i teorien, hvis du konstruerte din egen URL eller var i stand til å endre URL-en, kan du endre stedet hvor dette magiske autentiseringstokenet endelig ble sendt.
Men du ville ikke være i stand til å lure brukeren, fordi en dialogboks vises som sier: «Appen kl URL-here
ber deg logge på Facebook-kontoen din. Stoler du fullt og helt på dette og vil la det gjøre det? Ja eller nei?"
Men når det kom til poenget med å motta autorisasjonskoden fra Facebook, eller Google, eller hva som helst, og sende den til denne "retur-URLen", ville ikke Expo-koden sjekke at du faktisk hadde klikket Yes
på godkjenningsdialogen.
Hvis du aktivt så dialogen og klikket No
, da ville du forhindret angrepet fra å skje.
Men i hovedsak, dette "mislyktes åpen".
Hvis du aldri så dialogen, så ville du ikke engang vite at det var noe å klikke og du bare gjorde ingenting, og så utløste angriperne ganske enkelt neste URL-besøk av seg selv med mer JavaScript...
… da ville systemet fungere.
Og grunnen til at det fungerte er at den magiske "retur-URLen", stedet hvor den superhemmelige autorisasjonskoden skulle sendes, ble satt i en nettinformasjonskapsel som Expo kunne bruke senere *før du klikket Yes
på dialogen*.
Senere ble eksistensen av den "retur-URL"-informasjonskapselen i hovedsak tatt, hvis du vil, som bevis på at du må ha sett dialogboksen, og du må ha bestemt deg for å gå videre.
Mens det faktisk ikke var tilfelle.
Så det var en stor slip 'twixt kopp og leppe, Douglas.
DOUG. OK, vi har noen tips, som starter med: Når det kom til å rapportere og avsløre denne feilen, var dette en læreboksak.
Dette er nesten nøyaktig hvordan du bør gjøre det, Paul.
Alt bare fungerte som det skulle, så dette er et flott eksempel på hvordan du kan gjøre dette på best mulig måte.
AND. Og det er en av hovedgrunnene til at jeg ønsket å skrive det opp på Naked Security.
SALT, menneskene som fant feilen...
..de fant det; de avslørte det på en ansvarlig måte; de jobbet med Expo, som fikset det, bokstavelig talt i løpet av timer.
Så selv om det var en feil, selv om det var en kodefeil, førte det til at SALT sa: "Vet du hva, Expo-folket var en absolutt fornøyelse å jobbe med."
Så gikk SALT i gang med å skaffe en CVE, og i stedet for å si: "Hei, feilen er rettet nå, så to dager senere kan vi gjøre et stort PR-splash om det," satte de likevel en dato tre måneder frem når de faktisk ville skrive opp sine funn og skrive opp sin svært pedagogiske rapport.
I stedet for å forhaste det for umiddelbare PR-formål, i tilfelle de ble scoopet i siste liten, rapporterte de ikke bare dette ansvarlig slik at det kunne fikses før skurkene fant det (og det er ingen bevis for at noen har misbrukt denne sårbarheten), de også da ga Expo litt spillerom til å gå ut dit og kommunisere med kundene sine.
DOUG. Og så snakket vi selvfølgelig litt om dette: Sørg for at autentiseringskontrollene mislykkes lukket.
Sørg for at den ikke bare fortsetter å fungere hvis noen ignorerer eller avbryter den.
Men det større problemet her er: Anta aldri at din egen klientsidekode vil ha kontroll over verifiseringsprosessen.
AND. Hvis du fulgte den nøyaktige prosessen med JavaScript-koden levert av Expo for å ta deg gjennom denne OAUTH-prosessen, ville du ha vært i orden.
Men hvis du unngikk koden deres og faktisk bare utløste koblingene med din egen JavaScript, inkludert å omgå eller avbryte popup-vinduet, så vant du.
Å omgå klientkoden din er det første en angriper kommer til å tenke på.
DOUG. Ok, sist men ikke minst: Logg ut av nettkontoer når du ikke bruker dem aktivt.
Det er et godt råd rundt omkring.
AND. Vi sier det hele tiden på Naked Security-podcasten, og vi har for mange år.
Det er et upopulært råd, fordi det er ganske upraktisk, på samme måte som å fortelle folk: "Hei, hvorfor ikke stille inn nettleseren din til å slette alle informasjonskapsler når du avslutter?"
Hvis du tenker på det, i dette spesielle tilfellet... la oss si at påloggingen skjedde via Facebook-kontoen din; OAUTH via Facebook.
Hvis du ble logget ut av Facebook, ville autentiseringsprosessen med Facebook ikke lykkes, uansett hvilket JavaScript-forræderi en angriper forsøkte (å drepe Expo-popupen og alt det der), fordi Facebook ville si: «Hei, denne personens ber meg om å autentisere dem. De er ikke pålogget for øyeblikket.»
Så du vil alltid og uunngåelig se Facebook-påloggingen dukke opp på det tidspunktet: "Du må logge på nå."
Og det ville umiddelbart gi bort underskuddet.
DOUG. Ok veldig bra.
Og dagens siste historie: Ikke få panikk, men det er tilsynelatende en måte å knekke hovedpassordet for åpen kildekode-passordbehandler KeePass.
Men igjen, ikke få panikk, fordi det er en mye mer komplisert enn det ser ut til, Paul.
Du må virkelig ha kontroll over noens maskin.
Seriøs sikkerhet: At KeePass "master passord knekker", og hva vi kan lære av det
AND. Du gjør.
Hvis du vil spore dette opp, er det CVE-2023-32784.
Det er en fascinerende feil, og jeg skrev en slags Magnum opus stilartikkel om Naked Security om det, med tittelen: At KeePass 'master passord sprekker' og hva vi kan lære av det.
Så jeg vil ikke ødelegge den artikkelen, som går inn på C-type minneallokering, skriptspråk-type minneallokering, og til slutt C# eller .NET administrerte strenger... administrert minneallokering av systemet.
Jeg skal bare beskrive hva forskeren i dette tilfellet oppdaget.
Det de gjorde er... de lette i KeePass-koden og i KeePass-minnedumper etter bevis på hvor enkelt det kan være å finne hovedpassordet i minnet, om enn midlertidig.
Hva om den er der minutter, timer eller dager senere?
Hva om hovedpassordet fortsatt ligger rundt, kanskje i byttefilen på disken, selv etter at du har startet datamaskinen på nytt?
Så jeg satte opp KeePass, og jeg ga meg selv et passord på 16 tegn med store bokstaver, slik at det ville være lett å gjenkjenne hvis jeg fant det i minnet.
Og se og se, jeg fant ikke på noe tidspunkt hovedpassordet mitt liggende i minnet: ikke som en ASCII-streng; ikke som en Windows widechar (UTF-16))-streng.
Flott!
Men det denne forskeren la merke til er at når du skriver inn passordet ditt i KeePass, blir det lagt opp... Jeg vil kalle det "Unicode-blob-karakteren", bare for å vise deg at, ja, du trykket på en tast, og derfor for å vise deg hvor mange tegn du har skrevet inn.
Så mens du skriver inn passordet ditt, ser du strengen blob [●], blob-blob [●●], blob-blob-blob [●●●], og i mitt tilfelle, alt opptil 16 blobs.
Vel, disse blob-strengene ser ikke ut til å være en sikkerhetsrisiko, så kanskje de bare ble overlatt til .NET-kjøringen for å administrere som "administrerte strenger", hvor de kan ligge rundt i minnet etterpå...
...og ikke bli ryddet opp fordi, "Hei, de er bare klatter."
Det viser seg at hvis du gjør en minnedump av KeePass, som gir deg hele 250 MB med ting, og du leter etter strenger som blob-blob, blob-blob-blob, og så videre (uansett antall blobs), er det en del av minnedumpen der du vil se to klatter, så tre klatter, så fire klatter, så fem klatter … og i mitt tilfelle helt opp til 16 klatter.
Og så får du bare denne tilfeldige samlingen av "blob-karakterer som skjer ved en feiltakelse", hvis du vil.
Med andre ord, bare det å lete etter disse blob-strengene, selv om de ikke gir bort det faktiske passordet ditt, vil lekke lengden på passordet ditt.
Imidlertid blir det enda mer interessant, fordi det denne forskeren lurte på er, "Hva om dataene i nærheten av disse blob-strengene i minnet på en eller annen måte kan være knyttet til de individuelle tegnene du skriver inn passordet?"
Så, hva om du går gjennom minnedump-filen, og i stedet for bare å søke etter to blobs, tre blobs/fire blobs, mer ...
…du søker etter en rekke klatter etterfulgt av et tegn som du tror er i passordet?
Så i mitt tilfelle søkte jeg bare etter tegnene A til Å, fordi jeg visste at det var det som sto i passordet.
Jeg søker etter en hvilken som helst streng med blobs, etterfulgt av ett ASCII-tegn.
Gjett hva som skjedde, Doug?
Jeg får to blobs etterfulgt av det tredje tegnet i passordet mitt; tre klatter etterfulgt av det fjerde tegnet i passordet mitt; helt opp til 15 blobs umiddelbart etterfulgt av det 16. tegnet i passordet mitt.
DOUG. Ja, det er et vilt bilde i denne artikkelen!
Jeg fulgte med... det ble litt teknisk, og plutselig ser jeg bare: «Huff! Det ser ut som et passord!"
AND. Det er i utgangspunktet som om de individuelle tegnene i passordet ditt er spredt rikelig gjennom minnet, men de som representerer ASCII-tegnene som faktisk var en del av passordet ditt da du skrev det inn...
…det er som om de har selvlysende form festet til seg.
Så disse strengene med klatter fungerer utilsiktet som en merkemekanisme for å flagge tegnene i passordet ditt.
Og, egentlig, moralen i historien er at ting kan lekke ut i minnet på måter du rett og slett aldri forventet, og som selv en velinformert kodeanmelder kanskje ikke legger merke til.
Så det er fascinerende lesning, og det er en flott påminnelse om at å skrive sikker kode kan være mye vanskeligere enn du tror.
Og enda viktigere, det kan være vanskeligere å gjennomgå, kvalitetssikre og teste sikker kode...
...fordi du må ha øyne foran, bak og på sidene av hodet, og du må virkelig tenke som en angriper og prøve å lete etter lekke hemmeligheter overalt hvor du kan.
DOUG. Ok, sjekk det ut, det er på makedsecurity.sophos.com.
Og når solen begynner å gå ned på showet vårt, er det på tide å høre fra en av våre lesere.
På den forrige podcasten (dette er en av favorittkommentarene mine ennå, Paul), kommenterer Naked Security-lytteren Chang:
Der. Jeg har gjort det. Etter nesten to år med overstadig lytting, sluttet jeg å lytte til alle podcastepisodene av Naked Security. Jeg er helt fanget.
Jeg likte det fra begynnelsen, og startet med den langvarige Chet Chat; deretter til det britiske mannskapet; "Å nei! Det er Kim» var neste; så nådde jeg endelig dagens "This Week in Tech History."
For en tur!
Takk, Chang!
Jeg kan ikke tro at du har overbevist alle episodene, men vi setter alle (håper jeg ikke snakker ut av tur) veldig stor pris på det.
AND. Veldig mye, Doug!
Det er fint å vite ikke bare at folk lytter, men også at de finner podcastene nyttige, og at det hjelper dem å lære mer om cybersikkerhet, og å løfte spillet deres, selv om det bare er en liten bit.
For jeg tror, som jeg har sagt mange ganger før, hvis vi alle løfter cybersikkerhetsspillet vårt en liten bit, så gjør vi mye mer for å holde kjeltringene i sjakk enn om ett eller to selskaper, en eller to organisasjoner, en eller to organisasjoner. to individer legger ned en enorm innsats, men resten av oss henger etter.
DOUG. Nøyaktig!
Vel, tusen takk igjen, Chang, for at du sendte det inn.
Vi setter virkelig pris på det.
Og hvis du har en interessant historie, kommentar eller spørsmål du vil sende inn, elsker vi å lese den på podcasten.
Du kan sende en e-post til tips@sophos.com, du kan kommentere en av artiklene våre, eller du kan kontakte oss på sosiale medier: @nakedsecurity.
Det er showet vårt for i dag; tusen takk for at du lyttet.
For Paul Ducklin, jeg er Doug Aamoth, og minner deg på, inntil neste gang, om å...
BÅDE. Hold deg trygg!
[MUSIKK MODEM]
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoAiStream. Web3 Data Intelligence. Kunnskap forsterket. Tilgang her.
- Minting the Future med Adryenn Ashley. Tilgang her.
- Kjøp og selg aksjer i PRE-IPO-selskaper med PREIPO®. Tilgang her.
- kilde: https://nakedsecurity.sophos.com/2023/06/01/s3-ep137-16th-century-crypto-skullduggery/
- : har
- :er
- :ikke
- :hvor
- $OPP
- 10
- 15%
- 28
- a
- evne
- I stand
- Om oss
- om det
- Absolute
- absolutt
- adgang
- Logg inn
- kontoer
- tvers
- Handling
- aktivt
- faktiske
- faktisk
- adresse
- adresser
- råd
- Etter
- en gang til
- mot
- siden
- fremover
- Alle
- allokering
- Ok
- også
- alltid
- am
- beløp
- an
- analyse
- og
- animasjoner
- noen
- noen
- hvor som helst
- app
- eple
- verdsette
- godkjenning
- godkjent
- ER
- rundt
- arrestere
- Artikkel
- artikler
- AS
- At
- angripe
- Angrep
- lyd
- godkjenne
- autentisert
- autentiserer
- Autentisering
- forfatter
- tillatelse
- unngå
- unngås
- borte
- tilbake
- Båndbredde
- fat
- basert
- I utgangspunktet
- bukt
- BE
- fordi
- vært
- øl
- før du
- Begynnelsen
- bak
- være
- tro
- under
- BEST
- mellom
- Stor
- større
- Bit
- Bitcoin
- bitcoin-adresse
- både
- skuddpremie
- nett~~POS=TRUNC leseren~~POS=HEADCOMP
- Bug
- bugs
- men
- by
- ring
- som heter
- kom
- CAN
- kapasiteter
- saken
- fanget
- Århundre
- Gjerne
- chang
- endring
- endret
- Endringer
- endring
- karakter
- tegn
- sjekk
- sjekket
- Sjekker
- chiffer
- fjerne
- klikk
- kunde
- lukking
- kode
- Koding
- tilfeldighet
- samling
- COM
- kommentere
- kommentarer
- kommunisere
- Selskaper
- Selskapet
- kompatibel
- datamaskin
- datamaskiner
- kontakt
- kontroll
- kontrovers
- cookie
- cookies
- politifolk
- kunne
- kurs
- crack
- sprukket
- skaper
- crooks
- krypto
- kryptografi
- kopp
- Gjeldende
- I dag
- Kunder
- cve
- Cybersecurity
- dato
- Dato
- dag
- Dager
- avtale
- Død
- besluttet
- Avgjør
- defensiv
- levert
- Etterspørsel
- beskrive
- arrestert
- utviklet
- Dialog
- Dialog
- gJORDE
- Die
- forskjellig
- Å avsløre
- oppdaget
- Vise
- do
- ikke
- gjort
- ikke
- ned
- Drop
- to
- dumpe
- Tidlig
- lett
- pedagogisk
- effektivt
- innsats
- element
- Heisplass
- emalje
- e-post
- kryptert
- slutt
- fiender
- håndhevelse
- ingeniør
- England
- Med tittelen
- Episoder
- hovedsak
- Selv
- etter hvert
- NOEN GANG
- alt
- bevis
- nøyaktig
- undersøke
- eksempel
- spennende
- henrettet
- Utgang
- forventet
- forklare
- Expo
- øyne
- Faktisk
- FAIL
- famously
- fascinerende
- Favoritt
- frykt
- tenkte
- filet
- slutt~~POS=TRUNC
- Endelig
- Finn
- finne
- funn
- funn
- slutt
- Først
- fikset
- fulgt
- etter
- Til
- glemt
- format
- Heldigvis
- funnet
- fire
- Fjerde
- fra
- foran
- fullt
- fikk
- spill
- få
- få
- giganten
- gif
- Gi
- gir
- Go
- mål
- Går
- skal
- god
- grafikk
- flott
- skyldig
- HAD
- hånd
- skje
- skjedde
- Skjer
- Hard
- Ha
- he
- hode
- høre
- hjelpe
- her
- her.
- Gjemme seg
- kapre
- ham
- hans
- historisk
- historie
- hit
- Hjemprodukt
- håp
- håper
- TIMER
- hus
- Hvordan
- Hvordan
- HTTPS
- stort
- i
- JEG VIL
- Tanken
- if
- bilder
- forestille
- umiddelbar
- umiddelbart
- uforanderlige
- gjennomføring
- in
- inkluderer
- Inkludert
- Øke
- uavhengig av hverandre
- indikert
- individuelt
- individuelt
- individer
- informasjon
- informasjonsteknologi
- innledende
- insider
- i stedet
- interessant
- inn
- utstedelse
- Utstedt
- IT
- DET ER
- Javascript
- bare
- Hold
- nøkkel
- strikke
- Vet
- Språk
- Siste
- Late
- seinere
- Law
- rettshåndhevelse
- lekke
- LÆRE
- minst
- Led
- venstre
- Lengde
- i likhet med
- Begrenset
- lenker
- lytteren
- Lytting
- lite
- levende
- logg
- logget
- Logg inn
- Lang
- så
- ser
- UTSEENDE
- Lot
- elsker
- Luksus
- maskin
- magi
- Hoved
- Mainstream
- gjøre
- mann
- administrer
- fikk til
- leder
- mange
- Master
- Saken
- maksimal
- Kan..
- midler
- måle
- mekanisme
- møter
- Minne
- meldinger
- Middle
- kunne
- minutt
- minutter
- feil
- MITM
- modifisere
- måneder
- moralsk
- mer
- flytte
- mr
- mye
- musikk
- musikal
- må
- my
- Naken sikkerhet
- Naken sikkerhetspodcast
- navn
- Nær
- Trenger
- nødvendig
- forhandlinger
- nett
- nettverk
- aldri
- likevel
- nyheter
- neste
- fint
- Nei.
- ingenting
- Legge merke til..
- nå
- Antall
- oauth
- of
- off
- ofte
- on
- ONE
- seg
- på nett
- bare
- åpen kildekode
- or
- organisasjoner
- Annen
- vår
- oss selv
- ut
- enn
- oppsyn
- egen
- Oxford
- Panic
- parametere
- del
- Spesielt
- Passerer
- Passord
- Password Manager
- Mønster
- paul
- Betale
- betaling
- porsjoner
- tillatelse
- person
- overtalt
- telefoner
- plukket
- Tonehøyde
- Sted
- plato
- Platon Data Intelligence
- PlatonData
- spiller
- glede
- podcast
- Podcasts
- Point
- politisk
- pop
- popularitet
- mulig
- innlegg
- pr
- presentere
- trykk
- forebygge
- forrige
- sannsynligvis
- prosess
- uttales
- bevis
- beskytte
- Bevis
- forutsatt
- leverandør
- formål
- sette
- setter
- Queen Elizabeth
- spørsmål
- raskt
- tilfeldig
- ransomware
- Ransomware -angrep
- heller
- nådd
- Lese
- lesere
- virkelig
- grunnen til
- grunner
- mottak
- kjenne igjen
- reflektere
- i slekt
- utgitt
- fjerne
- erstatning
- rapporterer
- rapportert
- Rapportering
- representere
- forsker
- REST
- gjennomgå
- ikke sant
- Risiko
- rss
- Kjør
- rennende
- Sa
- salt
- samme
- sier
- sier
- sier
- spredt
- Søk
- søker
- sikre
- sikkerhet
- se
- synes
- synes
- sett
- beslaglagt
- sending
- senior
- sendt
- tjeneste
- Tjenesteyter
- sett
- hun
- Om kort tid
- bør
- Vis
- side
- Tilbehør
- undertegne
- Enkelt
- ganske enkelt
- So
- selskap
- Soft
- noen
- Noen
- noe
- Soundcloud
- sett
- spesielt
- Spotify
- stå
- Begynn
- startet
- Start
- opphold
- Steps
- Steve
- Still
- lagring
- Story
- String
- stil
- send
- lykkes
- plutselig
- Sol
- støtte
- Støttes
- ment
- mistenkelig
- swap
- system
- Systemer
- Ta
- tatt
- lag
- tech
- Teknisk
- Teknologi
- fortelle
- terminologi
- Testing
- lærebok
- enn
- takk
- Takk
- Det
- De
- Storbritannia
- deres
- Dem
- seg
- deretter
- teori
- Der.
- derfor
- Disse
- de
- ting
- ting
- tror
- Tredje
- denne
- denne uka
- De
- selv om?
- trodde
- tre
- tronen
- Gjennom
- Tied
- tid
- ganger
- tips
- til
- i dag
- token
- også
- tok
- verktøykasse
- topp
- Top 10
- spor
- transparent
- prøve
- prøvd
- utløst
- Stol
- prøve
- SVING
- snur
- to
- typen
- typer
- Uk
- ute av stand
- etter
- dessverre
- unicode
- til
- URL
- us
- bruke
- brukt
- Bruker
- ved hjelp av
- Verifisering
- versjon
- Versus
- veldig
- av
- Besøk
- vital
- sårbarhet
- ønsker
- ønsket
- var
- Vei..
- måter
- we
- web
- Nettsted
- uke
- uker
- VI VIL
- gikk
- var
- Hva
- uansett
- når
- om
- hvilken
- HVEM
- hvorfor
- utbredt
- Wild
- vil
- vinduer
- tørke
- med
- innenfor
- uten
- Vant
- ord
- ord
- Arbeid
- arbeidet
- arbeid
- ville
- ville gitt
- skrive
- skriving
- X
- år
- ja
- ennå
- du
- Din
- deg selv
- zephyrnet