bardóczi ákos @post.r

Még nem tudni, hogy milyen újdonságok várhatóak a megújuló freemail.hu-tól, viszont elvben elképzelhető lenne az is, hogy világszerte használt óriás levelezőrendszerek versenytársa legyen. Ehhez persze szükség lenne angol nyelvű változatra, ezen kívül olyan feature-ökre, amiket más, mezei levelezőrendszerben nem talál meg a felhasználó.

Összegyűjtöttem néhány ötletet, közben pedig négy szempontot tartottam előtérben, mégpedig az egyszerűséget, a felhasználói élményt, máshol nem látott, haladó funkciók elérhetővé tételét és azt, hogy mindezt viszonylag egyszerűen le is lehessen programozni. Ezen kívül feltételeztem, hogy a felhasználók legalább egy nagyobb közösségi szolgáltatásban már regisztráltak. Az ötletek egy része az agyamból pattantak ki vagy egy enterprise level levelezőrendszerben, esetleg közösségi szolgáltatásban találkoztam velük, míg néhányat más levelezőrendszerekből loptam át. A feature-öknek önkényesen még egy-egy fantázianevet is adtam néhol, persze minden extra funkció opcionális lenne.

A felhasználói élményt és kényelmet fokozó lehetőségeket soroltam előre, míg az inkább technikai vagy haladó felhasználók számára érdekeseket a végére.

A felhasználók időnként hiányolják azt, hogy egy levél nem vonható vissza, amit egyszer elküldtünk, az kézbesítődik is, ha tud, viszont egyre több levelezőrendszernél bekapcsolható olyan lehetőség, ami azt a benyomást kelti, hogy a levelet vissza lehet vonni. Ilyen esetben nem valódi visszavonásról van szó, hiszen az eleve lehetetlen, hanem arról, hogy a levél bekerül egy várakozási sorba, majd ha a felhasználó nem gondolja meg magát, akkor történik meg a levél tényleges kiküldése. A funkció beépíthető lenne olyan módon, hogy a felhasználó beállítja, hogy a levél percben mennyi ideig tanyázzon a Kimenő mappában, ha addig nem gondolja meg magát, a levelezőrendszer már küldi is.

Gondolom sokakkal előfordult már, hogy vasárnap hajnalban, sakálrészegen álltak neki SMS-t vagy email írni, amit azt alaposan megbántak. Korábban erre a problémára kínált megoldást a Google Labsból a Gmail-hez elérhető kiegészítő Mail Goggles néven. Lényeg, hogy a Freemail [Másnap] funkció bekapcsolásával előre beállított nehézségű, de alapvetően fejben elvégezhető matematikai feladatok közül kellene ötöt megoldani egy perc alatt, a megfogalmazott levelet pedig a rendszer csak akkor engedné elküldeni, ha ezt az akadályt sikerrel vitte a felhasználó. Beállítható lenne egy időintervallum, amikor ennek mindenképp működnie kell, azaz hétvégén estétől hajnalig. A funkció lényege, hogy ha a józanul seperc alatt megoldható feladatokat nem sikerül megoldani részegen, akkor az a felhasználók többsége számára egy nyomatékos figyelmeztetés önmaguk felé, hogy akkor nagyon nem lenne érdemes üzenetet küldeniük.

Ma már minden valamire való szolgáltatástól elvárható, hogy legalább a legnagyobb social media felületekkel összedrótozhatóak legyenek. Ennek megfelelően ha a felhasználó a Freemail [Szülinap] funkciónak megengedné, hogy hozzáférjen a facebookos/Google plusos ismerőseihez, így az ő születési dátumukhoz, és beállítana egy előre megadott sablont, a Freemail [Szülinap] az ismerős email-címére automatikusan születésnapi köszöntő üzenetet tudna küldeni – még akkor is, ha mi simán elfelejtenénk. Persze érdemes lenne elvégezni azt a finomhangolást, hogy az összes ismerős kaphasson automatizált köszöntőt vagy csak az ismerősök egy bizonyos köre.

Ismerve, hogy a felhasználók átlagosan mennyi időt töltenek más közösségi szolgáltatásokban, ha már az összekapcsolás megtörtént, hasonlóan ahhoz, ahogy beállítható a Skype-kliensünkben, hogy ott is megjelenjen az, ami a Facebook-falunkon, a Freemail [Social]-lel megoldható lenne, hogy az oldalsávban a facebookos, twitteres, linkedines falunk tartalma pörögjön vagy éppenséggel egy RSS-feed.

Gyakori jelenség, hogy egy levelet félrecímeznek, nem véletlenül van minden levelezőrendszerben automatikus kitöltés a címzett mezőhöz. Viszont ha a levelezőrendszer még látja is a különböző szolgáltatásokban lévő kontaktjainkat, az első címzés után felajánlaná, hogy egy arcot kapcsoljunk az automatikusan mentődő címhez. A további levélküldést pedig többféleképp tenné egyszerűbbé.

A félreküldést küszöbölné ki és a címzést tenné kényelmesebbé, ha egy gyorskeresővel ellátott oldalpanelben az apró avatarképpel és névvel látszó ismerős nevére kattintva a levelezőrendszer autofillezné a címzett mezőt, ha korábban a levelezőpartnernek küldtünk levelet – a lényeg a képen van! Itt megjegyzem, hogy nem a Gmail sajátossága, hogy betölti a feladó fotóját is, ha tudja, a Gravatar [Globally Recognized Avatars] szolgáltatásban szinte már mindenkinek a fotója fenn van – legfeljebb nem tud róla – ennek megfelelően pl. a Fastmail és a Yandex Mail is megjeleníti webes felületen a feladó képét, ha az elérhető az email címe alapján. Ha pedig ilyen módon az avatar betöltése nem lehetséges, a rendszer lepecázhatná a képet egy olyan közösségi szolgáltatásból, amivel már összekapcsolta a felhasználó, illetve ha valakinek a profilja kívülről is látható, még erre sem lenne szükség a kép megjelenítéséhez.

Egy Freemail [Időzítő] lehetőséget bekapcsolva megoldható lenne, hogy egy előre megírt levelet a Freemail adott időpontban küldjön ki, ez ha nappalra van beállítva, egy fontos címzett mobilja akkor sem vinnyogna, ha a levelet az éjszaka közepén írtuk meg neki, de fontos, hogy mielőtt megkapja, azaz például reggel, amikor már esetleg nem vagyunk gép előtt.

Szintén hasznos kényelmi szolgáltatás lenne, ha egy oldalpanelből egy levelezőpartner nevére kattintva egyszerre lenne megjeleníthető az összes tőle érkezett és neki küldött levél.

A fontos, megválaszolandó levelek csillagozása hasznos dolog, viszont ha közben érkezik egy rakás levél és a megcsillagozott nincs a felhasználó szeme előtt, nagyobb valószínűséggel fogja elfelejteni. Így beállítható lehetne, hogy a felső vagy az alsó sávban a rendszer jelezze, hogy mennyi fontos levél várakozik még és azok egy kattintással a figyelmeztetősávból elérhetőek lennének.

Több levelezőrendszerben már rég alapszolgáltatás, hogy ha a levél szövegében előfordul például az a szó, hogy „CV”, „életrajz”, „csatolt” vagy bármi, aminél valószínűbb, hogy valamit valóban csatolni terveztünk a levélhez, de mégsem tettük, a levelezőrendszer a küldés gombra kattintás után rákérdez, hogy nem felejtettünk-e el mellékletet csatolni a levélhez esetleg.

A Freemail [Metatag] a kimenő, bejövő levelek feladóinak nevéből, a tárgyban előforduló szavakból, benne előforduló linkekből és különböző tartalmi elemekből generálhatna egy halmazt, aztán pedig a metacímkéket oldalpanelen megnyitva gyakoriságuk sorrendjében mutatná azokat, valamint ugyanitt kereshetőek is lennének. Így például előkukázható lenne az összes olyan levél, ami esetleg teljesen különböző feladótól jött teljesen különböző okból, de szerepel benne például a „pályázat” kifejezés.

Ha már metáknál tartunk, a Freemail [Sherlock] az előző elven működne lényegében, de nem a gyakori, releváns, hanem épphogy a legritkább kifejezéseket, szokatlan szófordulatokat gyűjtené össze. Így például be lehetne saccolni, hogy nem azonos-e esetleg a feladója két, különböző címről és névvel küldött levélnek, még akkor is, ha a levelek több éves időbeli különbséggel érkeznek.

Ha már úgyis bölcsészkedésnél tartunk, a leveleket opcionálisan fel lehetne dobni a Freemail [Coelho] bekapcsolásával, ami az aláírás elé vagy után tenne valamilyen rémes közhelyet Freemail [Coelho] aláírással. Ugyanezen az elven lehetne egy beépített mémgenerátor is, ahol a felhasználó kiválaszthatná egy jól ismert mém képét, amire a Freemail [Coelho] automatikusan rátenne egy feliratot a levél tárgya alapján, amit persze a felhasználó szerkeszthetne, majd pillanatok alatt hasonlóan az aláíráshoz illeszthetne.

Egy levelet PDF-be exportálni nem egy nagy bravúr, viszont teljesen más a helyzet, ha ez a lehetőség egyetlen klikkel elérhető. A Freemail [PDF] bekapcsolása után egyetlen kattintással a levelezőrendszer elkészíthetné a levél PDF másolatát és már kérdezné is, hogy hova mentse le. Ennek lenne egy másodlagos funkciója is: nagyon sok helyen a HTML formátumú levelekben lévő képek nem töltődnek be automatikusan adatvédelmi okból, hiszen ilyenkor a levél feladója láthatja, hogy a címzett a levelet elolvasta és azt is, hogy honnan, milyen operációs rendszerrel, milyen böngészővel, hiszen a kép végülis egy külső webszerverről töltődik be, ami ugye naplózza a letöltéseket, így a képek letöltését is. Ebben az esetben viszont a Freemail egyik IP-címét tudná csak naplózni, hiszen az tölti le önmagának és nyomtatja ki PDF-ben a levelet képekkel együtt.

Az automatikus mentés elemi minden olyan felületen, ahol szöveget írunk. Viszont előfordulhat, hogy egy átfogalmazott szöveg sokkal rosszabb, mint az eredeti és egy 10 perccel korábbi változatát szeretnénk előszedni. Ha a levelet a rendszer percenként mentené, akkor egy 25 percen keresztül fogalmazott levél esetén, percenkénti mentéssel persze 25 példány lenne a piszkozatok közt, ami persze eltűnik, amint a levelet elküldtük, addig viszont egy tetszőleges, korábbi változat előkukázható, ami sokkal egyszerűbb, mint a visszavonás gombbal játszani, hiszen lehet, hogy olyan szövegrészt is eltüntetünk vele, amit viszont szeretnénk meghagyni. A Freemail [Croquis] megoldaná.

Előfordulhat, hogy nem vagyunk otthon, egy publikus gépet használunk, valamilyen kisebb vagy éppen óriási fájlt le szeretnénk tölteni magunknak későbbre, viszont nincs nálunk pendrive sem, sem más egyéb, ráadásul még a netkapcsolat is siralmasan lassú, esetleg a tartalmat helyben le sem lehetne tölteni. Ekkor a Freemail [Crawl] használatával a Freemail a megjelölt URL-ről letöltené saját magának a tartalmat, amit ésszerű ideig tárolna, otthon le lehetne tölteni, majd küldene a levelező egy figyelmeztetést, hogy a félretett fájl meddig tölthető le, hasonlóan az ún. óriáslevelekhez, ahol a csatolt fájl szintén nem magában az emailben van, hanem fel van töltve a levelezőszolgáltatás tárhelyére.

Ha már tárhely, igaz, hogy ez nagyban függ attól, hogy az adatok tárolása hogyan van megoldva, szolgáltatói részről lehet, hogy praktikusabb lenne, ha a felhasználók nem kapásból 10 GB-t kapnának, hanem a regisztrációkor mondjuk 500 MB-t, ami aztán a felhasználói használati szokásaihoz alkalmazkodva – például a levelezőben töltött idő, a regisztráció óta eltelt idő és a forgalom függvényében - növekedne, ahogy ez működött régen a Yahoo levelezőjénél is.  

Hasonlóan egyrészt a felhasználót és a szolgáltató erőforrásait is védené, ha beállítható lenne, hogy a különböző mappák mennyi ideig tárolják a leveleket, a megadott idő lejárta után pedig törlődjenek, kerüljenek a kukába vagy kerüljenek át tömörített archívba, amit a belső keresőnek már nem kellene indexelnie.

Az előző megoldás mellett vagy helyett bevezethető lenne az a funkciói is, ami disaster prooffá teszi a levelezést, hasonlóan a nagyvállalati megoldásokhoz, csak éppenséggel fapados kivitelben: ha például a alicebobandeve@freemail.hu cím regisztrációjakor létrejönne egy alicebobandeve-bak@freemail.hu fiók is, aztán abba minden kimenő és bejövő levelünkből érkezne egy-egy példány, a néhány napnál régebbi leveleket pedig a rendszer alaposan betömörítené. Ekkor, ha valaki véletlenül törli az összes levelét mondjuk egy elszart  POP3-letöltéssel, az egész előkukázható lenne a másik fiókba való belépés után és nem kellene a szolgáltatónál könyörögni a mentésért, ezen kívül ha valaki más felhasználó fiókjába belépve a nevében küldene levelet, annak egy ilyen backup fiókban ugyancsak nyoma maradna, hiába törölné a támadó a levelet a kimenő levelek közül.

Tudjuk, hogy nagyon gyakori, hogy valaki egész egyszerűen úgy hagyja a gépét használat után mondjuk nyilvános helyen vagy iskolában, így utána bárki odaülhet, aztán úgy trollkodhat a másik fiókjában, ahogy csak akar. Ezt a kockázatot többféleképp lehetne csökkenteni. Ha mondjuk a felhasználó be akarna keményíteni, akkor beállíthatná, hogy egy-egy levél megnyitásához, új levél küldéséhez vagy a beállítások átállításához ismét be kelljen írni a jelszót valahány perc inaktivitás után. Inaktivitás alatt itt azt értem, amikor a felhasználó nem navigál el másik felületre mondjuk 1 percig.

A belépéskor opcionálisan lehetne kétlépcsős azonosítás, amiről itt a blogon már többször írtam, illetve a Yandex megoldásához hasonlóan mondjuk Freemail [Kulcs] mobilapp, ami az alkalmazás előre beállított PIN-kódjának megadása után kiköp egy olyan karaktersorozatot a felhasználó okosmobilján, ami érvényes belépési jelszó 1 percig. A hagyományos jelszólopással kapcsolatos kockázatot egy csapásra kiküszöbölné.  Az más kérdés, hogy ha valakinek a fiókjába nagyon be akarna lépni valaki, akkor ellopná az okosmobilját, miután leleste a Freemail [Kulcs] mobilalkalmazás PIN-jét...

Hasonlóan, a felhasználó a Freemail [Kulcs] vagy adott számra küldött SMS segítségével azonnal le tudná zárni a felhasználó a fiókját /*kényszerített átmeneti jelszó + minden aktív session lezárása*/, amint tudomást szerzett róla, hogy valaki belépett a fiókjába, majd az otthoni gépén fel tudná oldani a blokkolást.

A levelezőrendszerek körében szintén eléggé eredeti lenne, ha kiiktatható lenne a jelszóemlékeztető kérdés lehetősége [igaz, ezt most sem kötelező megadni], ami ugye nagyobb kockázatot jelent, mint amennyire a biztonságot fokozza, le lehetne tiltani, hogy másodlagos email-címre jelszóhelyreállítot küldjön a rendszer. Viszont meg lehetne adni 3-5 ismerős email címét, akik kapnának egy-egy rövid karakterláncot, majd ezeket külön-külön megkapná a fiók tulajdonosa, összeillesztené és csak úgy tudna új jelszót beállítani, ha már kicsukta magát. Na, ezt az ötletet a Facebooktól csentem.

A kényelmet nagyban fokozó szolgáltatás lenne, ha a Freemail [IMAP]-pal meg lehetne adni más postafiókunk IMAP4-elérését. Az ilyen módon bedrótozott külső postafiók egy új mappaként jelenne meg a Freemailben, de nem töltené le az összes levelet a másik helyről fölöslegesen, hanem hasonlóan a jól nevelt levelezőprogramokhoz csak a levelek fejlécét. Aztán az töltődne át ténylegesen, amit a felhasználó meg is nyit. Ezen kívül a Freemail-ből a külső fiókba lehetne átmásolni leveleket az IMAP-os mappába másoláson keresztül. A Freemail ilyen módon levelezőkliensként is működne, viszont nem zabálná a tárhelyet.

A Freemail [fancy] bekapcsolásával a Freemail magától generálna egy ékes-grafikus aláírást, ami a social webes elérhetőségeinket is tartalmazza, ha engedélyeztük azt. Hasonló elven, amikor levelet kapunk valakitől, a rendszer előkukázná az illető LinkedIN-profilját név vagy email-cím alapján és mutatná is az oldallécben, ahogy erre a Microsoft Exchnage-ben és a Google Appsben egyaránt van lehetőség egy kiegészítővel.

Persze, persze, az emailjeink aláírása lazán átszerkeszthető a beállításoknál, viszont ha bekapcsolható lenne a Freemail [szignó]-n keresztül több aláírás, a levél megírása után, alul, legördülő menüből választhatnánk ki, hogy az adott levél aljára melyik kerüljön, esetleg ne is legyen aláírás.

Az Out of Office jó ötletnek tűnt, amikor kitalálták, viszont ha valaki elmegy nyaralni, aztán minden, levelezőlistán keresztül neki is kézbesítődő levélre automatikusan küld Out of Office választ, az már zavaró lehet. Ha pedig spammernek, akkor kínos, mert a spammer biztos lesz benne, hogy élő postafiókot talált be. Kifinomultabban a Freemail [OOO]-val be lehetne állítani, hogy csak bizonyos, például címjegyzékben lévő, nem levlistás címzettek felé küldjön automatikus választ a távollétről.

A Thunderbird Display Mail User Agent addonjához hasonlóan a Freemail [Spy] egy kis ikonnal jelezné, hogy a feladó milyen levelezőrendszerből küldte a levelet, aminek még nem lenne önmagában túl sok értelme, ugyan innen gyanítható lenne, ha a feladó címét meghamisították, ha például egy Yahoo-s logo virít egy bme.hu-s cím mellett. Ha ez kiegészülne olyan funkcióval, ami azt is mutatja, hogy a levelet földrajzilag honnan küldték, na, az aztán igazán főnök lenne. A https://www.iplocation.net/ -ról elérhető adatbázisok valamelyikét lehetne alapul venni, aztán pedig adatforrásként a levelezőrendszernek csak ki kellene olvasnia a hosszú fejléc sorai közül a küldői IP-címet tartalmazó X-Originating-IP értéket vagy ha ilyen nincs, akkor a megfelelő Received: sort, ahol, ha máshogy nem, a hostname reverse alapján adódó IP-címhez tartozó országot alapul vennie – persze a helymeghatározás hibás lesz, ha az így következtetett ország időzónája és az az időzóna, amit ugyanúgy tartalmaz a hosszú fejléc, nem egyezik. Az esetek többségében viszont mutatná, hogy melyik városból jött a posta. Az esetek döntő többségében működne. Nos, mivel a szolgáltatás olyan adatokkal dolgozik, amit eleve megkapott a hosszú fejlécben, ezért annyira azért nem lenne emberiség ellenes dolog kiírni a valószínűsített várost vagy országot.

a freemail - igencsak rég

Réges régen, talán igaz sem volt, a két nagy levelezőóriásnál be lehetett állítani, hogy a postafiókunkat a saját domain-nevünkkel használhassuk, aztán először a Google jelentette be, hogy a Google Apps free változatát nem támogatják tovább nem sokkal később pedig a Microsoft tett ugyanígy.

Mondjuk freemium változatban a saját domain beállítható például a mail.ru-n – feltéve, hogy valaki eléggé jól tud oroszul – vagy az Oroszországból érzékeny dolgokat kitelepített Yandexen, ha pedig valaki echte ámerikai megoldáshoz ragaszkodik, a Zoho Mail 10 felhasználóig ingyenes saját domain névvel. Nos, elvben a Freemail eléggé nagyot dobbanthatna, ha lehetne saját domaint beállítani a levelezéshez, de például olyan módon, hogy a full ingyenes változatban ott virít a Freemailt promózó sor a saját domaines címekről küldött levelek végén, míg néhány garas befizetése után már nem.

Egy közösségibb dolog lenne az opcionális Reblog oldaldoboz, ahova a felhasználó néhány klikkel tudná hajigálni a hírlevelekben érkező, érdekes híreket vagy linkeket egy-egy mikroblogposztba.

Mind küldtünk már levelet olyannak, akiről tudtuk, hogy a postafiókjába csak az nem lát be, aki nem is akar, de a dolog elkerülhetetlen volt. Erre frappáns megoldás lenne az önmegsemmisítő levél, ami végülis egy Freemail-tárhelyen tárolt levél lenne, a címzett pedig csak egy linket kapna, amire kattintva a levelet el tudja érni. Be lehetne állítani, hogy a levél az elküldéstől számítva, valamint a megnyitástól számítva mennyi ideig lehet olvasható, így talán még a legkreténebb, nulla biztonságtudatossággal és a teljes céges adatvagyonnal rendelkező CEO-t is sikerülne megvédeni önmagától :)

A biztonságot ugyan nem, de geek-faktort fokozná egy Freemail [Wordcloud], amelyik az adott szövegben lévő szavak gyakorisága alapján az aljára legenerálná a levélre jellemző szófelhőt, aztán jót röhögni rajta. Ha még nem játszottál ilyennel, erre tessék szórakozni erre vagy éppen erre.

Volt már róla szó, hogy a teljes iparág mennyire rápörgött az emailek titkosítására, aztán megjelent egy rakás levelezőszolgáltató, amelyik webes felületen keresztül nyújtott PGP-szolgáltatást, magyarul újra feltalálták a kereket. Hogy mást ne mondjak, a szanaszét hype-olt Protonmail 14 évvel (!!) később újra feltalálta a Hushmailt.

Viszont aki levelezéshez használt Horde rendszert, tudja, hogy ott is van lehetőség PGP-kulcspárt importálni, aztán úgy titkosított leveleket küldözgetni, az más kérdés, hogy ha a privát kulcs nem csak a végponton van meg, az pont a PGP koncepcionális lényegének lábbal tiprása.

Ugyanakkor ha minden, így a levelezés is a weben van, igény van rá, abban pedig bízzunk, hogy a kulcsot a szerver tényleg eléggé ellophatatlan módon tárolja. A Freemailbe simán be lehetne építeni olyan funkciót, ami lehetővé teszi a PGP-kompatibilis titkosítás és digitális aláírást – legalább megismerik többen, hogy mi a jóég az a PGP – és lenne rá lehetőség, hogy a felhasználó a privát kulcsát törölje a Freemail szerveréről és a saját gépén tartsa, amit együtt tudna használni bármilyen levelezőklienssel. Illetve ha weben használná a PGP-t, a Freemail levele letöltődne kliensoldalra, a felhasználó titkosítaná vagy aláírná a böngészőben a privát kulcs betöltése mellett, majd a kliensoldal visszaküldené szerveroldalra és úgy küldené a levelet.

Lehet, hogy amit leírtam, azok közül többminden olyan dolognak tűnik, ami túl kevés felhasználót érdekelne ahhoz, hogy érdemes legyen leprogramozni, viszont ami biztos, hogy felfigyelnének a sokat látott Freemailre, másrészt nemzetközi színtéren a felhasználók „kis része” nem is jelentene annyira kevés felhasználót. Ekkor persze alaposan megváltozna az üzleti modell, a rendszert angol nyelven használó felhasználók miatt, akkorát menne’ a dolog, amekkorát magyar levelezőrendszer még nem.

Képek: Gravatar, Iminet, ic.co.uk

Microsoft OneDrive, Google Drive, MEGA, Yandex Disk, Apple iCloud vagy Dropbox? Nem, nem fogok írni sokak után egy ezer plusz egyedik cikket arról, hogy ezeket összehasonlítgassam, inkább írok arról, hogy milyen szempontok alapján érdemes fájlhoszting szolgáltatót választani személyes célra.

Sokakkal előfordult már, hogy otthon felejtettek egy fontos pendrive-ot, esetleg ellopták a gépét vagy más módon, de fontos adatokat vesztett el, amikről ugye a felhasználó sosem készít mentést, amíg először meg nem történik a baj. A cloud fájlhoszting szolgáltatók ugyan ezt a problémát gyakorlatilag egy az egyben ki tuják küszöbölni, használják is egyre többen, viszont nagyon nem mindegy, hogy melyiket, több szempontból sem.

Nagyon gyors felzárkóztatóként írom, hogy ezekhez a szolgáltatásoknak része egy gépre telepíthető kliensprogram, amivel ki lehet jelölni azokat a mappákat a gépen, amiket szeretnénk a saját gépünk mellett a felhőben is tárolni. Azaz ha egy ezen belüli fájlt módosítunk, a módosítás  szinte azonnal megtörténik a felhőben tárolt példányon is, hasonlóan minden  más fájlművelethez, azaz az egész olyan, mintha egy hálózati meghajtó lenne. Itt most a személyes használatra szánt szolgáltatásokkal fogok foglalkozni, főleg információbiztonsági és stabilitási szempontból, de emészthetően.

Ahhoz képest, hogy mennyi fájlhoszting szolgáltató van meglepően kevés az olyan, aminek a freemium változata szerintem megfelel az átlagos felhasználói igényeknek és azoknak a biztonsági követelményeknek, amiket ha mindenki követne, egy boldogabb világban élnénk.

Korábban már írtam róla, hogy a PRISM-para után számos semmiből előtűnő netes cég, legyen szó levelezésről, fájlhosztingról vagy csevegőprogramról, úgy fogta ki a szelet a vitorlából, hogy a felhasználók tájékozatlanságára építve olyan ostobaságokkal bizonygatta azt, hogy ők aztán tényleg a legbiztonságosabbak, mint például hogy a szervereik valamilyen egzotikus országban vannak, ahova nem ér el sem az EU sem az USA mocskos mancsa /*#LOL!*/, illetve egymást akarták túllicitálni azzal kapcsolatban, hogy a szervereiken milyen erősségű titkosítás mellett tárolják a felhasználóik adatait.

Nos, több tárhelyszolgáltató valóban megvalósította, hogy a felhasználó amikor adatot feltölt, azt kliensoldalon a kliensprogram vagy a böngésző titkosítja, eleve titkosítva tolja fel a szerverre, a szerver azt tárolja, amikor pedig a felhasználó letölt a tárhelyéről, letöltődik a szerverről az igencsak erősen titkosított adatmassza, amit a felhasználó a saját kulcsával, amit jelszó véd, szépen kibont. Eléggé gyorsan belátható, hogy ugyan ilyen esetben nyilván a szolgáltató sem látja, hogy milyen adatot is tárolnak nála ténylegesen, viszont egyrészt nagyban korlátozza a lehetséges kényelmi szolgáltatásokat, másrészt eszközfüggő ugyan, de a fájlok szinkronban tartását lassabban végzi. Harmadrészt pedig olyan kockázat ellen véd, aminek a bekövetkezési esélye meglehetősen kicsi, nevezetesen, hogy valaki közvetlenül a szerverhez férjen hozzá valamilyen módon, aztán arról emeljen le adatokat, amihez ugye eleve tudnia kellene, hogy egy sok(tíz)ezer gépből álló privát cloudban melyik gép is az, amelyiken az ellopni, hatóságok esetében pedig lefoglalni kívánt adat van. Nos, igen, a jó öreg MEGA-ra gondolok, amivel végfelhasználói szempontból a legnagyobb para látszólag paradox módon éppen az, hogy nincs lehetőség jelszóhelyreállításra vagy a fiók teljes törlésére, ha a felhasználó nem tud belépni. Az viszont igenis életszerű, hogy valaki az áldozat  MEGA-jelszavát egy keyloggerrel ellopja, belépés után megváltoztatja, a fiók tulajdonosa pedig nem tehet semmit.

A MEGA-t azért emeltem ki, mert a legbiztonságosabb szolgáltatónak tartják, elméletben az is, gyakorlatban viszont épphogy ezért nem.

Ha belegondolunk a jelszólopás rizikója miatt, a felhasználói név és jelszó páros egy-egy belépéshez mindenhol édeskevés, pláne abban az esetben, ha az összes dokumentumunk fenn tanyázik a fellegekben, ugyanakkor a többlépcsős hitelesítést aminek a legegyszerűbb megvalósítása, hogy a felhasználói néven és jelszón kívül egy SMS-ben érkező vagy mobilapp által generált, fél percig érvényes tokent is meg kell adni belépéskor, ha olyan eszközről lép be, amiről korábban nem lépett még be. Azaz az azonosítás kétlépcsős, 2-FA. Viszont egy kezemen meg tudom számolni, hogy hány normális fájlhoszting szolgáltató van, amelyik ezt lehetővé is tenné, legalábbis a freemium változataiban.

Nem teljesen mindegy, hogy szerveroldalon az adat mennyire titkosított abban az esetben, ha egy közönséges jelszólopással is elérhető mind a kliensoldalon keresztül? Na ugye! A saját fájljainkhoz tipikusan csak a saját eszközeinkkel szeretnénk hozzáférni, ugyanakkor a jól kialakított 2-FA lehetővé teszi, hogy ha idegen gépen kell belépnünk egy fájl eléréséhez, a munkamenet egyszeri legyen, azaz más gépén ne jegyezze meg a böngésző, mint saját eszközt. Tehát a 2-FA elemi feature kell, hogy legyen!

A MEGA-t még akkor kezdtem el használni, amikor nekem alkalmasabb még nem volt, nemrég az átköltözésnél pedig volt szerencsém kipróbálgatni a komolyan vehető alternatívákat, amikkel kapcsolatban azt tapasztaltam, hogy több téren éppen arra alkalmatlanok, amire kitalálták őket.

Szép dolog, ha nagy az ingyenesen használható tárhely, ez viszont teljesen mellékes, ha nem talicskával hordjuk fel a HD pornót, hogy ne a gépen foglalja a helyet, hanem valóban dokumentumokat, forráskódokat és fotókat tárolnánk rajta, ami pedig nyilván sok apró fájlt jelent, amit a szolgáltató esetleg egyszerűen nem tud kezelni. Márpedig tényleges felhasználói adatból átlagosan 10-20 GB-nál több aligha van, aminek folyamatosan frissnek is kell maradnia.  

Google szolgáltatást a Youtubeon kívül elvből nem használok ugye, viszont eleve titkosított fájlokat próbáltam feltolni a Google Drive-ba, aminek a kliensprogramja az első volt, amelyik egyszerűen megadta magát, mivel nem tudta kezelni a túl sok fájlt a feltöltésnél. Kiírta ugyan, hogy behalt, azt már nem, hogy milyen fájloktól dobta el az agyát. Viszont abban az esetben, ha valakit nem zavar, hogy a Google-felhőben tárolt adatok olyan infrastruktúrán működnek, aminek a kialakításánál a költséghatékonyság volt az egyik fő szempont, a Google semmiféle felelősséget nem vállal egy-egy adatvesztés miatt, hajrá! Ugyanakkor a Google Drive jól teljesít nagy méretű fájlok feltöltésénél, de itt különösen igaz, hogy a felhőbe eleve titkosítva kellene feltolni az adatot. A Google mezei és üzleti felhasználásra szánt Google Apps változata közt semmiféle lényegi különbség nincs.

A Google Drive szerveroldalon ugye nem titkosít. Hogy miért eleve titkosítva? Egy fél pillanatig se felejtsük el, hogy az adatok védelme elméletileg a Google európai leányvállalatának policyjától függ, gyakorlatilag meg ugye annak az államnak a jogbiztonságától, ahol az adott konkrét felhasználó adatait ideiglenesen vagy tartósan tároló szerverek vannak. A Google pedig stílusosan a felhasználó földrajzi helyéhez legközelebbi adatközpontba fogja az adatot lapátolni, nos, Magyarország meg nem egy olyan ország, ahol különösebb visszhangja lenne egy adatlopásnak.

Az Európában kevésbé ismert Yandex Disk kliensprogramja már lényegesen jobban teljesített sok apró fájl esetén, de alapvetően szintén megadta magát idővel, de nem ez volt benne a legirritálóbb, hanem az, hogy az én esetemben pont akkor nem működött a kliensprogram, amikor a 2-FA-t bekapcsoltam, innentől kezdve pedig felejtős a dolog, ugyan alighanem a hibát előbb-utóbb javítják. Webes felületen 2-FA mellett viszont problémamentesen működik, tökéletesen alkalmas olyan adatok tárolására, amiknek az elérésére, módosítására csak ritkábban van szükség.

A Microsoft OneDrive kliensprogramja szintén a sok apró fájlba döglött bele először, viszont ha ezeket a húzós tartalmú mappákat külön-külön töltöttem fel, problémamentesen működött. A OneDrive-val kapcsolatban többször emlegetett adatvédelmi aggály, hogy folyamatosan pásztázza a felhasználók által feltöltött tartalmakat, alapvetően illegális tartalmak után kutatva, például a nagy mennyiségű, szerzői jogvédelem alá eső, megosztott könyvek, na meg a visszaélésre esetlegesen alkalmas fotók miatt harap. Szép és jó, hol itt a probléma?
Természetesen mindezt egy mintázatfelismerő algoritmus végzi, az viszont ismétcsak nem világos, hogy ha az algó talál ilyet, akár falspozitívan gyilokpornóként azonosítva egy farsangi képet, azonnal szögre akasztja a felhasználót vagy éppenséggel bekerül egy nagy kalapba, ahol már emberi ellenőrzésen is átmegy a dokumentum. Természetesen az is előfordulhat, hogy egy leendő, még nem szabadalmaztatott gyógyszerhatóanyaggal kapcsolatos részletes dokumentumot tekint a nagyokos algoritmus valami drogos cuccnak, ami enyhén szóval nem szerencsés, ha egy teljesen kívülálló alkalmazott elé kerül ellenőrzésre. Ugyan lehet még olvasni az Onedrive-on szinkronizálható fájlok számát érintő 20000-es limitről, ezt nem tapasztaltam.

Fontos tudni, hogy ilyen tartalmi ellenőrzést végez az összes nagyobb cloud szolgáltató, amelyiknek van rálátása a felhasználói adatokra, egyetlen megoldásként ismétcsak az javasolható, hogy a különösen rázós doksikat eleve titkosítva töltsük fel.

Szintén lényeges, hogy ne bízzunk ezer százalékig a felhőben, legyen air gapped másolata is mindennek olyan pendriveon, amit csak akkor húzunk elő, amikor nagyon kell. Ugyanis hiába, hogy a fájlhoszting szolgáltatókat arra találták ki, hogy kényelmesebbé és egyszerűbbé tegyék a fájlok kezelését különböző eszközök közt, simán előfordulhat, hogy pont ez okoz adatvesztést.

Ugyan nem mentem bele részletekbe, de ha egy fájlt módosítunk a saját gépünkön mondjuk Windowsban és természetesen nem sokkal később az OSX-et futtató almás laptopunkkal szeretnénk elérni, a szinkronizáló kliensprogramnak nyilván meg kell oldania, hogy a fájl újabb verzióját érjük el. Hogy ezt melyik kliensapp hogyan csinálja, annak nem mentem utána nagyon, a MEGA például a fájlok korábbi verzióiról készít egy-egy példányt, ami alapértelmezés szerint a felhasználó elől el van rejtve, de előhúzható szükség esetén. Annak felismerése, hogy melyik fájl a legújabb és melyiket kell figyelembe vennie a szoftvernek, valószínűleg úgy történik, hogy a szoftver megvizsgálja egyrészt az utolsó módosítás pontos idejét időbélyeg  szerint vagy éppen nyilvántartja a fájlok kiszámított hash értékét ami azonnal megváltozik, ha a fájlban módosítás történik. Az időbélyeget vagy a hash-ellenőrzőösszeget pedig ügyesen tárolja és kezeli olyan sebességgel, hogy ebből a felhasználó semmit se vegyen észre.

Aki szinkronizált már életében bármit bármivel találkozhatott azzal a jelenséggel, amikor éppen ez a kényelmi funkció okoz adatvesztést. Például a hülye box.com cloud esetén, amiről még nem írtam, ha a szinkronizálás rosszul van beállítva – jobb családokban a felhasználónak eleve szinte semmit sem kell állítgatnia – olyan módon, hogy egy helyben tárolt üres mappát szinkronizáljon egy olyannal, ami a felhőben már megvan vagy éppen fordítva, a box.com képes és az üres mappához igazodik úgymond, azaz törli a teljes tartalmát, ráadásul úgy, hogy azt esetleg vissza sem lehet állítani.

A cloud tároló vállalati környezetben gyakorlatilag megkerülhetetlen, személyes használat esetén pedig könnyebbé teszi az életet, viszont érdemes figyelembe venni, hogy mi az, amire alkalmatlan valamilyen szempontból – például a darkwebről bizonyítékként lementett tartalmak tárolására nem a legalkalmasabb.

Egy nem is olyan régi hír szerint pedig a legkomolyabb versenyzők esetén sem szavatolható 100%-ig, hogy valaki valamilyen újfajta technikával ne lásson át a felhőkön: Man-in-the-Cloud

Mármint pina nevű wifi-hálózat. De miért érdekes mindez? Mi az a wardriving? A heti második OSINT gyorstalpaló posztból kiderül.  

kép nagyban

Egyre többször kerül szóba a wifi hálózatok biztonsága, egy-másfél éve meg is keresett egy kiadó, hogy a készülő kötetükbe lektoráljam a vezeték nélküli hálózatok biztonságával foglalkozó részt, amihez ha nem is vagyok hülye, mint a harangöntéshez, de messze nem értek hozzá annyira, hogy egy ilyen fejezetnek szaklektora legyek.

A wifi hálózatok népszerűsége túl sok szót nem érdemel, amiről alighanem szintén eddig is többen hallottak vagy használták már, hogy számos olyan, known sourcingen, azaz közösségi tudásmegosztásra alapuló szolgáltatás van már, amin meg lehet nézni, hogy egy idegen helyen hol találunk legközelebb wifi-hálózatot. Na de honnan tudják ezek a szolgáltatások, hogy hol van wifi, és még azt is, hogy éppenséggel nyitott vagy valamilyen jelszavas hozzáféréshez kötött, ráadásul nem ritkán a hálózati eszköz olyan adataival együtt, amit nem a legbölcsebb, ha elárul a wifi-hálózat tulajdonosa?

Kezdetben volt a klasszikus wardriving, amikor megszállott geekek erre kihegyezett, laptopra kapcsolt antennákkal bóklásztak, amik folyamatosan figyelték a terepet, majd ha láttak egy wifi hálózatot, feljegyezték annak nevét, azt, hogy jelszóval védett vagy sem valamint természetesen rögzítették hozzá a pontos GPS koordinátákat. Ebből még annyira nem gyűlt össze tengernyi adat, néhány kivételes esettől eltekintve, mint amilyenről múltkor írtam a helymeghatározás kapcsán és csak részben volt elérhető a nagyközönség számára. Aztán jöttek a wifi-képes okostelefonok és ahogy az várható volt, ezt is megváltozott. Több alkalmazás is van, amin a mobilunkon meg tudjuk nézni, hogy a világ különböző pontjain milyen feltérképezett wifi-hálózatok vannak, ezek egy részénél opcionálisan, más részénél gyakorlatilag a használat kezdetekor elfogadjuk azt a feltételt, hogy a szolgáltatás használatáért cserébe a mi mobilunk is folyamatosan figyel, ha úgy tetszik jegyzetel, aztán tölti is fel a szolgáltatás adatbázisába az újonnan talált hálózatokat vagy frissíti azok tulajdonságait. A világ wifi routereinek nevének, pontos helyének és MAC-azonosítójának összegyűjtése és közzététele nem az ördögtől való dolog, viszont azon túl, hogy wifit foghatunk olyan helyen, ahol egyébként nincs netelérés, de szükség lenne rá, természetesen számos más célra is használható.

A nyitott wifi nem játék. Nemrég történt, hogy valaki egy család nyitott wifijét használva egy fórumon trollkodott egyet, konkrétan azt írta, hogy tele van robbanóanyaggal és használja is, ha kell, a fórumozót pedig persze az netelőfizetése alapján próbálták azonosítani, ami alapján rá is találtak egy családi házra, az Illinois állambeli Evansville-ben, ahova a SWAT igencsak nagy erőkkel szállt ki:

Mire aztán kiderült, hogy valójában valaki az utcáról használta a wifit, ők konkrétan nem robbantottak volna semmit. Arról, hogy a betört ajtó javításának költségét megtérítették-e a hékek, már nem nagyon van hír.

Azoknál a szolgáltatóknál, ahol bevezették a Wi-Free nevű őrületet, aminek a lényege, hogy más netkapcsolata is használható, ha az adott szolgáltatónál mi magunknak is van előfizetésünk, van némi ok a parára. Nos, elvben bárkinek wifi kapcsolata használható, - aki kimondottan nem tiltatta le a Wi-Free opciót, - mivel annak használata elvben saját előfizetéshez és azonosításhoz kötött, viszont sosem lehetünk benne biztosak, hogy
-    másvalaki a free wifihez kapcsolódó azonosítóinkat más nem szerzi meg, esetleg kéri kölcsön
-    esetleg nem lopják ki magától a szolgáltatótól
-    az előző kettő egyike sem, viszont az authentikációt a router olyan protokollon keresztül végzi, amiről rég tudott, hogy szar – nem vagyok benne biztos, de talán az egyik legnagyobb magyar netszolgáltató a MS-CHAPv2-et használja ehhez, amiről a Buhera Blog is beszámolt
-    esetleg a protokollal nincs probléma, viszont egyszerűen rosszul van implementálva, azaz leprogramozva az adott hálózati eszközben
-    ha még csak nem is használunk Wi-Free csodát, magának a routernek az alapértelmezett beállításai olyanok, ami alapján simán csatlakozhat rá bárki – poszt egy hazai példán keresztül szintén a Buhera Blogról erre

Másrészt tudva levő, hogy az olcsó 2 in 1, szolgáltatótól kapott kábelmodemek, amik routerek is egyben, ha önmagukban nem lennének eléggé közveszélyesek, maga a szolgáltató azzá teheti őket azzal, hogy egy WAN management protokollon keresztül az ügyfél tájékoztatása nélkül beleturkálhat valamilyen távbeállítás miatt, esetleg nem csak a szolgáltató, hanem bárki más is, amilyenre ugye szintén volt már példa.

Ha megnézünk egyet, a legnépszerűbb, wifis eszközöket feltérképező oldalak közül, mint amilyen a Wigle.net, akkor látható, hogy egy-egy hálózat nevére rázoomolva sokszor látható annak ún. MAC-azonosítója is, amiből kiderül a hálózati eszköz gyártója és sokszor az is, hogy melyik szériába tartozik.

Ez azért minimum problémás, mert rendszeresen fedeznek fel sebezhetőségeket bizonyos gyártók adott szériába tartozó eszközeivel kapcsolatban, amit ha egy támadó is tud, azt esetlegesen kihasználva hozzáférést tud szerezni a routerhez anélkül, hogy ahhoz tudnia kellene a belépési adatokat.

A routerekben persze beállítható, hogy az a nevét, az ún. SSID-t ne boardcastolja, viszont még ekkor is láthat minimum annyit például a mobil, ami a feltérképezést végzi, hogy mi a router MAC-címe. Nos, azért, hogy a MAC-cím alapján ne legyen a router típusa azonosítható, azt természetesen át lehet írni gusztus szerint olyan esetben, amikor ez lehetséges. Ugyanis több kábelmodem – ami tipikusan egyben wifi router is - esetén ha a MAC-cím megváltozik, a szolgáltatóval nem képes felépíteni a netkapcsolatot. Olyan részletekbe most nem mennék bele, hogy bizonyos eszközökön külön MAC állítható be a net és a belső hálózat felé, ahogy abba sem, hogy mindenképp egészségesebb a szolgáltató által biztosított kábelmodem és a gépeink közé egy saját routert is betenni.

Ne felejtsük el, hogy ha valaki telepített egy wifi hálózatok térképezésére és egyben gyűjtésére használt alkalmazást, könnyen lehet, hogy a mobil akkor is figyel és küldi a látott hálózatokat a szolgáltatás felé, amikor emberünk nem is tud róla, csak a az alkalmazás a háttérben fut.

Nem mintha nagy távolságból ne lehetne a wifi hálózatokat figyelgetni, de alighanem ez történhetett a több olyan közhivatalban is, ahol ilyen-olyan jópofa nevű hálózatokat vagy azok MAC-címét láthatjuk. A Nemzetbiztonsági Szakszolgálat egyik pina nevű wifijéről tudható, hogy egy kis Cisco-Linksys router, míg egy másik, közelben lévő, szintén pina nevű wifi hálózat egy Technicolor. Még egyszer: abban az esetben, ha nem mókolták meg a MAC-címet. Ezen kívül pedig figyelembe kell venni, hogy az adatbázisban nem feltétlenül minden adat friss, viszont az évszámot mutató csúszkát átállítva lehet rá következtetni, hogy a wifi hálózat mikor került fel először közszemlére.

Az ilyen térképekről egyébként sokszor nem csak az olvasható le, hogy hol vették lazábbra a figurát a kelleténél, hanem – lévén, hogy a jelerősség is fel van tüntetve – az is, hogy merre szoktak mászkálni az alkalmazottak illetve nyilván, ha sűrűn vannak egymás mellett wifi spotok, akkor abból látható, hogy egy könnyebben megközelíthető helyről, például az ügyféltérről van szó. Ezen kívül azok a mobilok, amik wifi hotspotként is képesek működni, természetesen szintén felkerülhetnek az adatbázisba, aminek a MAC-címe alapján pedig a mobilteló típusa derül ki.

Az Országgyűlés Hivatalának és a Parlament épületének legendásan hülye wifi policyjáról amúgy az Instán is találni képet:

kép: https://instagram.com/p/fSV88zsyHV/

A rendszeresen átirkált, kilométeres jelszavak használata helyes, az már kevésbé, hogy a Parlament területén lévő, összes parliament néven boardcastolt hálózatról megállapítható, hogy melyik Cisco szériába tartozik. De kis keresgélés után találni alighanem otthonról becipelt routert is a Parlament vagy más kormányhivatal területén, amivel sejthetően nem az ajtót támasztják, hanem szintén a belső hálózatához kapcsolódnak, ami ismétcsak nem túl bölcs dolog.

Találni viszont olyan eszközöket is, például a Teve utcai Sünplázában, aminél a MAC-cím alapján nem azonosítható sem a gyártó, sem pedig a típus - a MAC-cím leolvasásához a zoomolásnál az egyszerű térkép nézetet érdemes választani a műhold helyett.

Kutatásra fel, kommentben lehet nevezni a nagy Wifi Hülyenév Versenyre, közben pedig akkor se lepődjön meg senki, ha a Google megkérdezi, hogy miért is vagy kíváncsi valamilyen adatra:

Hivatalos alkalmazásboltból lett letöltve, több százezer felhasználó által, akik 4+ pontosra osztályozták, legitim alkalmazásnak tűnik és a mobilplatform bármely mobilját érinti, nem csak a megbuheráltakat, mi az? Igen, androidos kémprogram, mi más.

Már ha egyáltalán hírértékű az Android-mezőnyben, hogy a Google Play Storeban azonosítottak néhány olyan alkalmazást, amit letöltöttek és kitűnőre értékeltek több százezren, és teljesen mindegy, hogy az adott mobil rootolva van vagy sincs, így is, úgy is viszi az egész házat, pofátlanul gyakorlatilag minden adatot, amit csak lát. Ne legyenek illúzióink, a válogatás nélkül, minden áldozattól kilopott és összegyűjtött információ minden bizonnyal megvehető a feketepiacon, akár konkrét adatmasszaként, akár csak belépéshez szükséges felhasználói név-jelszó párosként, alighanem a díler csak annyit kérdez, hogy dekára vagy tonnaszámra venné a vásárló. Ilyesmit tesz lehetővé az a heti házikedvenc is, amit az ESET azonosított nemrég.

Az Android manapság olyan, mint a Windows 98 és Windows Millenium volt sokáig: mindenki tudta, hogy ön- és közveszélyes, de azért továbbra is mindenki használta, olyan sebezhetőségek illetve malware-ek megjelenése pedig, amik eget rengető, na meg részvénycibáló hatással lennének más platformokra, az Androidnál épphogy hírértékűek.

Mi több, előfordul, hogy még csak nem is kell alkalmazást telepíteni az androidos mobilra, mivel a felhasználó eleve úgy veszi meg hivatalosan a szolgáltató üzletében, hogy az eszközre  előtelepített alkalmazások lopják a felhasználói adatokat, ahogy az történt egy magyar szolgáltató által értékesített telefonszériával is. A hírt most nem keresem meg, de írom  egyszerűsítve, hogy mi történik a mobillal, mielőtt kikerül a polcokra. Úgy kell elképzelni a dolgot, hogy amikor az adott szolgáltató megrendel raklap számra adott márkájú, adott típusú mobilt, ahogyan azt is be kell állítani, hogy a mobil csak egy adott hálózattal álljon szóba – amíg nem függetlenítik – legyen rajta egy előtelepített Android, előtelepített alkalmazásokkal, ezt pedig ott csinálják, ahol a legolcsóbb, mondjuk Kínában, hol máshol. Miután elvégezték az előtelepítést, megy mondjuk Magyarországra, aztán persze kutya sem ellenőrzi, hogy a mobil nem küld-e a kelleténél több felhasználói adatot bárkiknek, a felhasználó tudta nélkül. Olyan ez a téma, mint a globális klímaváltozás vagy az éhínség, nem lehetne dokumentumfilmet csinálni abból, hogy az Android mindössze azzal, hogy olcsó, a mobilszegmens egy részét valahol a pattintott őskorban tartja, ehhez képest ha találnak egy bugot az iOS, Windows Phone vagy Blackberry egy ezer éve nem frissített verziójában, bégethet a nyáj, ha kihasználható a bug, ha nem. Ami meg aztán már végképp érthetetlen, hogy ha a felhasználók otthon, na meg a cégnél használnak személyi tűzfalat, vírusirtót, miért vesznek olyan mobilokat, amiről konkrétan tudják, alighanem lopható róla az égvilágon minden?  

Nos, normális ember nem engedné, hogy egy teljesen ismereten személy kattintgasson a LinkedINjén, Facebookján, Google-fiókján, Tinderjén, turkáljon az SMS-ei közt, ráadásul mindent lementsen és bárkinek el is adja, aki fizet érte. Androidot bezzeg használ a fél világ. Hát így.

Ha eltűnnék több napra, túlságosan belemerültem az irracionális fogyasztói döntések kutatásába, eltűntem az óceánon, esetleg csak a Balatonba fulladtam bele.

A Linux Torvaldsnak tulajdonított idézet szerint „Talk is cheap. Show me the code.”, szóval mostantól majdnem minden poszthoz írok példakódot könyvajánlót is annak, akit behatóbban érdekelnek a témák.  

Android-alapú szoftverfejlesztés - Az Android rendszer programozásának bemutatása (Ekler Péter - Fehér Marcell - Forstner Bertalan - Kelényi Imre)

Kép: phandroid.com

Körülbelül két héttel ezelőtt tett közzé a Symantec egy figyelmeztetést az otthoni felhasználók részére egy videóval együtt, amiben pazar módon elmagyarázzák, hogy hogyan lopható, "törhető" egy Google Account  mindössze az áldozat mobilszámának ismeretében. /*azaz hogyan férhető hozzá a Gmail mellett az áldozat összes kapcsolódó Google-szolgáltatáshoz való hozzáférése is a jelszó ismerete nélkül*/

A módszer lényege nagyon röviden:

1. a támadó kattint az elfelejtett jelszóra a Google bejelentkező felületén, megadja az áldozat címét, majd kiválasztja a jelszóhelyreállítás módjainál, hogy SMS-tokent kér a visszaállításhoz. Ez ugye az a rövidke számsor, ami az áldozat mobiljára megérkezik, majd a begépelésével új jelszó állítható be.
2. Az áldozat persze azonnal figyelmeztetést kap, hogy valaki jelszóhelyreállítást kért a nevében és persze magát a tokent /*vegyük figyelembe a pszichés hatást is!*/, ilyennel bizonyára már többen találkoztatok Ti is korábban. Valami ilyesmire kell gondolni:

"Your account was logged into from a new browser or device. Review the login: https://webhely.tld/token_helye"

"Your account was recently logged into from Safari on Windows."

"Facebook Password reset code: [öt-hat számjegyű szám] Or reset your password here: http://fb.com/l/token_helye" [1]

"Access data for your account has been ordered by you personally or by someone else. Your temporary password: [jelszó helye]"

3. És itt jön a csavar, a támadó egy, az áldozat által nem ismert mobilszámról SMS-t küld, ami nagyban hasonlít a webszolgáltatások előbb idézett rendszerüzeneteihez, majd hozzáteszi, hogy a fiókja biztonságosabbá tétele érdekében SMS-ben küldje el válaszként a tokent.

4. Az áldozat kellően beparázik ahhoz, hogy ne vegye észre azt, hogy a válasz SMS-t egy közönséges mobilszámra küldi, ami kézbesítődik is a támadó mobiljára, aki a böngésző előtt vigyorogva szépen bekalapálja a tokent, új jelszót állít be és már el is lopta a fiókot, az áldozat legfeljebb akkor veszi észre, hogy valami nagyon nem stimmel, amikor legközelebb próbál belépni, de akkor már valóban új jelszót kell kérnie, hiszen nyilván nem tudja, hogy mit adott meg a támadó. Esetleg a támadó egy olyan kamu SMS-t küld, amiben egy kamu ideiglenes jelszó van és azt állíttatja be a felhasználóval olyan körítéssel, hogy ne változtassa meg pár napig :)

Videó, hogy szemléletes legyen:

Hozzáteszem, hogy a Symantec a Gmail-en mutatja be a módszert, de vegyük észre, hogy gyakorlatilag bármilyen webalkalmazásnál bevethető a támadás, ideértve a Facebookot, LinkedIN-t, Evernote-ot, stb. aminél a fiókhoz hozzá van rendelve mobilszám.

Adja magát a kérdés, hogy a támadás kivédésére mi jelent megoldást és mi nem?

Első laikus gondolat, ami nemhogy nem jelent megoldást, utalva a korábbi posztjaimra, nagyon veszélyesen hülye ötlet, a fiók még könnyebben ellopható:
- ha nincs beállítva mobilszám - hiszen így akkor sem tud a szolgáltatás azonosítani, amikor a legitim felhasználónak lenne rá szüksége
- ha olyan mobilszám van hozzárendelve, amit más nem ismerhet meg - ne vicceskedjünk már, ilyen egész egyszerűen nincs, soha nem is lesz, még olyan életszerűtlen esetben sem, amikor valaki fene nagy biztonságtudatosságában direkt a webszolgáltatásokhoz vesz egy SIM kártyát, amit a mobilszolgáltató titokban tart, a felhasználó a számot nem árulja el senkinek. Egészen egyszerűen nincs olyan, hogy "beszerezhetetlen mobilszám".

Akkor mi jelent megoldást? Egyszerűen az, ha a felhasználó figyelmes, és semmilyen webes szolgáltatásból érkező SMS-re nem válaszol, mivel ilyet normális webes szolgáltatás szinte sosem kér, néhány nagyon ritka esetet leszámítva!

Egyébként a videó megjelenése óta gondolkoztam rajta, hogy ezt megírjam-e vagy sem, több szempontból. Egyrészt egész egyszerűen azért, mert ez a blog nem news outlet, nem posztolom újra, amit más kitalált, esetleg csak abban az esetben, ha ahhoz eléggé sokmindent hozzá tudok tenni. Másrészt azért, mert ez a tweak nekem konkrétan annyira nem új, hogy már ezer éve találkoztam vele, ugyanakkor felvet egy fogós etikai kérdést. Amikor valaki talál egy programhibát, ami esetlegesen kihasználható, majd azonnal közzéteszi, ezzel kényszerítve a szoftverrendszer fejlesztőjét a minél gyorsabb javításra, full disclosure-nek nevezzük, megoszlanak a vélemények azzal kapcsolatban, hogy ez mennyire jó gyakorlat. Nos, teoretikai szempontból az olyan módszerrel kapcsolatban is tehető közzé full disclosure, mint amilyen ez, azaz egy kevéssé ismert social hack ismertetése, viszont remek kérdés, hogy erre a szolgáltatók hogyan reagálnak, persze legnagyobb valószínűséggel sehogy, ugyanakkor alighanem lesznek olyan pöcsök, akik megtalálják mondjuk ezen a blogon, aztán fel is használják, mivel a téma iránti érdeklődés finoman fogalmazva is intenzív – ja, az egy tálca sört még tartom!  

Ugyanakkor egyrészt a blogolás olyan értelemben nem felelősségteljes műfaj, hogy agyalnom kellene annak a közvetett következményein, amit leírok,  az is előfordulhat, hogy aki biztonságtudatossági tréningeket tart, esetleg itt találkozik a módszerrel először, aztán be tudja építeni a tananyagba, hogy aztán a felhasználók erre a támadási formára is fel legyenek készítve.

Azoknak írom, akik erre a posztra keresőn keresztül találtak rá törési gyorstalpaló után kutatva és primitív kíváncsiskodó pöcsként nem értik meg, hogy a barát, barátnő, főnök, alkalmazott, feleség fiókjához való illetéktelen hozzáférés milyen súlyosságú dolog, azt tudom mondani, hogy nyugodtan próbálják ki, mivel az előzetes megfelelő anonimizáláshoz, na meg mondjuk úgy, laborkörülmények beállításához elég eszük úgysincs, a web giantek meg nem hülyék, jó esetben szokatlan aktivitás esetén úgyis meggátolják a támadást, bónuszként azonosítják a támadót, de úgy, hogy őt rúgják ki végleg, szóval hajrá!  

Sokszor nem értik, amikor arról beszélek, hogy alapvetően mindenféle jelszóemlékeztető, jelszóhelyreállító feature rossz, pláne, ami nem igényel emberi beavatkozást, akármilyen szofisztikáltnak tűnik is. Ugyanakkor erre nyilván szükség van tömegszolgáltatások esetén, hiszen semmilyen szolgáltatás, amelyik közvetlenül nem kér előfizetési díjat a használatáért, egyszerűen nem engedheti meg magának egy harceddzett ügyfélszolgálat fenntartását [2], ugyanakkor azt sem, hogy a felhasználóik semmilyen módon ne férhessenek hozzá a fiókjukhoz például amikor valóban elfelejtették a jelszavukat.

Vegyük észre, hogy a netbank-rendszerek már nem ilyen hülyék, nem lehet beállítani új jelszót csak úgy, néhány banknál még telebankon keresztül sem, ahogy azt is, hogy itt - az én definícióm szerint - ismétcsak szó sincs törésről, csak egy átlagosan kifinomult trükkről, ami az emberi tudat egy sajátosságát használja ki, - ami ugye esetfüggően bug vagy feature :) -  nem pedig egy szoftveres hibát!  

[1] korábban a FB-ban volt egy olyan jelszóhelyreállító metódus, amiben a mobilra érkező 5 számjegyű számmal lehetett új jelszót beállítani. Nos, ekkor megérkezett egy token SMS-ben, amit a felhasználónak meg kellett adnia, ha pedig elírta, akkor a Facebook figyelmeztette, hogy helytelen, ezért adja meg újra, VISZONT nem korlátozta a próbálkozások számát! #facepalm!!! Tehát akár automatizáltan is bárki bárki másnak a fiókján végigpróbálgathatta a maximálisan 99999 lehetséges ismétléses permutációt - átlagosan ebből ugye tehát mindössze ötvenezer próbálkozás is elegendő volt, majd ha talált, beengedte a szolgáltatás a támadót. A módszer persze azóta már nem működik és a próbálkozások számán túl még nagyon sok mást is figyelnek a normális webszolgáltatások annak kiküszöbölése érdekében, hogy a jelszót valóban a fiók tulajdonosa tudja csak átírni, aztán ha támadást tapasztal, ahogy írtam, szépen szögre akasztja a támadót.

[2] Ami a szolgáltatások supportját illeti, nos, igen, kivétel minden alól van. Ortó nagy botrány volt belőle, amikor kiderült, hogy jelszóvisszaállításkor az Apple telefonos supportja az új jelszó beállításához csak a fióktulajdonos postai címét kérte el meg talán még egy adatot, amit bárki megtudhat, a gyakorlaton mégis csak akkor változtattak, amikor már jópár Apple-fiókot feltörtek. Másrészt bizonyos esetekben a Google csak akkor engedélyezi az új jelszó beállítását, ha a fiók tulajdonosa befizet 1-3 USD-t, ekkor egy alkalmazott is megnézi a felhasználó korábbi aktivitását, majd valamilyen belső policy alapján eldönti, hogy a kapcsolattartói email-címre küld-e átmeneti jelszót. Azt viszont már nem ellenőrzik, hogy a bankkártya, amivel ezt az összeget valaki fizeti, annak a nevén van-e, akinek a nevén regisztrálva van a fiók :)

A legdöbbenetesebb tapasztalatom konkrétan személyes és egy óriásszolgáltatóhoz tartozik, mivel nem tudom, hogy a módszer működik-e még, nem írom meg, hogy melyikről van szó. Történt, hogy egy szolgáltatásba még kiskoromban regisztráltam, nem használtam évekig, amikor pedig ismét léptem volna be, a jelszó nem stimmelt. Gondoltam, semmi probléma, ott az account recovery, igen ám, de a hozzá tartozó email cím már nem élt, már a domain sem, így oda nem tudtam jelszóhelyreállítót kérni. Ahogy az ott szépen le volt írva, felvettem a kapcsolatot a supporttal, megírtam nekik, hogy mi az ábra, viszont lévén, hogy ilyet bárki írhat, feltüntettem azokat az adatokat, amiket csak én tudhatok, nevezetesen, hogy évekkel korábban másodperc pontossággal mikor regisztráltam /*megvolt az ezzel kapcsolatos email a benne lévő aktiváló kóddal együtt*/, melyik netszolgáltatót használtam akkor. Olyan válasz érkezett, hogy azt hittem, nem hiszek a szememnek: a supportos tag ragaszkodott hozzá, hogy arról az email címről írjak nekik, amelyikkel regisztráltam, holott pont azért írtam nekik, mert a postafiók már nem létezett. Aztán küldtem nekik még néhány adatot, ami nyilván megvolt nekik is, rajtuk kívül csak én tudhatok róla, de a tag ragaszkodott a belső policyhoz, aztán ellevelezgettünk pár napig. Végén gondoltam, hogy ez már tuti bukó, nincs vesztenivalóm, aztán lezavartam neki a legcifrább kurvaanyázást, amit csak tudtam, ékes angolsággal viszont - itt jön a lényeg - az emailem fejlécét úgy változtattam meg, hogy annak a feladó mezőjében az általuk kért, a már nem létező címem szerepeljen, válaszcímként pedig olyan, ami létezik és azt is megírtam nekik, hogy egy több tízmilliós szolgáltatásban ez a gyakorlat nevetséges, hiszen ilyen alapon bárki lenyúlhatja más fiókját egyszerűen a supportnak küldött email fejlécének megmókolásával. Nem hiszitek el, hogy mi történt: a supportos azonnal küldött jelszót /*hiszen formálisan arról a címről írtam nekik, amelyikhez tartozott az account!*/ és visszakaptam a hozzáférést a szolgáltatáshoz.

képek: geekpause.com, hackpla.net, mikeyanderson.com