About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (37),privacy (17),Facebook (17),social media (11),itsec (11),egyéb (10),social web (9),biztonság (8),mobil (8),OSINT (6),jog (6),magánszféra (6),tudomány (6),szellemi tulajdon (6),Google (5),molbiol (5),felzárkóztató (5),webcserkészet (5),szájbarágó (5),plágium (4),Nobel-díj (4),kriminalisztika (4),terrorizmus (4),kultúra (4),big data (4),email (4),genetika (3),pszichológia (3),molekuláris biológia (3),biztonságpolitika (3),CRISPR (3),Android (3),online marketing (3),sajtó (3),élettudomány (3),gépi tanulás (3),Onedrive (3),üzenetküldés (3),jelszó (3),2015 (3),orvosi-fiziológiai (3),Apple (3),Gmail (3),reklám (3),konferencia (3),webkettő (3),biztonságtudatosság (3),kriptográfia (3),levelezés (3),magatartástudomány (3),azelsosprint (3),popszakma (3),hype (3),open source intelligence (3),torrent (3),nyelvtechnológia (3),bejutas (2),tweak (2),villámokosság (2),cas9 (2),Yoshinori Ohsumi (2),Hacktivity (2),génterápia (2),fiziológia (2),természetes nyelvfeldolgozás (2),Reblog Sprint (2),bűnügy (2),Pécs (2),nyílt forrású információszerzés (2),webkamera (2),deep web (2),P2P (2),Netacademia (2),arcfelismerés (2),DDoS (2),Balabit (2),bűnüldözés (2),TOR (2),kulturális evolúció (2),ransomware (2),hitelesítés (2),SPF (2),Whatsapp (2),neuropszichológia (2),szabad információáramlás (2),FUD (2),DKIM (2),2-FA (2),bolyai-díj 2015 (2),molekuláris genetika (2),jövő (2),sudo (2),IDC (2),cyberbullying (2),social engineering (2),malware (2),tartalomszolgáltatás (2),meetup (2),facebook (2),reblog (2),videó (2),titkosítás (2),kutatás (2),epic fail (2),pedofília (2),netkultúra (2),nyelvtudomány (2),vírus (2),hírszerzés (2),iOS (2),farmakológia (2),szociálpszichológia (2),tanulás (2),biológia (2),gépház (2),bulvár (2),bug (2),Tinder (2),öröklődő betegség (2),Yandex (2),könyv (2),beszélgetés rögzítése (2),pszeudo-poszt (2),Twitter (2)

Honnan tudható, hogy a címzett olvasta-e az emailed? 


email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésAmikor emailt küldünk valakinek, annak reményében tesszük, hogy azt a címzett majd el is olvassa. Ugyanakkor bármikor bárki mondhatja, hogy az emailt nem kapta meg, spamben landolt, nem volt még ideje foglalkozni vele, ugyanakkor indokolt esetben, ha a levél kellően fontos volt, tudunk kellene, hogy a levelet a címzett olvasta-e és ha igen, akkor mikor is. Hogyan oldható meg mégis a feladat? Tökéletesen sehogy, de részmegoldás azért van.  

Sokak számára alighanem már csak amolyan megmosolyogtató emlék, hogy az emailek olvasottságáról a címzettől visszajelzést kérhetünk, ha levelezőrendszerünk támogatja azt a pattintott kőkorszakból ránk maradt funkciót, amiben kérelmezi a címzettet, hogy jelezzen vissza a feladónak emailen, ha a levelet elolvasta. Ezt tekinthetjük a klasszikus e-tértivevénynek. A lehetőséget szinte már senki sem használja, ugyanis alapvetően a felhasználók többsége nem akarja a címzettel tudatni, hogy a levelet elolvasta-e, ha fontos dologról van szó, úgyis jelentkezik majd, ha pedig nem, jobb elsumákolnia, aztán tud jönni valami vérszegény kifogással. 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésAhogy írtam, gyakorlatilag egy kihalt lehetőségről van szó, mivel még ha kérünk is ilyen visszajelzést, a címzett levelezőrendszere ezt vagy figyelembe veszi vagy sem, ha támogatott a visszajelzés funkció, a felhasználó még mindig dönthet róla, hogy küldjön visszajelzést, ne küldjön visszajelzést, esetleg a levelezőrendszer rá se kérdezzen, így soha senkinek ne küldjön olvasottsági visszajelzést. 

Ugyanakkor fennmaradt az a természetes igény, hogy a feladó tudhasson róla, hogy a levelét a címzett megkapta, olvasta, csak ha nem válaszol, tesz rá magasról vagy nem jutott el hozzá. Az egész pedig egy régi jó technikával szinte mindig kivitelezhető, hamarosan rátérek, hogy miért nem garantáltan mindig. 

Amikor egy webszerverről egy dokumentumot letöltünk, annak a naplófájljába bekerül többek közt, hogy milyen IP-címmel, milyen böngészővel és böngészőverzióval, milyen oprendszerrel és annak milyen verziójával, azaz milyen géppel történt a letöltés. Megjegyzem, ezek kombinációja sokszor már önmagában is igencsak egyedi. Már több, mint tíz évvel ezelőtt is úgy küldték a hírleveleket a szolgáltatók, hogy abban olyan grafikus elemeket, azaz képeket helyeztek el, amiket HMTL formátumú levélbe szerkesztettek bele, a képeket pedig ennek megfelelően nem csatolták az emailhez, hanem egy külső szerverről töltötték be a HTML megjelenítésnek megfelelően a címzettnél. Nyilvánvaló, hogy ha a levél normálisan megjelent, a hírlevél küldője visszajelzést kapott azzal kapcsolatban, hogy a levelét egyáltalán mennyien nyitották meg, hiszen látta, hogy mennyi különböző logbejegyzés van, ami a képi elemek szerverről való letöltődését tanusította. Biztonsági szempontból viszont nagyban gondolkozva igen nagy kockázatot jelent, ha tudható, hogy valaki pontosan milyen platformmal netezik, ráadásul az IP-címekhek kapcsolódó szervezet és annak helye egyre pontosabban azonosíthatóvá vált az évek folyamán. 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetésSok-sok évvel ezelőtt már minden jólnevelt levelezőkliensben és webes levelezőrendszerben alapértelmezés volt, hogy a HTML-formátumú levelekben lévő távoli szerveren tárolt képeket nem tölti le automatikusan, hanem rákérdez a felhasználónál, hogy letöltse-e azokat. Ha a felhasználó úgy döntött, hogy ne töltse le, akkor a feladó nem értesült róla, hogy a címzett a levelet megkapta-e. Viszont könnyen lehet, hogy a címzett egyszerűen nem tudta elolvasni a levelet, mert ilyen-olyan lényegi információk nem szöveges formátumban, hanem egy képre írva voltak a levélben, mint például egy szilveszteri parti helyszíne. Így ha a címzettet érdekelte a dolog, mindenképp le kellett töltenie a képet, mint külső tartalmat is. 

Ez még mindig az ókor. Aztán jöttek az ügyesebb hírlevélkézbesítő rendszerek, amik minden egyes címzett leveléhez külön-külön, egy egyedi, távolról letölthető képet is linkeltek. 

Azaz például, ha valaki feliratkozott pistike@example.org címmel, akkor a hírlevélküldő az adott címhez és hírlevélhez generált egy egyedi nevű fájlt a szerveren, mondjuk http://hirlevelkuldo.tld/track/d1a3c5382be1a69c57f7caccbb8c6858.gif 

ahol a fura nevű GIF, tipikusan 1x1 pixeles átlátszó GIF-fájl a HMLT-levélbe volt ágyazva és ha a fájl a levéllel együtt letöltődött a szerverről, akkor az egyértelműen bizonyította, hogy a pistike@example.org címre kiküldött hírlevél kézbesítődött és Pistike meg is nyitotta azt, természetesen azzal az információval együtt, hogy mikor. 

Az ilyen típusú állandó feedback mesterkéltnek tűnhet, viszont olyan hírlevelet küldeni, amire a felhasználó valaha feliratkozott, a levelezőrendszer nem vágja azonnal spambe, drágább mulatság, mint amilyennek tűnik, a hírlevél küldője pedig érthető módon tudni szeretné, hogy mennyi értelme van egyáltalán hírlevelet küldözgetnie. 

Ezen kívül voltak még ilyen-olyan torzszülött megoldások, mint például a HTML-levélbe ágyazott JavaScript-kód, ami elvben a levél megnyitásakor lefut, érthető módon kicsit is normális levelezőrendszer nem tette lehetővé az azonnali kódfuttatást a levél megnyitásakor. 

Azaz maradt a jó öreg 1x1 pixeles megoldás, ami persze nem csak hírleveleknél vethető be, hanem minden további nélkül egyénileg küldött leveleknél is. Számos szolgáltató van, ami lehetővé teszi ilyen levelek küldését, úgy, hogy a részletekkel a feladónak ne kelljen foglalkoznia, ami viszont közös bennük, hogy sosem garantálják 100%-ra a visszajelzést, de az esetek többségében igen.  Ezek közül egyet mutatok be, utána pedig azt, hogy mindez hogyan kivitelezhető sokkal geekebb stílusban, bármilyen szolgáltató igénybevétele nélkül. Ezen kívül feltételezem, hogy a levelezéshez a legtöbben Gmail-t használnak, azt is webes felületen keresztül – ott viszont gyakorlatilag mindig működik. 

http://www.getnotify.com/ oldalon egyszerűen csak regisztrálni kell azzal a saját email címünkkel, amelyikkel követett levelet szeretnénk küldeni, majd ha ez megvan, teljesen hagyományos módon megírhatjuk az emailt a címzettnek, nemes egyszerűséggel csak a címzett címének végére kell biggyeszteni a getnotify.com hosztnevet. Azaz ha a címzett pistike@example.org lenne, akkor a levelet a pistike@example.org.getnotify.com címre kell küldeni. 

A küldést követően a Getnotity a levelet átformázza HMLT-formátumúvá, akár HTML levél volt eredetileg, akár nem, majd elhelyez benne a kézbesítésre nézve teljesen egyedi nevű átlátszó fájlt, majd a levél fejlécét olyan módon módosítja, hogy levágja a .getnotify.com hosztnevet a cím végéről és továbbküldi a levelet a címzettnek. A címzett a levelet megkapja, megnyitja, a feladó pedig a Getnotify felületén keresztül értesül is róla, hogy a levél meg lett nyitva, mi több, ha a címzett a levelet többször is megnyitotta, az összes időpont szerepelni fog, amikor a levél meg lett nyitva. Hogy érthetőbb legyen, egy Gmail-es címre küldött levél kézbesítési reportja valahogy így néz ki: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Mint látható, a report szinte mindent mutatna, ami a kézbesítődéssel kapcsolatos, ráadásul külön-külön, amennyiszer megnyitotta a címzett a levelet, ebben az esetben persze a tesztlevelet egy saját gmail-es címemre küldtem. Gyakorlatilag viszont a levél megnyitásának idején kívül semmilyen értelmes adat nem hámozható ki például a címzett földrajzi hollétét illetően, mert annak helyén a Google szerverei által odamókolt adatok vannak. Mi lehet a magyarázat? 

A Google nagyon jól tudja, hogy a Gmailt a többség webes felületen keresztül használja, ugyanakkor azt is, hogy ha azonnal betöltenék a távoli tartalmakat, az egyrészt felfedné a felhasználó hollétét, az általuk használt platformot, ugyanakkor emellett nyilván igény van rá, hogy a HTML-formátumú emaileket a felhasználók el tudják olvasni úgy, hogy azokban megjelennek a képek is. Éppen ezért nem is olyan rég a Gmail-ben az lett az alapértelmezett beállítás, hogy a távoli tartalmakat is automatikusan betölti a levél megnyitásakor, viszont nem az eredeti helyéről, hanem előzetesen a képet a Gmail a háttérben gyorsítótárazza a GoogleImageProxy-n keresztül, majd innen töltődnek be a képek ténylegesen. Ekkor viszont természetesen a küldő rendszer nem a valódi címzett címét és egyéb platformjellemezőit látja, hanem a GoogleImageProxy-ét fogja naplózni. Nem megyek bele olyan finom részletekbe, hogy a Google természetesen a háttérben nem Windows XP-s gépeket használ Firefox böngészővel a gyorsítótárazáshoz. 

Persze mezei levelezőrendszer esetén, ha a HTML-levéllel távolról letöltődik az apró, átlátszatlan kép, a feladó teljesen valid információkat kap a címzett által használt platformmal kapcsolatban is, ez viszont szinte mellékes, ha a fél világ Gmailt, Outlook.com-ot és hasonlókat használ levelezéshez, amik a GoogleImageProxy-hoz hasonló megoldást alkalmaznak. A filléres és fapados levelezőfelületeknél, mint amilyen a Horde, Squirrel vagy a Roundcube, a rendszer ideális esetben rákérdez, hogy betöltse-e a távoli tartalmat, amit a felhasználó jó esetben csak akkor engedélyez, ha a feladó számára megbízható.  

Érdekesség, hogy az egyik legkomolyabb levelezőrendszer, a Microsoft Exchange alapértelmezés szerint úgy tölti be a levelek megnyitásakor a képeket, hogy nem is kérdez rá, hogy a távoli tartalmat letöltse-e. Az ok alighanem az, hogy meglegyen az a típusú kényelem, amiért egy-egy felhasználó elvár, ha a cége egy Exchange üzemeltetéséért fizet. Ott az Exchange előzetesen persze alaposan átvizsgálja, hogy a levél tartalmaz-e kártékony kódot, amit akár egy képbe rejtettek el, de nem proxyzza magukat a képeket, hanem letölti azokat az eredeti helyükről, így ha tudjuk, hogy a címzett Exchange-t használ a cégnél, ritkábban magáncélra, ott jobban jobb lesz a „találati arány”. 

Végülis mennyire megbízható konkrétan a Getnotify? 

A saját súgóoldalán ugyan azt állítja, hogy a címzett semmit fog észlelni abból, hogy egy követett küldeményről van szó, ez igaz is és nem is. Az átlag felhasználó valóban semmit sem fog észlelni belőle, kicsit is jobban megnézve viszont ordít a trackelt levélről, hogy az egy köztes átjárón lett keresztülpréselve valami miatt. Éppen a Gmail nemrég vezette be azt az újítást, hogy a feladó mellett egy törött piros lakatot helyez el akkor, ha a feladó rendszere nem szavatolta, hogy az email csak titkosított csatornán kézbesítődhet, márpedig a Getnotify esetén ez a helyzet. 

A részleteket megnézve pedig egyre büdösebb lesz a dolog: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Ami pedig már bizonyító erejű, ha megnézzük az emailt nyers formátumban, ahol nem csak az kerül ki, hogy a látszólag egyszerű szövegként küldött levél valójában egy egyszerű szövegnek tűnő HTML-levél benne egy-két érdekes képpel, ami sima nézetben nem látszik, hanem az is, hogy ha a feladó domain nevéhez DKIM-rekord tartozik, a fejlécben látható, hogy az sérült, lévén hogy a levelet valami út közben megváltoztatta, ez egyébként annak az esélyét is nagyban növeli, hogy a levél a címzettnél spamben landol. 

Összességében elmondható, hogy nem, bárki bármit is mond, máig nincs olyan csoda technika, ami biztosan szavatolná, hogy a levél olvasottságáról a feladó biztosan tudomást szerezzen, pláne nem úgy, hogy azt a címzett ne vegye észre, ha akarja, legalábbis hagyományos emailek esetében nincs és ez így van jól. Ez a technikailag meglehetősen egyszerű trükk viszont az esetek döntő többségében működik, csak személyre szóló levél küldésekor nem túl bizalomgerjesztő, ha a címzett észreveszi, hogy előzetes beleegyezése ellenére ellenőrizni akarta a feladó a levél olvasottságát, hiszen ahhoz vagyunk hozzászokva, hogy ez a címzett magánügye. Egy személyes hangvételű levélbe bele lehet varrni olyan linket, amiben valaminek a megtekintésére kérjük a feladót egy linken keresztül, ami persze olyan szerveren van tárolva, amihez a logjaihoz hozzáférünk, hiszen ekkor ugyanúgy szervernaplóba kerül a linkelt tartalom letöltése, csak éppen egyáltalán nem biztos, hogy kattintani is fog a linkre a címzett. 

Ami fontos, hogy olyan levelet, amilyet például a Getnotify.com készít, írhat bárki, aki olyan levelezőprogramot használ, amelyik támogatja a nyers HTML-szerkesztést, amiben csak egy saját tárhelyre mutató, akár láthatatlan képet lehet elhelyezni, ez lenne a kézműves megoldás. 

Megjegyzem, gyakorlatilag minden levelezőrendszerben tiltható, hogy a levél egyáltalán HTML-ben jelenjen meg vagy éppen az, hogy külső képeket töltsön be. Ha mégis ilyen levelet kapnánk, megbízunk a feladóban tipikusan néhány kattintással engedélyezhetjük a teljes megjelenítést. 

Mindegy, hogy a Getnotify-ről vagy szó vagy valamelyik másikról, a működési elve mindnek az, amit leírtam. A kukkoló funkciót különböző levelezőrendszerek esetén ezekkel a beállításokkal lehet teljesen hatástalanítani.  

Gmail esetén: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

AOL-on: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Zimbra rendszerben: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Horde-n: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Hushmailen: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Roundcube-on: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

Squirrelmailnél: 

email privacy magánszféra Gmail Horde Zimbra Roundcube Squirrelmail levelezés nyomkövetés

0 Tovább

Email biztonság, újragondolva – jelszó nélkül


Mióta az azonosításhoz használnak jelszavakat, gyakorlatilag ugyanaz a probléma velük: a felhasználó leírja, elhagyja, lenyúlják, lelesik, kölcsönadja, a jelszó túl gyenge és folytathatnám a sort. A blogon már többször is téma volt az egyre több helyen bevezetett többlépcsős, konkrétabban kétlépcsős hitelesítést valamilyen formában, azaz amikor a felhasználói nevünk és a jelszavunk, - mint két statikus azonosító – mellett meg kell adni még egy, egyszer használatos azonosítót is, ami például egy SMS-ben érkező token vagy egy mobilalkalmazás által generált, adott ideig érvényes számsor. Tanulságos, hogy ezt a netbankos rendszereknél vezették be először, majd jóval később, sorra azok a szolgáltatók, akiknél nagy mennyiségű információ tárolódik, mára pedig támogatja gyakorlatilag minden komolyabb webszolgáltatás.

Ami még érdekesebb, hogy a Yandex január táján gondolt egy nagyot és a nagy és ingyenes szolgáltatók közt elsőként opcionálisan olyan authentikációt tett elérhetővé a belépéshez, amivel a jelszó teljes egészében nélkülözhető: csak a felhasználói nevet kell megadni, a jelszót pedig képletesen egy olyan állandóan kulcs helyettesíti, ami végülis mindig nálunk van.

A beállítási folyamat meglehetősen egyszerű, az okostelefonunkra le kell tölteni a Yandex Key alkalmazást, majd a lépésről lépésre történő webes beállításkor megjelenő QR-kódot beolvasni vele, de megadhatjuk a képernyőn megjelenő átmeneti karaktersorozatot is. Jó, jó, de ezt eddig tudta többek közt a Google Authenticator, a Microsoft Authenticator, a Duo Mobile és a többi is, nem? Itt jön a csavar: a Yandex Key beállításához kötelezően be kell állítani egy négy számjegyből álló alkalmazás PIN-t is.

Innentől kezdve, ha megpróbálunk belépni a Yandex-fiókba, a Yandexen csak a felhasználói nevet kell beírni, majd a jelszó helyett a QR-kód ikonjára kattintani, ekkor egy QR-kód jelenik meg a képernyőn. Ezt be kell olvastatni a Yandex Key appal és a beléptetés megtörténik. Viszont! Abban az esetben, ha a Yandex Key megnyitása után hibás PIN-t adunk meg, szintén bescannelhető ugyan a QR-kód, viszont azzal a beléptetés nem fog menni és – ami a lényeg – ha valaki mondjuk az ellopott mobilunkkal próbálni így belépni, nem fog  tudni, mivel az alkalmazás PIN-t nem ismeri. Ha eddig nem lenne eléggé csavaros a dolog, az alkalmazás nem figyelmeztet érvénytelen PIN esetén sem, így a támadónak nagyon megnehezíti a dolgát, mert még ha neki is állna végigpróbálgatni a 10000 ismétléses permutációt, ami a PIN lehet 0000-9999 tartományban, nem fogja tudni könnyen megállapítani, hogy mikor talált.  

Akkor ez most végülis kétlépcsős hitelesítés vagy sem? Végülis igen, de eddig nem látott kivitelben. Jelszó helyett mindössze a négy számjegyű alkalmazás PIN az egyetlen fix elem, amire emlékezni kell, meg persze a saját felhasználói nevünk.

Természetesen a többi 2-FA megoldáshoz hasonlóan itt is van lehetőség alkalmazásjelszavakat létrehozni vagy visszavonni például levelezőklienshez, viszont vegyük észre, hogy a Yandex ezzel a módszerrel kiiktatta a felhasználók azonosításában örök problémát jelentő tényezőt, a statikus jelszót!

Abban az esetben, ha a mobil nem alkalmas QR-kód olvasására, a QR-kód helyett a webes belépésnél kérhetjük azt is, hogy egy egyszer használatos karaktersorozatot kelljen megadni, ami szintén a Yandex Key-en olvasható le.

Amíg nagyon bétában futott, tapasztaltam olyat, hogy nem sikerült belépni a helyes PIN ellenére sem, a hibát azóta már javították, az ok valószínűleg az volt, hogy a mobilalkalmazás más időzónát használt, mint ami a Yandex-fiókban be volt állítva. Hogy ennek mi a jelentőssége, azzal senkit sem büntetnék, erre lehet olvasni róla

A posztnak azt a címet adtam, hogy „Email biztonság”, mert a Yandexet évek óta elsősorban levelezésre használom. Viszont érdemes tudni, hogy az orosz google-nek is csúfolt webes óriás a levelezésen túl fájlhoszting szolgáltatóként is működik, van benne térképalkalmazás, webes fordító, naptár, gyakorlatilag minden, ami a Google-account vagy éppen Microsoft-accountok használatakor is elérhető.

Az ok, ami miatt a Yandex alig ismert Európa nyugati régióiban, egyszerű, konkrétan az, hogy nagyon sokáig nem volt elérhető angol nyelven, néhány éve viszont szinte minden szolgáltatását elérhetővé tették angol nyelven is. Ha először használod és oroszul jelenik meg, de nem tudsz oroszul, egyetlen kattintással állítható át a teljes felület angolra.

0 Tovább

Egy legendás levelezőrendszer esete a biztonsággal, na meg a felhasználókkal


"Celebrating our 15th anniversary with our new feature: Two-Step Verification" jelentette be a legendás Hushmail májusban a Twitteren, amit - kéretik figyelni! - mindössze egyetlen felhasználó favolt és retwittelt, én meg konkrétan nem vettem észre, pedig jópár éve hardcore hushmailes vagyok. Értem én, hogy a jó munkához idő kell, de ha egy olyan levelezőrendszernél, aminek a születésénél maga Zimmermann, a PGP titkosítóalgoritmus atyja bábáskodott, IMHO máig az egyik legbiztonságosabb levelezőrendszer a világon, gyakorlatilag le vannak maradva az end-user szemében a többiekhez képest, na, az nem jó. Nem jó, mert 2FA téren megelőzte őket az összes nagy, látszólag ingyenes, a felhasználók adataiból élő kommersz mailszolgáltató  Google Mail - Yahoo - Outlook.com sorrendben, ahogy az egy-egy újításnál lenni szokott. Szóval Hushmailék  túl kevéssé kommunikálták a történetet. 

Az, hogy beelőzték őket, még a kisebb probléma: a PRISM-parát meglovagolva ugyanis egy rakás "überbiztonságos", semmiből előtűnő freemium modellel működő vagy előfizetéses levelezőszolgáltatás jelent meg a piacon, amik jó esetben nem zárják be a boltot maholnap és tipliznek a Bahamákra az ügyfelek pénzével ill. jó esetben ezeket a szolgáltatókat nem valamilyen szépnevű hárombetűs szervezet fedőcége vagy nehézsúlyú adathalászok hoztak létre pont azoknak a megfigyelésére, akik éppen azért fizetnek, hogy a levelezésük ne legyen látható. 

Fejtegethetném, hogy nem, nem csak akkor van szükséged elfogadhatóan biztonságos levelezésre, ha egy jó nagy cég vagy hírportál vezetője vagy (egyébként is, 5-10-15 év múlva még lehetsz és igen, 5-10-15 év múlva is valakinél meglesz levelezésed), az meg sokkal cirkalmatosabb téma, hogy mikor is tekinthetünk egy levelezőrendszert biztonságosnak, ugyan egy részét itt már érintettem korábban. 

Az átlag felhasználótól nem várható el, hogy megállapítsa egy levelezőszolgáltatásról, hogy mennyire biztonságos, elég csak rákeresni a neten, hogy melyik is a legbiztonságosabb levelezőrendszer a világon és belenézni az első néhány találatként talált fórumba. Ezt a tudatlanságot kihasználva szedte meg magát egy rakás, elvben biztonságosnak tűnő levelezést kínáló startup olyan jól hangzó, ámbár szakmai szempontból még debilebb érvekkel, minthogy a szervertermük be van fúrva egy hegy gyomrában, skandináv országban/Svájcban van, amire kevésbé lát rá az NSA vagy éppen azzal érvelt a szolgáltató, hogy saját titkosító algoritmust fejlesztett ki, de hogy mi az, na, azt nem árulja el. Ha nem vagy terrorista, a levelezést amúgy nem az NSA-tól kell félteni, hanem mondjuk egy üzleti versenytárstól, aki alighanem meg tud fizetni olyan szakit, aki technikai tudással és/vagy kapcsolati tőkével szinte bármelyik szerverbe bele tud nézni, ha eleget fizetnek neki. Eloszlatnám azt a közhelyet, hogy "minek foglalkozni vele, mert úgyis feltörhető", tökéletes biztonság nincs, viszont elfogadható biztonság igenis van. És általában nem a legdrágább megoldásokkal. 

Ha egyéni felhasználóként vagy cégvezetőként arról szeretnél informálódni, hogy mi az, ami tényleg biztonságosnak tekinthető, ne a zöldségest, hentest vagy a szomszéd neandervölgyi kinézetű, informatikus végzettségű photoshop-artistát kérdezd, hanem olyat, aki ért is hozzá, mondjuk mert ez a hivatása. Ha a netről informálódnál, az csalóka lehet, ugyanis az ezzel kapcsolatos netes keresésnek csak akkor van értelme, ha pontosabb képed van róla, hogy mit is keresel, azaz az értékes információhoz nem meglepő módon eleve jól kell feltenni a kérdést. 

Securityreactions tumbliról schmittelt képpel zárnám soraimat: 

"Why aren’t you worried about the NSA spying on your internet use or emails?"

0 Tovább