Nagyon csúnyán bukott meg a 000webhost

HUP cikkturkáló

Igen komoly biztonsági incidens történt az ismert, litván bázisú 000webhost ingyenes hoszt- és tárhelyszolgáltatónál. A vállalkozás szerdán a Facebookon jelentette be, hogy főszerverük kibertámadás áldozata lett: a behatolók a felhasználónevek, a jelszavak és az e-mail címek teljes adatbázisát megszerezték, ráadásul ezeket aztán tovább is adták.
Mint kiderült, az üzemeltetők nem használtak semmiféle titkosítást, a belépési oldalt sem védték, ráadásul minden adatot egyszerű szöveges formában tároltak.

Teljes cikk itt

  • 6185 megtekintés

( Huncraft v | 2015. 10. 31., szo – 13:18 )

Részlet a levélből amit kiküldtek:
"At 000webhost we are committed to protect user information and our systems. We are sorry and sincerely apologize we didn't manage to live up to that."

Ezek után nagyon is hihető :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Dosika v | 2015. 10. 31., szo – 17:06 )

Vagy 6 éve volt ott egy drupal oldalam, amit aztán meg is szüntettem rá nemsokára. De mailt azt küldtek az esetről most, sőt egy reddites linken volt egy lap, ahol lehetett ellenőrizni, hogy érintve vagy-e, és az egyik emailcímemre bejelzett. tehát amellett, hogy bénék, még a régi userek adatait is tárolták. Ez csak nekem furcsa?

Altalaban az ilyen helyeken a "regi user" az egy UPDATE Users SET status = 0 WHERE Users.id = X, a password oszlop attol nem valtozik, az email is max akkor, ha sokan panaszkodtak, hogy account torles ota is kapjak a spameket, mert valamelyik tehetseges alkalmazottjuk nem ellenoriz status-t, amikor kigyujti a cimlistat. Ha a passwordot plain textben taroltak, miert lett volna eszuk pont erre figyelni (plane 6 ev utan)?

( bzs v | 2015. 10. 31., szo – 17:56 )

Én ezt kaptam:

What happened?

A hacker used an exploit in an old PHP version, that we were using on our website, in order to gain access to our systems. Data that has been stolen includes usernames, passwords, email addresses, IP addresses and names.

Although the whole database has been compromised, we are mostly concerned about the leaked client information.
What did we do about it?

We have been aware of this issue since 27th of October and our team started to troubleshoot and resolve this issue the same day, immediately after becoming aware of this issue.

In an effort to protect our users we have temporarily blocked access to systems affected by this security flaw. We will re-enable access to the affected systems after an investigation and once all security issues have been resolved. Affected systems include our website and our members area. Additionally we have temporarily blocked FTP access, as FTP passwords have been stolen as well.

We reseted all users passwords in our systems and increased the level of encryption to prevent such issues in the future.

We are still working around the clock to identify and eliminate all security flaws. We will get back to providing the free service soon. We are also updating and patching our systems.
What do you need to do?

As all the passwords have been changed to random values, you now need to reset them when the service goes live again.
DO NOT USE YOUR PREVIOUS PASSWORD.
PLEASE ALSO CHANGE YOUR PASSWORDS IF YOU USED THE SAME PASSWORD FOR OTHER SERVICES.

We also recommend that you use Two Factor Authentication (TFA) and a different password for every service whenever possible. We can recommend the Authy authenticator app and the LastPass password manager.
We are sorry

At 000webhost we are committed to protect user information and our systems. We are sorry and sincerely apologize we didn't manage to live up to that.
At 000webhost our top priority remains the same - to provide free quality web hosting for everyone. The 000webhost community is a big family, exploring and using the possibilities of the internet together.
Our leadership team will closely monitor this issue and will do everything possible to earn your trust every day.

Sincerely,
000webhost CEO,
Arnas Stuopelis

-----------

Megjegyzem, azóta nem érdekel ez a tárhely, amióta németeknél dolgoztam egy litvánnal... Inkább egy kínai bánya.

( dzsimbo | 2015. 11. 01., v – 15:28 )

Ezért volt "ingyenes", most eladtak egy rakás e-mail címet és rögtön meglett a haszon.. :D :D

( MrPrise v | 2015. 11. 01., v – 16:44 )

13 millió felhasználójuk volt/van? Szép.
Legalább nem fizettek, legalábbis pénzzel.

( uid_395 v | 2015. 11. 01., v – 17:18 )

hm, azért mégis mi lehetett az elképzelés akkor amikor plain* -ban tárolták el az adatokat ....

( d3ad | 2015. 11. 01., v – 18:15 )

csak mostanában kezdtem dinamikus oldalak szerkesztése/létrehozása felé kacsingatni és már nekem is van annyi tudásom, hogy mosolygok csak ezen.

( pappe v | 2015. 11. 01., v – 19:22 )

Erről eszembe jutott amikor a friss diplomás pályakezdő mérnök informatikus 4 hónapos oklevéllel jött hozzánk állásinterjúra.
Szakdolgozata témájaként egy webáruházat fejlesztett (PHP, Mysql és egy kis JS) amire ötöst kapott.
Kérdésünkre szemrebbenés nélkül és csípőből azt a választ adata, hogy a jelszavakat kódolatlan formában text típusú adatként tárolja adatbázisban, nem halott még arról, hogy mi az az Apache, vagy az IIS, de alternatívát sem ismert amikor elmondtuk "kik" ők. Hígul a szakma, azóta tudom.

Nem tudom pontosan mit és hogyan oktatnak de ez valóban elgondolkodtató:

a jelszavakat kódolatlan formában text típusú adatként tárolja adatbázisban => amire ötöst kapott.

Egy autós példával illusztrálva: Ma kora reggel többed magammal közlekedtem Budapest Liszt Ferenc nemzetközi repülőtér felé a ködben. A lámpánál megállva kellett szólnom az autóvezetést oktató vénembernek, hogy kapcsolják már be a világítást mert kb. 100m a látótávolság és ha 45-tel poroszkálnak az út közepén világitás nélkül akkor hátulról ráesik valaki.

Nekem egyszer éjjel, autópályán beszart a motor akksija. Ez valahogy túlfeszültséget okozott, és az összes izzószálat elolvasztotta ügyesen.

Hirtelen nem lett semmi lámpám, csak a fényszóró, az indexek és a féklámpa maradt.

Szerencsére nem kellett sokáig szopnom, mert kb. ahogy sikerült a leállósávon gyök kettővel elérnem a következő lehajtóig, addigra a gyújtótrafók is szétégtek.

Végül sikerült elismernie, hogy
- nem biztos, hogy jó, ha újra feltalálja - hibásan - az SSL-t
- az MD5 hash használata is vicces ma már, hát még az, hogy ebben a formában át is küldi a jelszót
- egyetlen (rossz) érve volt: Androidról szerette volna elérni, ezért csak http jöhetett szóba (a https-t óvatosan kerülte a dolgozatában).

A szomorú az, hogy a konzulense végig mondta neki, hogy ne így csinálja, de nem hallgatott rá.
Egyetlen enyhítő körülmény, hogy ez villamosmérnök képzésen volt.

Egyetlen enyhítő körülmény, hogy ez villamosmérnök képzésen volt.

en mindig azt hittem, az ember abbol ir szakdolgozatot, amihez ert, amit szeret, amibe beleasta magat. Mondjuk en szerencsesnek tartom magam, hogy egyik szakdolgozatom sem az 1562. darab a millio egy kaptafara keszulo "kkv irodai halozata debian alapon" temaju papirhalom kozott...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Hát nem tudom. Van pár szakmám -- bár van amelyiket inkább titkolom --, de mindegyiket úgy tanították meg, hogy a vizsgák után legalább ne kövessünk el (ön)gyilkosságot. Se szakmait, se biológiait.

Volt olyan tanár/mester aki ordított velünk, volt aki elment sírni (sértődötten elvonult), vagy volt aki lelki terrort alkalmazott (börtönbe akarsz küldeni?!), és ezek mikor hogy voltak komolyak vagy inkább csak figyelmeztetések.

Annyiból viszont végül is leszarom, hogy anno azért kaptam meg egy állást, mert az előttem interjún lévő mikiegér elbukott a "mi a processzorra várakozó processzek száma" kérdésen. Én is majdnem, mert azt hittem hogy valami trükkös, beugrató kérdés, de nem.

1) Nem mindenhol követelmény a diploma, vannak helyek, ahol az elegendő, ha a jelentkező megfelelő tudást tud felmutatni.

2) Egy infós diploma azt mutatja, hogy az ember képes tanulni, valamint az alapokat valószínű ismeri. Pályakezdőként tehát jó anyag ahhoz, hogy az adott feladathoz szükséges specifikus dolgokat megtanulja.

3) Én személy szerint infós diplomával és kb. 20 év szoftver tervezés/fejlesztés közeli tapasztalattal bírok. Lehet, hogy ezen meg fogsz lepődni, de a mai napig adódik olyan, hogy egy új projektben olyan témával kell foglalkoznom, amivel korábban még sosem (vagy esetleg a legutolsó alkalom óta sokat változott), ezért a projekt eleje során az adott témába bele kell magam ásni, és megtanulni.

Ostobaság lenne azt elvárni, hogy 20 évvel ezelőtt a főiskolán megszerzett tudás mindenre elég lesz majd ma. (és a személyeskedést kerüljük: nem az én esetemre gondolok konkrétan, hanem bárki, aki 20 évvel ezelőtt végzett bármilyen suliban infó szakon)

És ha azt kérdezed, hogy miért feltétel a diploma, akkor széttárom a kezem. Vannak álláshirdetések, ahol nem feltétel, megnézik az önéletrajzomat és elég amit látnak, és van olyan, ahol a fejvadász kétszer is rákérdez, hogy de ugye akkor van diplomád?

Én pályakezdőnél megértem az igényt, tapasztalt szakembernél, aki már bizonyított, igazából nem. De talán a HR-esnek így könnyebb, vagy nem tudom.

Egyébként ezt akartam kifejezni én is.

A 2-es pontban leírtakban is egyetértek. De azért hadd fűzzem hozzá: Én tudok és akarok tanulni, de csak olyat ami érdekel is.
Ismét lemaradtam a felvételin, mert olyan tantárgyak eredményeit is beleszámítják, aminek semmi köze nincs a választott szakhoz. Tehát hiába van 90%-os érettségim infóból, mivel töri lehúzza, megint nincs elég pontom fősulira, így pedig csak olyan pitiáner fillérbaszó helyekre mehetnék dolgozni, ahol egy RAID is "túl drága", aztán meg megy a picsogás, ha ugrik az adat...

Lehet, hogy nem rossz, hogy az alapokat megadja. De ez a terület olyan gyorsan változik, hogy az alatt, míg felvételitől a diplomáig eljutsz, elavul a komplett tanulmányod. Így feleslegesnek tartom ez alapján ítélni a jelentkezőt. Főleg, hogy sok példa mutatja, hogy inkompetens faszok jönnek ki diplomával a kezükben.

Jó, ez inkább picsogásnak volt nevezhető, de minden alkalommal felbasz, amikor ilyesmit tapasztalok, miközben én meg szívok ilyen fillérbaszó faszokkal.

--
openSUSE 13.1 x86_64

Mindenkinek más a helyzete, nem akarok neked tanácsot adni, mert nem ismerlek, és amikor én hasonló cipőben jártam, az régen volt.

Én 12 évesen kezdtem programozni hobbiból, gimi után de még diploma előtt elkezdtem dolgozni programozóként. Később munka mellett jártam főiskolára. Kb. 9 éven át dolgoztam úgy, hogy nem volt diplomám. Volt rosszabb és jobb munkahelyem is, és egyáltalán nem csak ruppótlan garázscégek voltak hajlandóak felvenni.

Egyébként pl. a jelenlegi munkahelyem állásajánlataira rápillantva simán láttam olyanokat, ahol nem feltétel a diploma. Küldtem egy PM-et.

( Proci85 v | 2015. 11. 01., v – 21:40 )

Sajnos tudok több olyan hosting szolgáltatóról, akik szintén plain text tárolják a jelszavakat. Van köztük elég nagy is és az userek fizetnek a szolgáltatásért. Itt tartunk, pedig már a csapból is az IT security folyik.

Még idén tavasszal volt a Telenorral egy kisebb csörtém (be szerettem volna fizetni az utolsó havi számlámat).
Ügyfélszolgálatnak a honlapjukon lévő formon ment levél.
Az ügyfélszolgálatos válaszolt nekem már e-mailben. Az meg, amit ő megkapott (s a formból lett generálva) lazán tartalmazta plain textben a jelszavamat.

Máshol is vannak ilyenek.
--
blogom

( khiraly | 2015. 11. 05., cs – 14:23 )

Mondjuk arra kivancsi vagyok, hogy hogyan csinalnatok meg, hogyha egy jelszot ki is *KELL* venni az adatbazisbol.

Tehat nem eleg hashben tarolni. Mondjuk a szerver, mint kliens ker adatot a user neveben egy masik szervertol. Es ehhez a user megadta a masik szerverhez tartozo jelszavat (barmi lehet: carddav szerver, webdav, imap jelszo, smtp jelszo, dokumentumiktato, akarmi).

Mert amit en tapasztalok az az, hogy addig er mindenki tudasa, hogy egy jelszot eleg hashben tarolni. De a fenti felhasznalasi modhoz ez nem eleg.
Es ebben az esetben mindenki plaintextben tarolja... :)

Csakhogy a szoftveroldalon maradjunk, hardveres titkosito modul nem er.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Jajj ne mar.

Meg a gmail is tudja, hogy masik emailcimedrol letolti neked a leveleidet, es te *megadod a masik emailcimedhez tartozo felhasznalonevedet es jelszavadat*.

Legy szives mondd el a google-nek, hogy ez egy hibas use-case.

Jah, igen es a googlenel van oauth2 is. Azt nem is ertem, hogy keveredett ebbe a szalba...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Igen, az egy hibás use-case - de nem a Google hibázott.

Én az Outlook.com-os email címemnek létre tudok hozni alkalmazás-specifikus jelszavakat. A Gmail, emlékeim szerint, szintéd tud hasonlót. Ha ezeket az inboxokat akarod másik kliensből kezelni, nem kell megadnod az accountod mesterjelszavát.

Ez igaz, de attól még el kell tárolni az alkalmazás specifikus jelszót, nem elég csak a belőle képzett hash-t.

Szerintem a jó use case az lenne, ha mondjuk a B elérésére akarom az A rendszert feljogosítani, akkor a B adjon nekem egy tanúsítványt, vagy tokent, vagy mindegy, minek hívjuk, valamit, amit az A-nak odaadok, és az A azt használja majd a jelszavam helyett és B meg elfogadja.

Vagy valami.

Najó, de ugye mivel az A tudja az azonosításhoz szükséges összes adatot (ami a példádban a token), ezt el lehet lopni, és onnan kezdve már felhasználható máshol is. Így mindegy, hogy az alkalmazásspecifikus jelszót lopják el - "sandorvagyokkeremkapcsojjaki" - vagy valami hasht - "af16a4a603b6663070c22e28bc89111f398d13c8" -, a végeredmény ugyanaz.

altalaban jelszo ismereteben tudsz jelszot vvaltoztatni, mig hash ismereteben ezt nem tudod megtenni, mert hash melle a regi jelszot is be szokas kerni valtoztataskor.

Persze ezt is el lehet rontani nem azt mondom... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Hol? Hogyan?

Ha én azt mondom, hogy töltse le a leveleket a pop3.vilmosnagy.hu-ról, óránként, akkor a Google-nek óránként oda kell adnia a pop3.vilmosnagy.hu-nak egy jelszót.

Ha jól emlékszem, a pop3-nak plain textben kéne odaadni a jelszót, így a Google a letárolt adatokból vissza tudja nyerni a plain text jelszót. (Ha nem plain textben adjuk át a pop3-nak a jelszót, akkor a kódolt verziót kell tudnia visszakapnia)

Ha a Google vissza tudja nyerni a jelszót a tárolt verzióból, akkor egy esetleges adatlopás esetén, igen nagy valószínűséggel más is meg fogja oldani.
--
blogom

"Ha a Google vissza tudja nyerni a jelszót a tárolt verzióból, akkor egy esetleges adatlopás esetén, igen nagy valószínűséggel más is meg fogja oldani."

Ez azért nem ennyire egyszerű. Simán megoldható az, hogy a user által használt hash-t összetolom egy másik (Google által használt, erre a célra fentartott) hash-el, és ebből képezek mondjuk egy 2 kulccsal titkosított adatot, ami igaz 2 irányú (tehát visszafejthető), viszont annak ellopása magában még kevés ahhoz, hogy vissza lehessen fejteni az algoritmus, illetve a másik kulcs) ismerete nélkül, még úgy is ha az összes ilyen jellegű cuccot ellopták, mivel a "salt" minden jelszónál így más tud lenni.

Az persze ettől függetlenül igaz, hogy miután a 2 adat segítségével feloldják a "kódot", onnan már plaintext-ben kell áttolni a POP3 szervernek (bár normálisabb helyen inkább használnak POP3S-t, vagy IMAPS-ot ha a lehetőségek engedik)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Lehet hülyeség amit írok, de mi lenne ha az lenne a gyakorlat szerver oldalon, hogy VAGY plaintext jelszót fogadja el (és ellenőrzi annak hash-ét a saját oldalán tárolt hash-el) VAGY pedig adott hash algoritmus által generált hash-t is elfogad - és ehhez szerver oldalon 1 jelszóhoz 2 hash-t tárolna - a saját hash algo eredményét meg az egyezményest is? :D

Az utóbbinak sok értelmét nem látom, több szempontból se:
- Ahhoz, hogy le tudd gyártani vagy az első, vagy a második hash-t rendelkezned kell a plaintext jelszóval. Ha az nincs meg, akkor onnantól az egyik hash-t nem tudod legenerálni (ergó nem tudod összevetni, hogy az adott jelszó 2 hash formátumban is megegyezik e (kerülendő a hash ütközéseket)
- Ha sima hash-t is elfogadsz (kb mint egy hosszú plaintext jelszót), akkor security téren ugyan ott vagy mint a plaintext jelszót kaptál volna (annyiból mondjuk jobb, hogy nagyobb a jelszó kulcstere, de ebben ki is merül a dolog)
- Ha ne adj isten lopják az adatbázist, akkor a támadónak plusz 1 opciót nyújtasz a hash feltörésére (olyan szempontból, hogy a 2 hash közül csak a gyengébbet kell támadnia, ergo az erőse(bbe)t simán meg is kerülheti). Plusz ha a 2. pontban leírt módon akár hash-t is elfogadsz (csak magában), akkor lényegében simán lopható az identitás, a tényleges jelszó ismerete nélkül is.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Milyen kliens? Leírom máshogy:

1. Belépek a Gmail-re. Azt mondom, hogy szinkronizáljon POP3-mal egy másik fiókból, megadom hozzá az email címet és jelszót.
2. Kikapcsolom a gépemet, alszok, elutazok, bármi, offline vagyok.
3. Miközben offline vagyok, a Gmail újra és újra letölti a leveleimet POP3-mal.
4. Belépek Gmailbe, és lőn, ott vannak a másik postafiókból szinkronizált leveleim. Sőt, ha másik számítógépről lépek be is, akkor is. Nem kell újra jelszót megadnom.

--

ha egy jelszot ki is *KELL* venni az adatbazisbol.

mondj mar egy konkret peldat, miert is kene belanak megadni az xyz-hez tartozo jelszavat a te szervered szamara?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

ha minden rendszer automatikusan adna oauth-ot, akkor egy tokeletes vilagban elnenk. De ez nem igy van, es ha nem igy van, akkor le kell tarolni a jelszot biztonsagos formaban.

Es a kerdes erre vonatkozott, hogyan tarolnatok ti le biztonsagos formaban egy "retrievable" jelszot.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

En a sajat megoldasomban ugy csinaltam, hogy amelyik service-nek tudnia kell a user jelszavat, az kulon szerveren van, kivulrol (internetrol) kozvetlenul nem erheto el, jelszot belole kinyerni nem lehet, csak egy butitott verziot (pl: v***o) lehet kikerni belole, de ez is kenyelmi szempont (hogy a felhasznalo tudja mi volt a jelszava).

A "worker" titkositva tarolja a jelszot, amit indulaskor a kinyito kulcsot a foszervertol keri el (titkositva) es azzal titkositja ki a helyileg tarolt jelszavakat. A jelszot by design kiadni nem adja ki. A ket szerver egymassal rest api-n kommunikal.

Valoszinu nem ez a legjobb megoldas, kicsit porogtem a teman, remelem nincs elvi hiba benne:)

A jovoben tervezek egy two factort is beletenni: ha a worker ujraindul (aminek nem kellene uzemszeruen bekovetkeznie), akkor jelszot a foszerver csak akkor ad ki, hogyha sms-ben ellenorzo kodot beutottem neki.
Ehhez be kell fejeznem az sms kuldo worker-t, ami 80%-on all.

Roviden ennyi. Persze jo ha van oauth amihez hozza kell ferni, de altalaban nincs, legtobbszor direkt.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

elvileg a workernel van "a jelszo", a foszerver nem tudja.

A kinyito kulcsot a sajat maga altal tarolt jelszavakhoz kapja.
Elvileg az internetre nezo webszervert torik meg eloszor, a workert jobb esetben soha, mivel csak egy rest apija van, amin minimalis parancsok vannak definialva, semmi mast nem tud.

Ha megis lenyuljak a worker kodjat *ES EZT ESZREVESZEM*, akkor tobbet nem adom ki a workerhez tartozo kulcsot a webszerver oldalon, hanem uj kulcsot generalok, es uj workert keszitek.

Termeszetesen abban az esetben, ha torik a webszervert, lenyuljak a workert, es elinditjak, akkor megkapja a kinyito kulcsot a webszervertol HA KOZBEN NEM VESZEM ESZRE. Ez egy valos veszely. Erre lenne jo a two factor auth, hoygha worker keri a kinyito kulcsat, akkor a webszerver csak akkor adja ki, ha mondjuk kozben megkerdezett engem (pl. sms-ben).

---

Van meg egy 5letem, hogyan lehetne tovabbfejleszteni, de szerintem az mar tenyleg brutal. De azert leirom:)
Workernel sincs jelszo. Worker indulasnal megkeri a kinyito kulcsot a webszervertol, webszerver szol nekem sms-ben, en feltolom a webszerverbe a worker jelszavait titkositva, amit a webszerver tovabbad a workerbe. A worker kinyitja a titkositottat a webszervertol kapott kulccsal es az egeszet eltarolja memoriaban.
Namost ha a workert lenyuljak, akkor sincs meg a jelszava senkinek.

Ugye ebben az esetben a laptopom valik celpontta:) De azt meg lehet azzal fokozni, hogy egy titkositott usb-s vinyon van, ami alapesetben ki van huzva, es ha kapom az sms-t akkor dugom ra:)

Persze igy mar en vagyok (mint emberi tenyezo) a leggyengebb lancszem.

Szerintem a nagyok vesznek valami hardveres titkosito modult, es abba beleontik a jelszot, es tovabbleptek a probleman... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

ha minden rendszer automatikusan adna oauth-ot, akkor egy tokeletes vilagban elnenk.

az ouath fincsi, en is hasznalom a google-nel levo levelek letoltesehez, de a tokeletes vilag meg odebb van. A jelszot csak a google-nel potyogi be a delikvens, hozzam mar csak egy token jut vissza, amit en eltarolok, hogy aztan kesobb el tudjam erni a leveleit. Tehat en a jelszavat sosem lattam, de nem is kell, mert a tokennel belepve is pont olyan jol elerem minden levelet.

Csak annyiban kisebb a token ellopasa kovetkezteben okozhato kar scope-ja (vo. ha a jelszot vittek volna), amennyiben kevesebb jogot kert es kapott az alkalmazasom, amit a delikvens neveben meg tud tenni...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)