Vlákno názorů k článku Google vám zadarmo zkontroluje bankovní výpis. Je o co stát? [DOPLNĚNO] od Filip Jirsák - Jaké nastavení URL netuším, to jste psal vy. Vy...

Jaké nastavení URL? Co je to za nesmysl? Čtete vůbec, co píšu, nebo snažíte se to aspoň pochopit? Nastavení se týká sdílení. Tady máte moji veřejnou adresu kalendáře: https://accounts.google.com/ServiceLogin?service=cl&passive=1209600&continue=https://www.google.com/calendar/embed?src%3Dvkt7cevdagfh0kt37ev887fhuo@group.calendar.google.com%26ctz%3DEurope/Prague&followup=https://www.google.com/calendar/embed?src%3Dvkt7cevdagfh0kt37ev887fhuo@group.calendar.google.com%26ctz%3DEurope/Prague&scc=1&authuser=0

Řekněte mi, co tam mám třeba na pátek. Podotýkám, že sdílení mám nastavené na určité osoby.

U Dropboxu je to tak, jak píšete, tam jsou pouze 2 možnosti: sdílet, nebo nesdílet, není žádná jemnější možnost nastavení. Naštěstí i tady by byla možnost, jak veřejné sdílení obejít, pokud by to někdo takto chtěl, ale to už je na jinou debatu.

Z té Vámi odkazované stránky:

Adresa kalendáře představuje veřejnou verzi kalendáře, kterou můžete sdílet veřejně se všemi uživateli nebo s konkrétními lidmi.

Takže není pravda, že si kalendář může zobrazit každý, záleží na nastavení. Na to jsem upozorňoval i o pár příspěvků výše, kde jsem psal o veřejném sdílení. A nic bych nedal za to, že na Dropboxu to bude podobné.

Do Dropboxu nemusím být přihlášen? A jak se dostanu ke svým souborům? :-D

Nesmysly plácáte Vy a není to zdaleka poprvé. Odkážete mě na stránku s nápovědou a sám si ji nejste schopen ani pořádně přečíst.

To nemá smysl. On je přesvědčený o své pravdě a hluchý ke všem argumentům. Doporučuji přečíst diskusi zde: http://www.lupa.cz/clanky/prichazi-dalsi-bic-na-piraty-copyright-alert-system-aneb-sestkrat-a-dost/nazory/ o svobodě slova, je to opravdu výživné čtení :-)

Koukám, že asi neumíte číst. Psal jsem jasně, že záleží na tom, jestli je kalendáři nastaveno veřejné sdílení. Pokud ne, žádným URL si ho bez přihlášení nezobrazíte. Taktéž jsem po Vás nechtěl, abyste se mnou něco sdílel, tak nevím, proč to píšete. A co se týče důkazu, to si můžete ověřit sám doma na dvou různých prohlížečích. Na jednom si zjistěte adresu pro sdílení a v druhém, kde nejste přihlášen, ji zkuste zobrazit. Schválně, co se stane.

Tímto diskusi končím, každý si může ověřit, jak to je.

Když si přečtete znovu můj příspěvek, zjistíte, že jsem se ke kalendáři vůbec nevyjadřoval. Nicméně co se týče vašeho dotazu co máte dnes naplánováno, kdybyste si psal někde blog, tak fakt, že ho nebudu schopen nalézt, taky nedokazuje, že jsou informace na něm privátního charakteru. Veřejně dostupná informace automaticky neimplikuje, že jí všichni znají, nebo vědí kde jí najít.

O tom, že na Lupě existuje tak velká bezpečnostní díra v zabezpečení silně pochybuji, pokud Vám ten odkaz funguje, má Lupa pravděpodobně implementován záložní mechanismus, který provede reautentizaci, nebo má OpenID svázáno s Vaší cookie. Každopádně jste tímto neprokázál, že OpenID pracuje na principu, který zde obhajujete. Chování Consument serveru na závěrečné přesměrování od OpenID poskytovatele totiž není součástí OpenID specifikace a záleží na každém provozovateli, jak s informací naloží, jestli bude bránit replay útoku, nebo ne.

Mimochodem zkuste si to Vaše Lupa URL v nějakém čistém prohlížeči, kde jste ještě nebyl na Lupě přihlášen. Jsem přesvědčen, že to nebude fungovat. Jestli mám pravdu, zjistíte, že i na Lupě do procesu vstupuje ještě nějaká jiná informace, než Vámi prezentované URL.

To je silný argument :-)

S první a druhou adresou neudělám nic, pokud neznám Vaše jméno a heslo. S tou první dokonce ani pak ne. S Dropboxem nevím, ale počítám, že to bude stejné, tedy že se mi zobrazí login box. Pokud máte povoleno veřejné sdílení, pak je to ovšem o něčem jiném, to je ekvivalent zobrazení obsahu kdekoliv na webu. Klidně sem dám odkaz na share z Google drive, bude Vám na dvě věci, pokud neznáte moje heslo. Chápete, že ta URL bez přihlašovacích údajů je Vám na ho.no?

A tady je URL, pomocí kterého se můžete přihlásit na kurs síťové bezpečnosti:

http://www.gopas.cz/Kurzy/Katalog-kurzu/IT-bezpecnost-/-Hacking/Network-Security-Hacking-v-praxi-GOC3.aspx

Nic ve zlém, jen mi to nedalo ;-). Ne, vážně, tím posledním odkazem mi hrajete v podstatě přesně do karet, nejde totiž o žádnou autentizaci či přihlášení, ale prosté zveřejnění informací z Vašeho účtu. Tedy přesně jako v případě toho FIO API URL.

První odkaz opět nepředstavuje žádnou autentizaci (i když se o tom se mnou asi budete přít), zjevně jde o návratovou adresu z přesměrování po úspěšném přihlášení u OpenID poskytovatele. S autentizací vůči serveru Lupy to tedy samozřejmě má dost společného, je to ale jen poslední krok. Tzn. samotný fungovat nebude, navíc s ohledem na proměnnou "openid.respon­se_nonce" bude fungovat právě jednou a nikdy více. Tedy pokud má Lupa ochranu proti replay attack, pokud ne, pak postrádá proměnná smysl.

Druhý odkaz mi nic neříká, takže se k němu nemohu vyjádřit.

A už máš nějakej link na export z Gimpu? :P

Aha, takže vy zavoláte nějakou URL, kde pomocí GET předáte přihlašovací údaje, aby se ty pak následně POSTem předaly ještě někam dál... no to je úžasné.

Chcete mi říct, že když vezmu jakýkoliv z těch Vašich příkladů, tak si můžu nechat zobrazit nějaká data? U Google calendar se nemusím přihlásit? Dropbox mi jen tak zobrazí Vaše soubory? OAuth mi umožní se přihlásit bez jména a hesla do Vašeho Facebooku? :-D Ale no tak. Naproti tomu u FIO mi stačí platný token a dostanu se jednoduše k výpisu odkudkoliv, stačí připojení k netu, nic víc nepotřebuju.

Ok, přijímám výzvu, z nabízených zbraní vybírám OpenID a nechávám Vám první výstřel ;-) Tedy, jak souvisí OpenID autentizace s naší debatou a co je podle Vás onen token?

Já nerozporuji, že se informace dá téměř vždy sloučit do jedné věty, v tomto případě URL, ještě lépe tím, že jí předáte třetí straně, která to volání ve výsledku udělá za Vás (jak uvádíte níže pomocí nickj.org). Rozdíl mezi tím o čem diskutuji já a Vy je asi takový, jako mezi situací, kdy by banka vydávala kreditní karty s přímo na kartě natištěným PIN kódem a situací, kdy si ho tam napíše uživatel. Pokud ten rozdíl nevidíte, je zbytečné tuto diskuzi dále rozvíjet, neboť se bavíme každý o něčem úplně jiném.

"Magie" frameworku nemá nahrazovat programátorovy nedostatečné znalosti, může ale účinně bránit úniku citlivých údajů v případě, kdy se změní počáteční podmínky například změnou konfigurace. A může tam být s pánem bohem třeba token. Když bude framework vědět, že ten token je autentizační údaj, může zablokovat jeho zaslání v otevřeném tvaru. Nebude ho vypisovat v logu, dávat do výjimek atd. To jsou ale základy bezpečnosti, nevymýšlíme tu nic nového.

Obávám se, že stavíš na domněnkách a klišé. Já mám jinou metodu. Bezpečnost* musí být prokazatelná/pro­věřená. (nápověda: citlivá data ti můžou prosakovat bez ohledu na to, v jakém políčku daného protokolu přišla – dokud prokazatelně nedokážeš, že nikde mj. neprosakují, nemůžeš o bezpečnosti systému říct vůbec nic)

*) tedy jde o to, zda jsi cracker, který jen tak zkouší, jestli se mi náhodou podaří do nějakých systémů vlámat (v tom případě je tvůj přístup dobrý), nebo jestli máš prověřit, zda je konkrétní systém *dostatečně* bezpečný. To jsou zcela jiné úlohy.

Pane kolego, tohle jsou tak základní věci, že je zbytečné je uvádět. Problém je, že on odvedl pozornost jinam. Jinak mohu ujistit, že tento dotaz v tom kontextu, jak se bavíme mu právě v Google položí a ještě maličko opepřený, protože s kolegou, který mi tam odešel tyhle otázky na pohovory řešíme. Takže pokud bude chtít na některou ze security pozic, musí to okamžitě vysypat z rukávu při prvním volání. Tyhle základní věci a okecávání dělají lidi, co jsou vývojáři, čtenáři lupy a ne lidi z bezpečnosti. Proto je snadno takhle poznáte. Neznamená to vůbec nic, ale vůbec o tom, že jsem zaměřený na web nebo jeden protokol. Znamená to to, že se probudím a vím okamžitě tyhle známé útoky, protože se o nich v komunitě mluví a mluvilo a jsem v obraze. Tím oddělím teoretika od praktika, co je do toho dění zapojen. Jednoduchý screeníng, tak se proberte.

Mimo jste oba dva.
1) Svěřovat data Googlu (nebo jiné firmě), když si je můžu zpracovat lokálně, je zhovadilost a zbytečné riziko.
2) API pro propojení dvou systémů je něco jiného než webové stránky a poučky platné pro web zde mnohdy nejsou na místě.

Ten první odstavec jsem nepochopil... kde je tam nějaký POST?

Ohledně druhého odstavce: všechny příklady, které jste vyjmenoval, mají nějaké omezení. Buďto jsou ty tokeny jednorázové (resety hesla, potvrzení emailu), nebo jsou vázány nějakou další metodou autentifikace (např. cookies). Žádný z nich není vygenerovaný na určitou dobu platnosti s tím, že ho můžu bez problému využít opakovaně a ještě navíc klidně z různých PC.

Zdraví komik :-D

Vy jste fakt komik a jak se tak koukám, jste tu pro legraci nejen mojí maličkosti :)

Člověče, Vy jste komik :-D Vy tady tvrdíte, že vlastně vždy existuje riziko vyzrazení přihlašovacích údajů, tak nemá smysl se tím zabývat a můžeme login a password rovnou plácnout do URL, vždyť ono to stejně může všechno "někde vyplavat". Proč se s.át s nějakým SSL a POSTem, že? Úplně pomíjíte míru rizika, proto jste schopen plácnout nesmyslné srovnání úniku dat svěřených dobrovolně Google s nějakým keyloggerem s rádiovou komunikací v klávesnici od Logitechu :-D

Vám nedochází, že bankovní výpis je nikoliv jedinou, ale jednou z mnoha informací, které jsou lidé ochotni svěřit úplně cizím firmám, že ty informace jsou centralizované a dostupné a obsahují údaje stovkách milionů lidí, je možné díky nim zjistit neuvěřitelná kvanta informací, jejichž množství se v blízké budoucnosti ještě znásobí. Vy (a miliony dalších) si svého soukromí nevážíte, jste ochoten jej dát všanc za větší pohodlí a imaginární bezpečí. Já vím, že je to dnes moderní, ale nesnažte se nás, kteří si svého soukromí vážíme přesvědčovat, že je to v pořádku a nic nehrozí.

Člověk, který ztratí soukromí, ztratí i důstojnost a svobodu. Je to i hlavní myšlenka Orwellova 1984.

Pane kolego, jen krátce. Tohle je otázka, co vám při úplně první pohovoru jako jedno z možných položí dokonce i v tom Google na bezpečáka, dokonce budou v tom Google ještě více záludnější a bude tam fígl, tohle bylo jednoduché. Okecávači se vymluví jako vy na jiné protokoly, že měli nejasné zadání a blablabla další výmluvy. Zadání jste měl jasné a dokonce jste si ho sám napsal a zadal. Že jste okecávač do diskuze, za to já vám nemůžu. Zkušených hackerů, reálných s praxí a reálnými exploity je strašně málo. Odpověď na otázku, co jsem vám položil, vám řekne každý nováček, když přijedete na kterýkoliv Blackhat. Teoretiků jako vy je neurekom.

Víte, to máte těžké. Na jednu stranu mne obviňujete, že nemám obecnou představu o zabezpečení a zlobíte se, že všechno beru z pohledu prohlížeče. Na druhou stranu jste se ale sám zasekl na tomto jednom případu a odmítáte z těchto kolejí vyjet.

Jak Vám názorně předvedl na několika případech uživatel Max, jakmile dáte něco do URL, může to na Vás vyběhnout někde, kde jste to původně vůbec neočekával - např. logy na cílové straně, výstup z výjimky atd. Vrazit heslo do URL parametrů je jako zadat heslo do parametrů příkazové řádky a následně se divit, že je to vidět ve výpisu procesů a v historii shellu.

To, že předhazujete URL nikoliv prohlížeči, ale nějaké knihovně, není žádný argument. Právní hledisko jsem tu už omílal asi stokrát, tak Vás tím znovu nebudu unavovat. Technicky má ale většina dnešních WS oddělenu konfiguraci přenosové vrstvy od autentizace a samotného datového přenosu. Pak můžete například psát WS klienta v .Netu a počítat s tím, že jedete pod SSL. Ve výsledku to tak vůbec být nemusí. A pak těžce narazíte. WCF má mechanismy jak zabránit nějaké plain-text autentizaci při vypnutí SSL a buď přejde automaticky na NTLM apod, nebo volání zcela zablokuje. V případě, že použijete nějaký token nebo jméno/heslo v URL, nebude knihovna vůbec tušit, že jde ve skutečnosti o autentizovanou komunikaci a spojení povolí. Pokud takovou práci odevzdáte ve firmě, která bere bezpečnost jen trošku vážně, už to znovu neuděláte, protože Vás k tomu už nikdo znovu nepustí...

K Vašemu domácímu úkolu pro mne - jediná vhodná varianta je první, protože dodržuje oddělenost autentizačních informací. Proto se také používá výraz "autentizační vektor". Všechny ostatní příklady jsou nevhodné. Poslední dva jsou sice pouze zápis a budou před použitím odděleny, ale jak jistě víte, URL specifikace je nedoporučuje, protože jsou považovány za bezpečnostní riziko.

Z toho si nic nedělej – to je typická slepota „lidí od webu“.

Podobných canců jsem u pohovorů slyšel moře. No nic, na tohle nemám čas. Pro mě to byl jednoduchý test, kterým prochází lidi krátce po škole a buď ví a nebo to okecává. S okecáváním můžete jít pracovat do manažerské pozice. No nic, fajn den a naštěstí já mám o vás jasno.

Tak je vidět, že jste ňouma. Pardon. Je to jedna z útočných metod, co se používala a standardně se přesně takhle dělá bezpečnostní test i pro zaměstnance. My jsme ji prakticky použili v roce 2010. Vůbec nic nemusíte dělat s SSL, vůbec. Jsou tři základní metody pane kolego a jednu jsem již popsal a tu doteď používáme. je to přes web log, což je možné uznat to, jak jste psal o tom před SSL. Ale my se k tomu dostali u v průběhu SSL a to bez prolamování. Způsob byl triviální, jen musíte přemýšlet. Je to přes GA a referera. Normálně došlo k requestu na GA tam byla součástí plná URL včetně login. Mohl bych popsat přesně scénář, jak jsem se domluvii s testovaným subjektem, jak velmi jednoduchou metodou sociálního inženýrství nabídnete firmě zdarma zvýšení návštěvnosti. Jak jsme se domluvili se správcem webu, aby si vypnul cookies a udělal tam nějaké změny na webu, co potřebujeme a pak něco prováděl na webu. Následně jsme dostali výpis z GA, podle kterého jsme měli subjektu pomoci zvýšit zdarma návštěvnost. No a na GA jsme měli referera s jeho loginem. Stálo nás to asi den práce. Je jedno, že máte v RFC jasně dáno, jak nakládat s refererem při https, ale GA si to posílalo ve svém skriptu na externí sajt, normálně to byl ukázkový XSS od Google s plným souhlasem uživatele. A právě k XSS mířila moje otázka, protože tohle je metoda, co se s ním používá. Google to pak změnil, ale tuším, že to tam opět je (teď to nemám ověřené, stačí si pustit httpwatch).
Poslední metoda je historie prohlížeče, kde na tohle je ideální IE, který po mnoho dlouhých let držel historii URL, ale to uvádím jen pro úplnost.

Jen doplním to zadání pro vás, pořád se bavíme v kontextu URL viz váš poslední post. Btw, tohle dostávají uchazeči o práci u nás jako naprostí začátečníci.

Pardon, ale spíše dojmem, že o bezpečnosti nevíte vy a k tomu ještě pořád napadáte uživatele Cohena.

Jinak test pro vás. Myslíte si, že je možné dostat se k autentikačním údajům (je úplně jedno, jestli to je token a nebo login), když jedu v SSL?

Tak schválně pane kolego :)

To máte pravdu. Můj příspěvek byl už více o tom, že je snaha snižovat bezpečnost s vidinou user-friendly řešení a v současné době, kdy většina dat je elektronicky dostupná, tak se zvyšuje pravděpodobnost jejich zneužití při současném poklesu bezpečnostních standardů a ochrany.
S tím právním bodem souhlas a s tím technickým popisem ad certifikáty úplně. Tak je to správně, ale přesně jak píšete a s čím já se pořád peru je to, že bezpečnost ustupuje pohodlí klientů. Ale tohle platí a vše je růžové jen do chvíle, než nastane průser. Pak za námi běží celý management, že jsme je měli důrazněji upozornit a že to nevěděli a další výmluvy :)

To jste ale už se zabezpečením zamířil úplně někam jinam než FIO ;-). Vícefázová autentizace je určitě nezbytná u nějakých citlivějších systémů (FIO jí pravděpodobně využívá ve formě SMS při přihlašování na účet - doufám) pro vyhrazenou skupinu uživatelů, obecně je ale na internetu zatím těžko prosaditelná. Prakticky by šla asi nejsnáze implementovat do OpenID technologie, kterou zmiňoval pan Jirsák, kdy by OP při požadavku na autentizaci kontaktoval program na uživatelově počítači a uživatel musel akci potvrdit. Nevím ale, jak je to s doporučeným časováním, jestli by to bylo použitelné pro běžné uživatele.

Každopádně máte pravdu.

Potíž s touto diskuzí je v tom, že já jsem původně řešil spíše právní stránku věci, kdy je dle mého názoru nepostižitelný přístup k URL, byť "zabezpečenému" pomocí tokenu. Nebylo by možné prokázat, že "útočník" věděl, že přistupuje k datům, která jsou osobní povahy. Pokud by bylo požadováno heslo, je situace úplně jiná.

Smysl mého původního příspěvku je v tom, že pokud by již někdo získal (neřešme jak) z mého Google Drive FIO URL, je víceméně nepostižitelný. Kdyby získal trojici údajů (adresa, jméno, heslo), nemůže se již tvářit, že nevěděl, že dělá něco špatně. Proto je způsob přístupu k FIO API přinejmenším nešťastný. Lepší variantou by byly jednoúčelové klientské certifikáty, vydávané nějakou FIO API CA. Technicky by to bylo pro klienty ale komplikovanější. Takhle to dopadá, když se staví pohodlí nad bezpečnost.

Nerozumím Vašemu přístupu, zjevně jste nepochopil mou původní výhradu vůči tokenům, tak jste vyrazil na pole osobních invektiv a dehonestování odborných znalostí oponenta. Zkuste to prosím méně útočně, jinak nemíním v diskuzi pokračovat.

K technické stránce věci: chápu, že můžou někteří tvůrci webových aplikací použít přístup, kdy je jméno a heslo předáno v rámci proměnných v URL, ale to je amaterismus nejhrubšího zrna. Když neřeším fázi autentizace, je po jejím dokončení samozřejmě možné uložit session token do cookie nebo jako "fallback" do nějaké POST skryté proměnné. To je ale komplikované, takže se to většinou také nedělá. Záložní varianta s GET proměnnou je s prominutím prasárna a když vidím v URL něco jako PHPSESSID, tak automaticky odcházím. Uživateli totiž stačí, když se zapomene odhlásit a do timeoutu je jeho sezení možné napadnout prostým průchodem historie prohlížeče. Už dlouho jsem nenarazil na web, který by se snažil vypnuté cookies nějak obcházet (možná s výjimkou LSO) a obvykle o zapnutí cookies požádá. Surfuji zásadně s vypnutým JS i cookies a zapínám je až když jsou potřeba, takže jsem přesvědčen, že nejde pouze o můj dojem.

Autentizační postupy jsou zde z nějakého důvodu, především proto, aby byly systémy schopné určit, kterou část informace si je možné zapamatovat (adresa) a kterou je třeba chránit (jméno/heslo). Pokud mi pro vstup do systému stačí pouze jediná informace (adresa), nedá se o bezpečnosti vůbec mluvit. Nevím jak přesně ve FIO přístup funguje, ale pokud je to tak, že si v internetovém bankovnictví vygenerujete adresu s tokenem (v podstatě autentizační fáze), která je pak platná například měsíc a samotná stačí k autorizaci, je to přinejmenším nešťastné. Já to nepovažuji za zabezpečení a nemyslím si, že jde z mé strany o paranoiu. Naopak jsem přesvědčen, že akceptování postupu jako bezpečného je značně lehkomyslné.

Prakticky byla ale původně řeč o něčem jiném. Z pohledu legislativy by bylo otevření takového URL považováno za neodporující zákonu. Až teprve zneužití takto získané informace by bylo trestné - jenže prokazování by bylo na Vaší straně. Naopak při krytí dodatečným jménem a heslem by bylo postižitelné už samotné otevření URL. V prvním případě by se mohl útočník bránit, že adresu našel někde na internetu, nevěděl o co jde, myslel, že je to veřejné. Ve druhém případě by mu taková argumentace nepomohla. Z tohoto pohledu je tedy token nešťastný i kvůli případné ztížené právní obraně.

Update: pročetl jsem dokument k API FIO a je to přesně jak předpokládám, stačí Vám pouze adresa. V příkladu ze zmíněného Apps Scriptu je:

UrlFetchApp.fet­ch("https://www­.fio.cz/ib_api/res­t/last/"+token+"/tran­sactions.json");

Pokud takovou adresu předhodíte prohlížeči a vyměníte na konci .json za .html, máte něco, co Vám bude schopen zaindexovat i vyhledavač. Soubor robots.txt také žádná omezení neklade. Stačí tedy odkaz vhodit někam do diskuze a majitel účtu má o návštěvníky postaráno.

Na závěr chci jen pro pořádek upozornit, že už jde dost o OT.

No právě, že musíte. Pro nás je to jedna z možných technik, co používáme při pentestech. Spoléháme na delší dobu expirace tokenu a metoda útoku je velmi snadná. Hledáte, jak se např. dostat k log fajlu toho web serveru. Jsou různé způsoby a úplně první a nejjednodušší, který uděláte je directory traversal na ten log, ten úplně stačí a případně ještě lépe na aplikaci. Sice většinou je zde firewall, ale obvykle je to jen iptables a na aplikační úrovni je minimální filtrace a většinou to admini řeší právy na fajlsystému. Nebudu do toho zabíhat, ale můžete se při troše štěstí a umu dostat k tomu, jak vypisovat log. Budete to dělat potichu a nebo to spojíte s nějakou kamufláží, ideálně odstíním pozornost admina předstíraným ddosem vedle a nebo mu začnete projíždět další servery skenerem a on na to zaměří pozornost, to máme vyzkoušené, že to zabere. A když vytáhnu log, vidím tam i tokeny. Pokud je nevidím, mohu aplikaci do toho módu přepnout a to jak v .NETu, Javě atd. takže by default aplikace nebude pracovat s cookies a pojede na URL. Pokud aplikační vývojář je taková lama, že tohle povolí a nechá to na úrovni aplikace a nenastaví to omezení systémově a nebo nejlépe na firewallu (např. přes mod_secure nebo obdobný http filter), tak je trotl a je to poměrně snadná metoda. No a útočník pak může sledovat, co se děje. Jo a s tím heslem a tajností, tak tady platí, že pokud nemáte dvoufázovou autentikaci nejlépe nějakým OTP, tak jste v pr,,, To, co popisujete je na nic a viz ten Dropbox nebo i Fejs, tak např. na dropbox byl poslední útok právě ukradením účtů na jiných accountech, protože uživatelé jsou lidé a mají obvykle stejná hesla v různých systémech (viz. http://www.zdnet.com/dropbox-gets-hacked-again-7000001928/). Pokud nemám dvoufázovou autentizaci, tak je to nejhorší metoda zabezpečení a cookies pro bezpečáka nejsou žádná ochrana. Vlastně pořád nevíte, kdo tam na druhé straně je. Takže příspěvek autora je sice technicky nepřesný a asi nepochopil fungování FIO, ale bagatelizace jeho pokusu o upozornění na tohle chování je devalvace práce bezpečáků evangelizovat uživatele, aby takové chování nedělali a aby opravdu chránili svoje soukromí a věřili jen sobě a lidem, co si ověří. Není to paranoia, ale je to nutnost v dnešním světě.

V zásadě souhlas. Jen bych trochu rozlišoval „webové stránky“ a „zneužití/využití HTTP jakožto přenosového protokolu pro aplikační rozhraní“. V tom prvním případě je dobré dodržovat určité zásady (kvůli ochraně proti XSRF atd.). Ve druhém případě je to ale jedno – webový prohlížeč je mimo hru a my si vlastně jen posíláme nějaká data po TCP a shodou okolností ten protokol vypadá stejně jako protokol používaný na webu. A pak je jedno, jestli pošlu token na řádku „GET ... HTTP/1.1“ nebo o pár řádků níže – všechna data je potřeba beztak zabalit do šifrovaného kanálu (typicky SSL/TLS) a zajistit „end-to-end“ bezpečnost mezi dvěma aplikacemi/systémy.

Dovolím si oponovat, v tomto případě je token součástí adresy, což je právě jádro pudla. Velké množství URL na internetu obsahuje nějakou část, jejíž význam není na první pohled zřejmý, většina uživatelů by v případě použití vůbec netušila, že přistupují k privátním údajům.

Zaindexování prohlížečem je samozřejmě nesmysl, v původním komentáři mělo být slovo "vyhledávač", díky za upozornění.

Děkuji za upřesnění, to je poměrně důležitá informace, která tu zatím nezazněla, API FIO banky samozřejmě detailně neznám. Nabízí se otázka, jestli má takové URL s maximálně měsíční platností nějaký význam, protože pro účetní program půjde v podstatě o OTP, ale to je již mimo rámec diskuze.

Co se týče zneužití, tak heslo je velmi podstatné. Pokud někomu vlezete do bytu, protože měl otevřené dveře dokořán, nějak se z toho vykecáte. Když si ale odemknete kopií klíče, tak budete mít poněkud menší prostor pro argumentaci, pravděpodobně skončíte v cele předběžného zadržení ;-).

Samozřejmě se Vám může stát, že uvedené FIO URL zaindexuje nějaký prohlížeč, i když zde by tomu asi zabránil formát výstupu (možná i robots.txt).

Přečetl jsem si celý článek, poté diskuzi včetně té na G+ a následně opět článek.

Ve světle všech informací je jasné, že autor v článku uvedl pár zavádějících údajů a s největší pravděpodobností původně nevěděl, že jde u FIO o přístup pouze pro čtení. Čímž řekněme snížil poněkud odbornost svou i článku, jeho chyba.

Nicméně článek ve své podstatě na tomto příkladu demonstruje (a nejlépe je to vidět v diskuzi) postupnou ochotu vzdávat se soukromí kvůli pohodlí, které poskytují cloudové služby. A varuje před tím, za což jsem mu osobně vděčný.

Jsem přesvědčen, že nešťastný je i přístup FIO banky s tím, že umožňuje přístup na účet (i když jen pro čtení) prostřednictvím jediného údaje, zde URL s tokenem. Jak se správně ohrazuje autor v diskuzi, tato adresa poskytuje komukoliv beztrestný časově neomezený přístup k informacím z transakční historie účtu. Záměrně píšu beztrestný, neboť pokud by bylo pro přístup ještě požadováno jméno a heslo, jednalo by se již ze strany třetí osoby při jeho použití o zneužití. Takto je informace veřejně dostupná. Nabízí se srovnání s povolením veřejného přístupu do webmailu, to by se také asi většině lidí nelíbilo.

Přístup pana Hráčka je naivní a přehlíživý a odpovídá klasickému přístupu Googlu. Google již roky nabízením osobních cloudových služeb postupně uživatele vychovává k tomu, aby mu dobrovolně poskytli své soukromé údaje. Není přitom žádným tajemstvím, že například označování osob na fotografiích na FB/G+ je hojně využíváno tajnými službami, které si kvalitu údajů nesmírně pochvalují. Čím více informací o uživatelích bude k dispozici, tím lépe. Mezi arogantními výkřiky typu "kdo by se s tím analyzoval" a obviněními z paranoi už chybí jen to klasické "kdo nedělá nic špatného, nemá co skrývat".

A nejhloupější na celé této mediální přestřelce je chování pana Dočekala. Nemám nic proti reakcím na G+, ačkoliv selektivní ignorování nejrozumnějšího argumentu ohledně časově neomezeného přístupu k FIO prostřednictím URL s tokemen mě o jeho profesionalitě příliš nepřesvědčilo. Ale hádka s kolegou v diskuzi pod jeho článkem s užitím osobních invektiv je ubohá a velmi poškozuje celou Lupu. Musím říct, že jsem se s něčím takovým ještě nesetkal.