Článek napsal pan Václav Novák, jehož názory si můžete přečíst v diskuzi pod původním postem na G+:
https://plus.google.com/u/0/111783114889748547827/posts/BZnsgkYdkA4
Nevěřím, že si pan Novák opravdu myslí to, co píše v článku. Například, že "propagovaný přístup nechává útočníkům zcela otevřené dveře", že útočník může "rovnou i získat přístup k vašemu bankovnímu účtu" nebo že "vaše bankovní přístupové údaje nejsou nijak zvlášť chráněny před zneužitím zaměstnanci Googlu".
Pokud si to opravdu myslí, nic si o tématu nezjistil. Ale vzhledem k tomu, jak je článek napsaný, je mi celkem jasné, že je to jen pokračování v trolování, které začalo na G+, pokračovalo na Twitteru, a teď je i tady na Lupě.
Nezáleží na tom, jestli je v kalendáři nastaveno veřejné sdílení. Veřejné sdílení jenom určuje, zda je kalendář dostupný ve vyhledávání kalendářů. Jinak může kalendář zobrazit každý, kdo zná jeho adresu.
S Dropboxem jste si to mohl vyzkoušet na výše uvedeném odkazu. Ani nepotřebujete dva prohlížeče, protože jste Dropbox v životě neviděl, tak v něm nemůžete být přihlášen. Stačilo na odkaz kliknout a uviděl byste obrázkovou galerii, kterou Dropbox automaticky generuje z obrázkových souborů.
Ano, každý si může ověřit, jak to je, akorát pro vás je i to jedno kliknutí velká námaha, tak tu radši plácáte nesmysly. Taky si to každý může přečíst v nápovědě. Zde k Dropboxu: https://www.dropbox.com/help/167/en a zde ke Google Calendar: http://support.google.com/calendar/bin/answer.py?hl=cs&answer=175256&rd=1 -- otázky "Jaký je rozdíl mezi adresami Soukromá adresa a Adresa kalendáře a jak je mohu použít?" a "Jak mohou můj kalendář zobrazit přátelé, kteří nemají službu Kalendář Google?"
Ten člověk je neuvěřitelný. Napsal text ve kterém vedle mylných věcí jsou i lži, místy člověk musí nutně uvažovat na tom, že to přece musel napsat záměrně, že nemůže být tak blbý. Od rána mu to na Google+ i tady lidé omlacují o hlavu a on se pořád jenom kroutí. Chvíli tvrdí že tam něco napsané není ačkoliv to tam napsal, pak se odvolává na "všichni že něco dělají" a pak že "všichni něco nedělají". Možná by se měl dát na politiku.
Viděl autor články někdy nějaký transparentní účet? Tam se přístup k výpisu účtu nedává jenom jedné firmě, ale má k němu přístup úplně kdokoli. Takže neskrývání výpisu z účtu není zase taková šílenost, jak se autor článku snaží naznačit. A existuje spousta dalších případů, kdy se výpis z účtu předává dalším aplikacím – např. účetnímu nebo fakturačnímu softwaru. Třeba takový Fakturoid má možnost párování plateb podle výpisu z účtu snad od začátku.
Ale já mám v bance funkci Hlásiče, kde si můžu podrobně nakofigurovat co chci sledovat, a přijde mi SMS nebo e-mail. Dále jsem se podíval do historie a mám ji tam od samého počátku, co u banky jsem, díval jsem se zpět na pohyby staré 6 let. To jsou ale snad základní funkce, kterými disponuje bankovnictví u většiny bank nebo je to vyjímka? Která banka vám dá k dispozici data pouze za rok? Taková snad není...
Srovnavat teplotu ovzdusi a citlive bankovni udaje? to snad nemuzete ani myslet vazne---
Defacto predavate Google pristupove udaje...neni to anonymni app je to Google, ktery si Vase udaje a data shromazduje, analyzuje a to zcela v souladu se svymi podminkami uziti. Pokud je to pod Vasi rozlisovaci schopnost tak je me nas lito, protoze za par let to diky laxnosti ci nevedomosti nas uzivatelu muze byt realna zkusenost, ze soukromi na webu neexistuje.
Komerčka má historii taky jen 13 měsíců, ale snad si výpisy aspoň jednou za čas stahuju, ne? I když být by to tam mohlo dýl...
Od KB si udělám vždycky jednou za čas export do CSV, sice si s tím člověk musí ještě pohrát, ale zaplať pánbůh za to. Pak už si v Excelu udělám, co potřebuju, aniž bych musel poskytnout někomu přístup.
jsou jich tisice... napr u FIO http://www.fio.cz/bankovni-sluzby/bankovni-ucty/transparentni-ucet/vypis-transparentnich-uctu?offset=1350
u RB http://www.rb.cz/firemni-finance/transparentni-ucty/
a jsou i dalsi..
Okecáváte tady akorát vy. Na zadání, jak jste jej široce a nepřesně napsal, jsem já napsal správnou odpověď. To, že vy píšete SSL ale myslíte HTTPS ve webovém prohlížeči, to je vaše chyba -- a teď se to akorát snažíte zamluvit. Jinak na to, aby vám řekl, že skript na stahování informací přes REST API se nebude obtěžovat s posíláním nějakého referreru, že ten skript nebude mít zabudovaný JavaScript interpreter, aby se tam mohl spustit kód Google Analytics, a že do odpovědi ve formátu JSON není možné vložit odkaz na spuštění skriptu Google Analytics (jak to znáte z HTML), nepotřebujete zkušeného hackera reálného s praxí, na to stačí kdokoli, kdo se aspoň trochu s nějakým API volaným přes HTTP potkal -- bude to vědět i kdejaký schopnější programátor, který dělá aspoň s AJAXem.
V Google doufám takovéhle otázky nedávají, doufám, že jsou tam odpovědných místech lidi, kteří aspoň trochu vědí, o čem mluví. Vy možná víte něco o bezpečnosti webových prohlížečů, ale když to ani nedokážete popsat a ani nedokážete použít správné termíny, je to dost katastrofa -- útočník dneska nebude útočit čistě jen na webový prohlížeč, ale prohlížeč bude jen jednou součástí. Takže ani náhodou nestačí jenom znát webový prohlížeč a neumět ani popsat, jestli myslíte síťovou komunikaci HTTPS kanálem nebo uživatelské sezení s prohlížečem, který hlavní stránku nahrál přes HTTPS.
Já tady tvrdím něco úplně jiného.
Tak ještě jednou a naposledy. Co kdo dá do URL je věc dotyčného a nikdo mu v tom nezabrání. Já si klidně vytvořím URL https://login.szn.cz/loginProcess?username=test&password=test&domain=seznam.cz nebo http://get-to-post.nickj.org/?https://login.szn.cz/loginProcess?username=test&password=test&domain=seznam.cz a Seznam ani Google ani nikdo jiný mi v tom nezabrání. A máte tam HTTPS i POST. Pokud tohle URL nezveřejním, je to v pořádku a ničemu nevadí, že jsem ty údaje zapsal ve formě URL. Pokud ho zveřejním, je to moje chyba, nikoho jiného – a nezáleží na tom, že jsem ty údaje zveřejnil zrovna ve formě URL. Když je zveřejním ve formě "login je test a heslo taky test", je to úplně stejný problém.
Na závěr pro vás mám ještě několik příkladů služeb, kde se bezpečnostní token předávaný v URL používá, a zatím bezpečnost těch řešení nezpochybnil nikdo kromě jednoho diskutujícího a dvou komiků na Lupě. Tady jsou: Dropbox, Google Calendar, drtivá většina ověření e-mailu při registraci (e-shopy, diskusní fóra apod.), drtivá většina resetů hesla přes e-mail, často zasílání faktur nebo odkazů na objednávky e-shopů, protokol OpenID, protokol OAuth.
Já myslím, že v Google nepoužívají odporný termit „jedu v SSL“, když chtějí říci „uživatel má ve webovém prohlížeči zobrazenu stránku, která se načetla přes HTTPS“. Okecáváte tady akorát vy, protože jste se chtěl zeptat na jeden konkrétní detail, a místo toho jste se zeptal na obecnou věc. Já jsem vám na tu obecnou otázku správně odpověděl, přičemž ta odpověď zahrnovala i tu odpověď, kterou vy jste si představoval na vaši otázku.
Jinak způsobem „vymyslím si odpověď a k ní vymyslím otázku“ zkouší ne příliš chytří učitelé. Ti nejhloupější pak ani neuznají jinou správnou odpověď a vyžadují, aby se zkoušený trefil do té jejich.
Tak například na Lupa.cz se přes můj OpenID účet přihlásíte pomocí http://www.lupa.cz/prihlasit/?do=form-mojeid-return&openid.assoc_handle:{xxxxxx}{xxxxxx}{xxxxxx}&openid.response_nonce:2000-01-01T00:00:00xxxxxxxx . Adresa mého kalendáře na Google Calendar: https://www.google.com/calendar/feeds/xxxxxxxxxxxxxxxxxxxxxx%40group.calendar.google.com/private-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/basic Moje soubory na Dropboxu si můžete zobrazit zde: https://www.dropbox.com/sh/xxxxxxxxxxxxxxxxxxxxxxxxxxxx Druhou a třetí adresu dokáže ze svého účtu získat i žák ZŠ – v Dropboxu stačí najet myší na složku, kterou chce s někým sdílet, objeví se tlačítko „Share link“ a pod ním je schovaný odkaz s bezpečnostním tokenem. V Google Calendar je to o pár kliknutí víc – kliknete na menu u příslušného kalendáře, a dole pak máte několik tlačítek podle formátu kalendáře a způsobu sdílení.
Fascinuje mne naivita čtenářů.
Děsí mne zásadní nepochopení ze strany autora článku, který tu pak šíří podobné dezinformace a paranoidní nesmysly mezi čtenáře.
Představa, že pomocí API pro čtení dat o pohybech někdo získá přistup k účtu, který by mohl jakkoli zneužít pro vykradení účtu, to je fakt absurdní.
A nebylo by lepší získat takhle rovnou přístup k Bankovnímu účtu?
"Přijdete k počítači, v prohlížeči si najdete Internetové bankovnictví, které někdo zapomněl odhlásit a je to. Není to tak, že by vám vyskočil na podnose na obrazovku, ale jak je jednou uživatel přihlášený do IB, nepotřebujete už nic dalšího, žádné zopakování hesla apod., co by člověk normálně čekal."
Naprosto souhlas. Jen dement si bude do Google stahovat data z banky. Nejde vůbec o to, že jsou readonly, ale i to jsou vysoce důvěrná data a nestojím o to, aby google měl k čemukoliv takto přístup a ty data na svých serverech. To fakt je pro dementy a nebo fanatické příznivce a nebo zaměstnance, co jim za tohle google platí.
U placení kartou (a mám pocit, že i v PayPalu a podobných systémech) to bývá tak, že software e-shopu dostane potvrzení od zúčtovacího systému banky, že zaplacení dané transakce proběhlo v pořádku, potom prohlásí transakci za hotovou. E-shop poté zboží uvolní k distribuci. Pokud by obchodník posílal zboží až potom co mu peníze na účet skutečně dorazí, občas byste se pěkně načekal...
Před 6 lety jsem odešel od GE k FIO kvůli poplatkům. Myslel jsem si tehdy že GE má dobré internetové bankovnictví, ale v porovnání s tím co má FIO je to dost slabé. FIO bankovnictví bude pravděpodobně nejlepší, už jen z toho důvodu, že ho mají ze všech bank nejdéle, byli před lety první, kdo internetové bankovnictví nabídli a dodnes si myslím, že mají velký náskok a jiné banky by u nic měly co okoukat.
V tom videu jde především o ukázání možností AppScriptu a napojení na API FIO banky je tam jen jako příklad.
Pan Novák z toho hned udělá kauzu, že Google vás navádí, aby jste mu dali přístup do banky a tu vám někdo vykrade přes ukradený smartphone.
Navíc předpokládám, že přes to API se dají maximálně stahovat výpisy z účtu..
Argumentů proti vaší teorii tu bylo napsáno už mraky, jen to asi nechcete vidět a furt si melete svůj kolovrátek.
Ale zkusím to zrekapitulovat.
Lež prvni: "nezabezpečené API"
Už jste sice pochopil, že read only přístup Fio banky je bezpečný a nelze pomocí něj vykrást účet, ale obratem jste si vymyslel teoretické "ale jiná banka to může mít i pro ovládání účtu".
To je stejná argumentace, že pan X je pedofil. Ne snad že by nějaké dítě zneužil, ale klidně to příště udělat může.
Fakt druhý: "read-only data o pohybu na účtu může Google zpracovat a použít proti mně".
- nikdo vas nenutí to používat
- už dneska google projíždí v GMailu emaily a vytězuje informace pro kontextovou reklamu. A lidi to akceptují. Tam je dale víc dat o tom, co jste si kde a kdy objednal a koupil.
- osobně mám nastaveno, že mi banka posílá emaily o změně zůstatku na účtu a o provedených transakcích. A necítím to jako ohrožení. I kdyby se mi do emailu někdo podíval.
Paranoia třetí: "data na Google Drive jsou nezabezpečená".
- je jen na vás, co tam nahráváte. Telefon, tablet i počítač máte mít zabezpečený, aby se vám do nich nikdo neoprávněný nedostal. Pak už nemusíte řešit zabezpečení heslem v samotné aplikaci. Pokud musíte zadat PIN už pro odemknutí displeje.
Mohl bych pokračovat. Ale už tohle byla promrhaná energie.
Predpokladam, ze si tam muzete (narozdil od banky) nastavit nejaka pravidla typu "kdyz vydaje presahnou XYZ, upozorni me na to", navic spousta bank (da se rict ze drtiva vetsina) neni schopna dat k dispozici data za vic nez rok (+-), coz je naprosto mimo ....
Tim nerikam, ze je dobrej napad nechat googla stahovat vypisy, ale i takovych dementu se jiste najde dost.
Tohle jste si nezjistil, vážený pane:
http://www.fio.cz/spolecnost-fio/media/tiskove-zpravy/122142-fio-banka-nabizi-bezpecne-automatizovane-ziskavani-dat-z-uctu
Jo, a ted tu o karkulce ... to bych chtelo mit aspon na 10 minut terminal, ze ... Obchodnik se dovi o platbe, ale ne od banky, platbu mu potvrdi platebni rozhrani. Na svem ucte ale uvidi jeste par dnu kulovy. A po tech par dnech, mu na ucer prijde rekneme mega (v jedny platbe), u toho vidi ze je to trebas "visa" a za par dalsi dnu mu od banky dorazi rozpis s ID plateb. Teprv na zaklade toho muze platby parovat.
Lež první, že někdo může takto ve Fio vykrást účet, tu vypustil někdo jiný. To jsem opravdu nepsal. Někdo tak mohl spojení "získat přístup" pochopit, ale opravdu to nutně nic takového neznamená.
2) Takže může. O tom jsem psal. Že vám to nevadí - v pořádku. I v závěru glosy jasně píšu, že komu to nevadí, ať do toho klidně jde. Nikomu nenutím, že mu to musí vadit. Ale stojím si za tím, že to tak je. Fakt, že tam někdo posílá citlivá data mailem, to nijak nemění.
3) Opět souhlasím. Kdo se z Googlu vždycky odhlašuje a zamyká si poctivě své zařízení, měl by být v tomto ohledu v bezpečí. Nenapsal jsem nic, co by tomu odporovalo, pouze si všímám, že aplikace pro bankovnictví jsou v tomto ohledu opatrnější.
Ale děkuji za snahu, škoda že takových věcnějších komentářů tu nebylo víc.
Myslím, že podsouváte autorovi něco, co vůbec neuvedl. Pokud tam budete mít uložené zmíněné údaje, je to Vaše chyba. Stejně jako u toho URL do FIO banky. A článek před tímto postupem varuje, tedy před ukládáním citlivých údajů na Google Drive, což je docela korektní. Nemyslíte?
Jen pro presnost, protoze vetsina diskutujicich API asi nezna. FIO umoznuje vygenerovat libovolny pocet tokenu a jejich platnost je povinne casove omezena. Takze jednak je muzete generovat s platnosti den/tyden/mesic a jednak je muzete selektivne revokovat.
Z hlediska zneuziti neni podstatne, jestli nekdo posila jmeno + heslo, nebo nahodne generovany token.
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).
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.
Pise clovek, kterej to vzivote nevidel, ja ty veci jen implementuju ... takze zjevne nevim jak to funguje. Obchodnik zadnou jinou moznost nema, protoze ty platebni systemy (v CR) jsou celkem asi 3 a z nich si musi vybrat. A pokud pouziva jednu z nasich bank typu CSOB, KB ... tak mu to chodi presne jak sem psal.
Takze si dal snete svoji pohadku, az se srazite s realitou, budete na to cumet jak puk.
Takže procesor do PC jste si navrhl a postavil sám, klávesnice a displej máte také vlastní výroby, operační systém a webový prohlížeč jste si taky naprogramoval sám, píšete sem zásadně přes HTTPS a to jste si také implementoval sám včetně ověření teoretických základů asymetrické kryptografie a ověření, že příslušné kryptografické funkce nemají nějaké boční kanály. Nejmenujete se náhodou Sheldon Cooper?
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.fetch("https://www.fio.cz/ib_api/rest/last/"+token+"/transactions.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.
Myslel jsem, že ta obecná odpověď bude stačit, abyste se sám zamyslel nad tím, čemu všemu věříte. Samozřejmě vám můžu vyjmenovat pár příkladů: výrobci hardwaru, který používáte; autoři softwaru; autoři kryptografických protokolů; matematici, kteří vytvořili teorie, na kterých ty kryptografické protokoly stojí.
Co to proboha plácáte? Pokud už budu takový paranoik, že si budu myslet, že procesor nebo klávesnice někam něco posílá (asi subprostorovou komunikací nebo jak), tak si to můžu aktivně ohlídat. Jestli vy nevidíte rozdíl mezí tímto a tím dát někomu vědomě a otevřeně možnost hrabat se v mých věcech, tak si budu myslet něco nelichotivého. Když jsou tak oblíbené analogie, tak jednu taky uvedu: je to stejné, jako mít byt zamčený a s dveřmi dokořán. Vloupání nezabráním, ale neposkytnu své věci dobrovolně každému joudovi, který jde okolo.
Kdyz uz jsme u tech URL, transakcni historie Raiffeisenbank se take zobrazuje pres proste URL, jen nejsou tak daleko, aby ji umeli poslat v json, ale princip je stejny jako u FIO, funguje to tak radove od roku 2003 a zatim jsem nenarazil na zadny pripad zneuziti nebo nekoho, kdo by to API rozporoval.
Jeste teda upresnim zneuziti toho URL, ne zneuziti jako takoveho, lidi co si nechaji ukrast pristupove udaje uz urcite nekolik bylo. Ma-li eshop fugovat samostatne, tak samozejme musi mit vsechny udaje pro pouziti API nekde v konfiguraci mit ulozene.
Myslím, že s vámi nejde diskutovat, protože si cucáte čísla z prstů. Podle vás nebude odhad dále od pravdy? Podle čeho? Pokládáte sám sebe za zdroj pravdy, když nemáte nic relevantního? A že jste nepochopil, jak to myslím s tím zobecněním, tak to je jiná věc. Mluvil jsem přesně o tom, co jsem psal na začátku. Nemáte sebemenší důkaz pro vaše tvrzení, takže z čeho vycházíte? Máte nějaký verifikovaný zdroj tedy kromě té vaší pravdy?
Ostatní jaksi je dost mimo ad diskuze o IT, protože jsme zde tuším neřešili zaměstnanost v ČR. Pokud byste to řešil relevantně, tak vyjdete z naprosto jiné demografie, protože ICT s tím nijak nesouvisí. Pointa ale byla jinde, ale to nečekám, že pochopíte.
No přesně tak. I na základní škole jste se učil tu matiku pochopit a ne namemorovat ne? Že máte věřit panu učiteli a bezhlavě to po něm opakovat. Nemluvě o VŠ. Já nememoroval slova profesorů, ale já se učil pochopit principy a ty si ověřit a dokázat. A protože dělám v té kryptografii tak přesně to je věda, kde nic neobhájíte bez jasných matematických důkazů. Nebo snad předpokládáte, že kryptografické metody fungují na naprostém utajení a nikdo je nesmí poznat a máte věřit evangelíkům z RSA, co nám řeknou? Bez důkazů? Pane kolego, to platilo v době enigmy, dneska již máte vše otevřené. Nemluvě o implementaci, kterou si každý pořádný klient ověřuje a to ať je to open source nebo i closed source řešení. Stejně tak u toho HW. Co si myslíte? Že ten HW vyrábí někdo z vakua? Že nepotřeboval vědou ověřené metody, které prošli veřejnou diskuzí? Pokud přijdete na akademii věd, tak poznáte, že tohle je základ celého rozvoje. Otevřenost a transparentnost. Žádné prohlášení nějakého guru, kterému mám věřit. Pokud budete kamuflovat, tak naštěstí dnes již vás nikdo nepřijme. Tedy pokud nežijete v Číně nebo Severní Korei, tam vaše premisa platí. Myslím, že oddělení víry a vědy a důkazů je naprosto jasné, kdo chce, ať je věřícím v Google nebo cokoliv jiného, jeho věc. Ale s vědou, bezpečnostní a důkazy to nemá nic společného a v době open source a tlaku na otevřená data ze strany státu i firem je to až absurdní.
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 :)
Nepodsouvejte mi váš způsob myšlení. Ano, ověřoval jsem si matematické teorie a to ještě na škole, když jsme měli Fermatův teorém a např. jeho důkaz. A chápu, o co se snažíte, ale je to nesmysl. Pochopitelně si neověřím, že měsíc je tam, co mi třeba řekne NASA. Pointa je jinde. Že já nebudu zvyšovat svoje rizika na základě víry a tam, kde se mě to zásadně dotýká. Viz. ta kryptografie, protože to dělám, tak si to pochopitelně ověřím včetně implementace. A řeč byla o tom, že tvrzení nějakého Hráčka je pro mě naprosto irelevantní. Podobně i kdyby to řekl kdokoliv z té firmy. Ta firma mi nic nedá, pokud dojde k problémům a já chráním své zájmy. A ty vůbec neohrožuje tvrzení NASA, že měsíc je tam, kde tvrdí, že je, proto jim klidně můžu věřit, protože to pro mě není žádné riziko.
Já jsem neřekl, že nikomu nedůvěřuju, ale že nikomu nevěřím, to je veliký a zásadní rozdíl. Já přemýšlím, to Vy špatně čtete.
Vaše příklady s Logitechem vs. Google jsou opravdu úsměvné :-) Když už chcete obhajovat svěřování soukromých dat do rukou nějakých firem, mohl jste si dát tu práci a vymyslet nějaký smysluplný argument.
Já vám odpovím v jedné věci, aby bylo vidět, jak si cucáte data z prstu. Přesně jste řekl, že tady je 2.5% lidí v ICT podle ČSÚ. To není žádný zlomek promile. Ostatní je už jen krajní spekulace, namátkou to rozdělení na dvě poloviny, které podle vašeho textu nemají určitou schopnost. Pominu to, že je irelevantní mluvit o demografii v souvislosti s demencí a navázanou na ICT skupinu, což samo o sobě je blbost. Ale budiž. řekněme, že populace má kvalifikovanou jen tuhle skupinu. Pak jen v rámci této množiny vymýšlíte fabulace o předpokladech nekvalifikace jedné nebo druhé poloviny, aniž by byly čímkoliv, ale opravdu čímkoliv věcně podložené. To je přesně to, co jsem psal, cucáte si je z prstu. A ostatní výpočet pak už je jen změť čísel, které jsou založené na fabulovaném základě, takže pokud ten je špatně. A jak jsem uvedl, celé je to offtopic toho, co jsem psal v úvodu. Víc nemám co dodat, protože opravdu nečekám, že to pochopíte viz vaše dva příspěvky, které jsou jen fabulace.
Já jsem neřekl, že nikomu nedůvěřuju, ale že nikomu nevěřím, to je veliký a zásadní rozdíl.
Ach so. Abych tomu lépe porozuměl, vzal jsem si na pomoc synonymický slovník. Důvěřovat, jediné synonymum je věřit. Zkusil jsem tedy druhý synonymický slovník -- důvěřovat, a jedno ze dvou synonym věřit. Tak ještě SSJČ -- a zase je ve výkladu jako alternativa slovo věřit. Zdá se, že české slovníky ten veliký a zásadní rozdíl ještě nepostřehly. Nebo že by důvěřovat a věřit byla synonyma, ale nedůvěřovat a nevěřit měly veliký a zásadně jiný význam?
Co je na příkladu Logitech vs. Google úsměvné? Googlu jak jsem pochopil nevěříte, tak stačí napsat, zda Logitechu věříte nebo ne. To je celkem snadné, ne?
KB umožňuje opravdu prohlížet data pouze 13 měsíců nazpět. :-( Ale můžete si zažádat o "archivní e-výpisy" kdy vám banka "připraví" požadované starší vípisy ke stažení a teď se něčeho raději chytněte: Za 1 Kč za stranu!!! Ano, chápete správně, laskavě vám umožní si stáhnout elektronický výpis a za každou stranu toho PDFka zaplatíte 1 Kč.
Managera, co tohle vymyslel, bych rád viděl, to musí být fakt exemplář. Ten až se v nějaké své managerské knížce dočte o "pay per click", tak to bude chtít jistě aplikovat coby způsob zpoplatnění elektronického bankovnictví... :-)
Četl jste o čem je tenhle článek? Nebo jste se zapojil až od půlky a proto to není k věci? :-)
Řeč je o stahování informací o svém účtu a svých platbách.
A jak u eBanky, tak u Komerčky, vidím uskutečněnou platbu kartu (v blokacích ke kartě) ihned. A to včetně všech informací, u jakého obchodníka byla platba uskutečněna. Jak banka ty údaje získává je mi docela jedno a je to pro mne nepodatatné. Stejně tak mne v tomhle případě nezajímá, kdy se informace objeví na účtu obchodníka, u kterého jsem nakupoval a kartou platil.
Navíc, on má informace ve svém pokladním systému a nebo webovem obchodu.
Rád bych znal důvod. V diskuzi se řeší moje motivace, můj psychický stav, moje vztahy s různými lidmi, že jsem troll, že jsem nějakou větou napsal něco jiného než jsem napsal, že píšu pod cizími jmény...
To je všechno bezesporu zajímavé, ale pro změnu mého názoru nebo přiznání chyby by někdo musel nějakou konkrétní najít. To urážením prostě nenahradíte. Je to moje první glosa na Lupě a tou diskuzí jsem opravdu zklamaný. Nadávek plno, k věci skoro nic.
I vy mi teď jistě odpovíte další nadávkou a ne vysvětlením, proč se určitě k provozním logům nikdo nepovolaný nedostane, proč jste si jistý, že Podmínky soukromí jsou sice napsané tak, že Google data může používat k cílení reklamy, ale své právo jistě nevyužije, nebo proč mám věřit, že získání tokenu z odemčeného počítače není hračka.
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í.
Mezi „může udělat“ a „dělá“ je dost podstatný rozdíl. Argumentem „může běžet na mém počítači a můžu od něj mít zdrojáky a zkontrolovat si, že je vše v pořádku a že ani omylem neumožní někomu jinému přístup k mým datům“ se taky dá vysvětlit, proč software nemá žádné bezpečnostní chyby. Jenže ve skutečnosti to nikdo nedělá ani reálně dělat nemůže, takže reálně je software plný bezpečnostních chyb.
Ostatně, reálná nabídka opensource účetního nebo fakturačního software taky není moc slavná.
Když věříte velké spoustě firem i lidí (nejspíš včetně Googlu), je trochu zvláštní psát, že není žádný důvod někomu věřit.
To, že všichni lidé (včetně vědců a byznysmenů) věří, je úplně normální, jinak to ani být nemůže. Problém je, že u spousty lidí je ta víra nereflektovaná. Takoví lidé se pak halasně chlubí, jak nevěří Googlu, ale je jim úplně jedno, že věří (jenom v oblasti IT) stovkám firem a lidí, kteří se nějak podíleli a podílejí na HW a SW jejich počítače a připojení k internetu.
S číslem 99,9 % nesouhlasíte? No tak byl to ode mne výstřel od pasu, ale daleko od pravdy to nebude.
Pokud vy soudíte jenom podle vaší osoby, maximálně podle vašeho okolí, tak děláte velikou chybu. Nezobecňujte ale vaše chyby na jiné.
1) ITáků je v populaci hodně pod procento.
2) Z ITáků stejně připadají v úvahu jenom administrátoři serverů, co pracovně nějaké mailservery oprašují. Protože provozovat mailserver nějak a provozovat ho s aktuálním profi know-how znamená rozdíl v tom, jestli to pojede nějak a bude to ztrácet spoustu mailů, nebo jestli to pojede dostatečně spolehlivě, aby se to dalo dlohodobě používat.
3) Ano, z IT adminů si provozuje vlastní server včetně mailserverů relativně hodně lidí - ale byl bych velmi skeptický k tom, kolik z nich provozuje server na vlastním HW (jako ostrý server na kterém jede jejich hlavní e-mail). Zejména s relativním poklesem ceny virtuálních serverů.
A pokud používá někdo virtuální server, tak tam už v principu je cesta, aby vaše data nebyla pouze vaše.
Takže číslo 0,1 % populace, které má svoje data skutečně pod dvou kontrolou považuji i tak za nadsazené číslo.
4) Pro účel diskuze můžeme klidně virtuální server definovat jako dostatečně bezpečné řešení, kdy poskytovatel sice má nástroje, jak se k vašim datům dostat, ale je malá pravděpodobnost, že to dělá.
I potom mi ale pořád vychází, že všichni lidé mimo části linuxových adminů jsou dementi. Tedy dle vaší logiky.
Aby Google mohl ta data nějak zneužít, také je musí dostat nějak ven (i když třeba v pozměněné podobě). Takže třeba v případě toho bankovního API je možnost, že si kterýkoli ze zákazníků všimne použití API v podivný čas z adres Google, a prozradí to ostatním. Pokud se v případě API loguje použití, je to dokonce mnohem pravděpodobnější, než že někdo bude zkoumat, co dělá jeho klávesnice.
Nic. Ale jak vás ty uložené kopie poškozují? Aby vás poškodili, musel by Google zjistit, co je to za data, nějak je zpracovat a zjistit, že třeba nakupujete u Apple. A na základě toho by vám třeba začal nabízet přechod na Android. teprve to by bylo zneužití – jenže to už s tím zase Google musí vyjít ven a hrozí tedy prozrazení.
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.
Mint a Google se liší v několika, někdo by řekl zcela nepodstatných detailech. Jenže právě o ně tu jde. Mint je především mnohem obšírnější v otázkách kolem bezpečnosti a ochrany soukromí. Sice i on předá vaše data třetím stranám, ale alespoň při tom slibuje anonymizaci. O vybílení konta nejde ani v jednom případě (alespoň u Fia, kde je přístup jen pro čtení). Jde především o to neadekvátně nízké zabezpečení (však srovnejte, co o tom píše ten mint) a o podmínky ochrany soukromí.
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í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.
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.
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
Č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.
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.
A tady je URL, pomocí kterého se můžete přihlásit na kurs síťové bezpečnosti:
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.response_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.
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.
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.
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?
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í :-)
Přijdete k počítači, v prohlížeči si otevřete Drive (k tomu obvykle heslo nepotřebujete) a tam už si v příslušném souboru token zobrazíte. Není to tak, že by vám vyskočil na podnose na obrazovku, ale jak je jednou uživatel přihlášený do Googlu, nepotřebujete už nic dalšího, žádné zopakování hesla apod., co by člověk normálně čekal.
Jistě. A také ho budete muset dát svému účetnímu programu. A ten to možná posílá někam kdo ví kam. Takhle to technické řešení fungovat musí.
Je to read-only API pro přístup k ůčtu. A psát v článku lži o tom že to umožní získat kompletní přístup k účtu je už hodně silné kafe. A jako read-only API pro přístup k účtu to prostě je udělané stejně jako všechna ostatní. Tak aby pomocí toho bylo možné automatizovat potřebné.
Vždy je s tím spojeno určité riziko ale nezle ho házet na Google.
Žádné tvrzení o tom, že to umožní získat kompletní přístup k účtu, v glose není. Tohle kafe tedy není ode mě.
U účetního programu jsem nemusel souhlasit s podmínkami, které říkají, že data mohou být použita za účelem zlepšování jejich služeb.
Typicky taky účetní program nenechá kohokoliv kolemjdoucího odnést si bez dalšího přístupový token.
Pánové z lupy, vysloužili jste si u mě mega facpalm roku :)
http://test.nodex.cz/87d9a4
Co myslite, akym stylom asi funguje www.mint.com ? Ponuka to iste co sa tu snazi ponuknut Google, ale funguje iba pre americke banky. Zaujimave, ze to tam vela ludi pouziva a neboja sa ze im niekto "vybieli" konto.
Pane Hráček, asi nevíte, co je to trolování. A nebo v Googlu si teď myslíte, že když někdo s vámi nesouhlasí a řekne to nahlas, že troluje? To, že upozorňuje na možná rizika je korektní. Nic špatného na tom není. Takže pokud někdo Vás neustále nechválí, že jste úžasní, tak je to hned trol? Nechcete rovnou začít dávat těm lidem ban, že si dovolili nesouhlasit?
smarja pokud vam nekdo neco da "zadarmo", tak je to v koncovce opravdu malokdy zdarma (necim za to zaplatite a v tomhle pripade se zda, ze svym soukromim). A podle me o tom ten clanek byl (aspon ja to tak pochopil), ze zadne obedy zdarma proste neexistuji (viz zaklady Ekonomie od Holmana).
Jestli si nekdo mysli ze Google dava zadarmo (bez protiplneni - at uz je jakekoliv) svuj vykon ci storage, tak mu to vyvracet nebudu, protoze to opravdu nema cenu.
Myslite, ze kdyz nechate Google stahnout vypis z banky, kde bude uvedeno, ze jste (napr.) PayPalem zaplatili xy a nekdo si v Adwords zaplati, ze na tyhle lidi co si tu konkurencni sluzbu koupili chce cilit (ukazovat jim svoje reklamy), ze mu to Google neumozni, kdyz za to dostane zaplaceno, tak uz opravdu nevim jaka skupina obyvatel cte Lupu.
Promiňte, ale čekal bych poněkud inteligentnější odpověď než tento obecný canc. Nevím, jestli na něj lze i odpovědět, protože jste nic neřekl. Ale vlastně ano, jde. Odpověď zní jednoduše pane kolego. Je to věda a je jsou to otevřené informace, systémy a data a držet se zdravého selského rozumu a hesla důvěřuj, ale prověřuj. Až napíšete něco konkrétního, rád Vám konkrétně i odpovím.
Debata je o tom, ze obchodnik - maje eshop, samozrejme pouziva api do banky, protoze je to cele zautomatizovano.
A kumulovane platby se nepouzivaji, kazda polozka prijde zvlast, kdyz se teda bavite i o kartach. Respektive by obchodnik musel byt silenec, aby si to nechal posilat kumulovane, protoze by si musel najat dalsi ucetni pro rozparovani.
Na takove blbosti co pisete, muzete mit normalne svoji IP, za to se nazavira.
Milý Maxi, já jsem uvedl, jak jsem k tomu číslu dospěl. Jestli se vám to nelíbí, tak to můžete rozporovat - ale o to jste se ani nepokusil.
Ale jestli vám nestačí hrubý odhad, mohu se opřít o data ČSÚ. IT odborníků je v ČR asi 2,5 % ze všech pracujících. Z toho polovina jsou IT technici, druhá polovina jsou "lepší" pozice.
Neumím snadno korelovat 7 milionů naší internetové populace na 5milionovou populaci pracujících, ale jistě ten podíl IT odborníků nebude zásadně odlišný. Většina VŠ studentů IT, kteří jsou schopni provozovat produkční e-mail, beztak pracuje na nějaký úvazek (a ne na brigády), takže už je ve statistice podchycena. Počet lidí, kteří jsou schopni provozovat produkční e-mail a nejsou zahrnuti ve stastitice pracujících bude zanedbatelný.
Z těch 2,5 % IT odborníků jsou tedy polovina technici bez schopnosti provozovat produkční e-mailový server a z té zbývající poloviny bude řádově polovina vývojářů/architektů/analytiků, kteří jsou schopni provozovat mail pokusně, ale né produkčně.
Tedy velmi hrubým 0,65 procent pracující populace jsou administrátoři schopní si provozovat vlastní e-mail.
Kolik z nich to dělá - tady opravdu nevím a spoléhám na odhady, které vidím v okolí. Každopádně hodně z adminů používá cizí e-mail (tedy e-mail, který provozuje někdo jiný) na víc, než jenom otravné registrace.
Kdybych jenom tak střelil, že celá polovina adminů jsou tak paranoidní, že nepoužívají cizí mail na nic jiného, než registrace, tak jsem to přehnal.
A kdybych řekl, že polovina z těch, provozují vlastní e-mail ho provozují i na vlastním železe, tak je jasné, že jsem to opět hodně přehnal.
Pak bych byl na 0,15%. Ale to je úplně nepodstatné, že je to 0,1 nebo 1% nebo dokonce 5%.
Pokud máte pocit, že postupuji ve svých úvahách chybně, tak mi nastiňte, jak to relevantně počítat jinak. Jaká jiná demografie je ta správná.Nemáte pocit, že bude velmi vysoká korelace mezi placeným adminem a člověkem, který je schopen provozovat svůj e-mail produkčně?
Pointa toho, co jsem se vám snažil napsat je ta, že drtivá většina populace používá cizí e-mail. Že počet lidí, který má svoje důvěrná data pod pouze svou kontrolou je minimální. A tedy že drtivá většina lidí má svoje důvěrná data u někoho cizího - což je podle vás možno vysvětlit pouze demencí, fanatismem, nebo zaplaceností.
Takže buď je vás normálních v populaci zlomek - anebo byste e-mailová data u někoho cizího neměl považovat za demenci.
Já tedy čekám, že to pochopíte.
To, jestli klávesnice někam něco posílá, si můžu bez problémů ověřit. Ale pořád to neznamená, že budu svá data poskytovat dobrovolně a s plným vědomím, ale to už jsem psal v minulém příspěvku.
Je mi úplně šumafuk, že Vy mi tady tvrdíte, že zneužití dat z Google je 0, to je totiž jenom Vaše domněnka, kterou nemůžete nijak dokázat. I kdyby tomu tak nakrásně bylo, jako že tomu nevěřím, tak to neznamená, že tomu tak bude vždy.
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.
pro spoustu lidi to muze byt fajn. Pouziva gmail a dalsi funkce google a tady to je doplnek. Muze si delat soucty plateb, prehledy a pod. ne kazdy umi anebo se mu chce si delat exporty z internetbankingu atd. A data v tabulce se zpracovavaji lip nez v internetbankingu. Takze je to celkem hezka vec. Ale souhlasim ze bezpecnost by mela byt resena jinak.
Ja mam nejdrazsi a nejlevnejsi banku. Raiffeisenbank, kde platim cca. 400 Kc mesicne "provoz", tak mi umozni divat se zpatky 370 dni. FIO, kde neplatim nic, mi umoznuje divat se neomezene zpatky (zatim 3 roky). Nechapu. U RB bohuzel musim jeste chvili byt, protoze tam stale dobihaji platby od zakazniku.
Ale pokud mám přístup k Googlu, mám přístup i měsíčním výpisům, čili stejný přístup jako zmiňované API. Zvyky jsou jiné, ale teorie o tom, že někdo přijde k cizímu počítači a získá přístup k Google a tím získá přístup k Read-Only API Fia je opravdu sci-fi. Vlastně ne sci-fi, spíš fantasy.
Než začnete mluvit o dementech, tak se to chce trochu zamyslet, abyste nebyl v podezření, že jste dement sám.
99,9% lidí nemá svůj e-mail pouze pod svou kontrolou. Má k němu přístup jeho poskytovatel placeného e-mailu, nebo freemailu.
Takže pro 99,9% lidí platí, že jejich vysoce důvěrná data svěřují někomu cizímu. Troufám si tvrdit, že v e-mailu má normální člověk mnohem důvěrnější data, než jsou data o pohybu na bankovním účtu. Ale ta data o pohybu na bankovním účtu poskytovatelé e-mailu často stejně mají, protože si mnoho lidí nechá posílat e-maily z banky.
Naprosto s Vámi souhlasím a máte úplnou pravdu ad demence. Taky většina lidí je dementních, stačí se podívat na Fejsbuk jak se desítky tisíc nechávají nachytat na opravdu dementně jednoduché triky a podvody. Jen s tím číslem 99.9% zcela nesouhlasím, protože k němu nemáte vůbec žádný relevantní důkaz. Podle mě je to jiné a každý soudíme jen podle své osoby nebo maximálně podle zkušenosti z blízkého okolí. To ale není statistický vzorek ani na promilové odhad natož udělat prakticky 100% výrok. Já osobně freemail mám na spamy, jinak používám svůj server, data mám šifrovaná a tak i moji zaměstnanci a partneři. Všude máme VPN, chráníme se. Na Linuxu a dalšími produkty tohle uděláte velmi levně. Jedině, kdy to moc nepoužíváme jsou např. anonymizační proxy, ale jinak citlivá data jako bankovní údaje velmi přísně hlídáme. Chráníme si naše data a to už jen proto, že si vážíme naše soukromí a chceme si ho zachovat. Že toto nedělá většina? Ano, to s Vámi souhlasím. Ale ona taky ta většina ty statisíce jsou fanouškové těch podvodných skupin a odpověď, proč to dělají jsem napsal již na začátku.
Už jsem psal, že nevěřím nikomu, stačí?
Úsměvné je na tom to, že se snažíte porovnávat dvě zcela odlišné situace, na jejichž důsledky absolutně nemůžu mít stejný vliv. Prostě jabka a buldozer.
S těmi synonymy jste mě opět rozesmál :-D Copak že znamená slovo synonymum? Otázka za 100 bodů ;-)
Maxi vy jste šlápl do něčeho nepěkného (váš původní příspěvek s demencí).
A místo, abyste to uznal, tak teď jenom kopete a snažíte se po mě vozit, že nemám exaktní data, tak aspoň otevřeně dělám nejlepší odhady, jaké umím.
Je to celkem fajn diskuzní metoda - popírat zjevnou věc, protože nemám dost přesná data. Proto jsem v závěru napsal, že je úplně jedno, jestli to číslo je třeba i 5%. Pořád je to naprostá menšina populace.
Jasně, že je to celé offtopic, ale já bych se do těch odhadů, kolik tak lidí si samo provozuje mail vůbec nepouštěl - kdybyste nepsal o tom, jak vy máte vlastní mail a taktéž všichni vaši zaměstnanci a partneři.
Takže sem klidně ještě jednou napište příspěvek plný slov jako fabulace a užijte si večer a den.
Proboha, podívejte se na to původní video. Filip pomocí Apps Scriptu harvestuje dostupná data. Apps Script je v tomto případě pouze harvestovací nástroj na DOSTUPNÁ data. Já opravdu netuším, proč je v tomto článku Google ten zlý.
Pokud bude Filip pomocí Apps Scriptu harvestovat do tabulky aktuální teploty počasí z dostupných dat, tak to bude také špatně?
Samotné spojení „získat přístup“ něco takového nutně znamenat nemusí. Ale v kontextu článku to rozhodně znamená. Celý článek totiž před něčím velmi varujete. A když vlastně nikde pořádně nenapíšete, před čím, čtenář logicky získá dojem, že to musí být minimálně zveřejnění plného přístupu k bankovnímu účtu.
Kdybyste se totiž nesnažil hledat senzaci tam, kde není, a popsal to pravdivě, čtenář by si z článku odnesl úplně něco jiného. A nikdo by se nemusel dohadovat, co znamená spojení „získat přístup“. Jenže co by na tom bylo zajímavého? Banky často umožňují readonly přístup k účtu pro účely automatizovaného zpracování výpisu z účtu. K použití API zpracování není potřeba žádný specializovaný software na počítači, existují cloudové služby, díky kterým můžete s API pracovat. Při použití toho API je nutné uvědomit si, kam zadáváte přístupový kód k API a kdo tedy může k údajům teoreticky získat přístup. To už ale není taková senzace a těžko se k tomu připojují kopance, že?
Součástí URL může být i jméno a heslo. Chápu, že ne každý musí znát postupy zabezpečení přístupu na webu, ale tak aspoň na této neznalosti nestavte své rozsáhlé teorie. Zvlášť když vám lidé, kteří ty postupy znají, opakovaně píšou, že dvojice jméno a heslo nebo přihlašovací token je jedno a to samé, liší se to jen formálně. Když si hesla volí uživatelé, není zajištěna jejich unikátnost, tak se k heslu přidává unikátní přihlašovací jméno – tím odlišíte různé uživatele se stejným heslem. Když to heslo generuje aplikace a je zajištěna jeho unikátnost, nepotřebujete k tomu další údaj v podobě přihlašovacího jména. Tomu heslu se pak neříká heslo, ale např. přihlašovací token. Je to ale pořád jedno a to samé.
To, že je potřeba přihlašovací token uchovávat v tajnosti, je samozřejmě v dokumentaci API napsané.
Přihlášení přes přihlašovací token se používá často, používá ho třeba účet Google, Facebook, Dropbox, používá se při přihlášení přes OpenID (takže se s ním můžete přihlásit i tady na Lupě). Ve všech těchto případech je ten token součástí URL. Ještě častější případ je, kdy je přihlašovací token uložen v cookie, tak je řešena velká většina přihlašovacích formulářů na webu. Spousta z těch webů má implementován fallback, a když prohlížeč nepodporuje cookies, vloží se token – překvapivě – do URL.
Takže z přihlašovacích tokenů v URL určitě strach mít nemusíte. Navíc každý, kdo ho chce použít, se dozví, že přihlašovací token odpovídá heslu a je potřeba ho uchovávat v tajnosti.
Pořád tvrdíte, že jsou někde nějaké výrazné rozdíly, jedno je bezpečné a druhé ne. Tak tady máte schválně několik URL vytvořených oběma způsoby, o kterých tu diskutujeme, a můžete je rozdělit na ta bezpečná a nebezpečná a napsat, proč je rozdělujete zrovna takhle?
Přihlašovací jméno: jan.novak
Heslo: maruska
http://example.com/login
Bezpečnostní token: n]wPPnaT'][gT+'Nnr)f[T~bqz3sJ;w(
http://example.com/api/{token}/rest/
http://example.com/login?username=jan.novak&password=maruska
http://example.com/login?login=jan.novak:maruska
http://example.com/login?login=69bd35a5c927a2c1f2557d8aef9cce10
http://example.com/login?token=n]wPPnaT'][gT+'Nnr)f[T~bqz3sJ;w(
http://jan.novak:maruska@example.com/login
http://n]wPPnaT'][gT+'Nnr)f[T~bqz3sJ;w(@example.com/login
http://69bd35a5c927a2c1f2557d8aef9cce10@example.com/login
Jenom připomínám, že se tu celou dobu bavíme o tom, že uživatel má tu adresu uloženou v nějakém skriptu, takže je úplně jedno, zda se používá GET nebo POST a zda se parametry přenášejí v URL, v hlavičkách nebo v těle požadavku.
V předchozím příspěvku jsem vás nechtěl nijak napadat. Ale pořád píšete o tom, že je rozdíl, jestli něco nazvu heslo nebo bezpečnostní token nebo bezpečnostní URL – z čehož je zřejmé, že toho o zabezpečení moc nevíte. A pak jsou opravdu jen dvě možnosti – buď budete věřit, když vám další lidi tvrdí, že bezpečnost opravdu nezávisí na tom, jak si co lidé pojmenují, nebo si o tom něco nastudujete a ověříte si to sám.
O pár komentářů výš jste psal, že nevěříte nikomu a ničemu. Teď už to zase vypadá, že spoustě věcí věříte. Rozhodnout, které ze dvou vašich navzájem protichůdných tvrzení je pravdivé, není otázka chytrosti čtenáře. To musíte udělat vy. Nebo můžeme zůstat u toho, že jste v rozmezí pár hodin tvrdil obojí, a že v tom tedy sám nemáte jasno.
To není argument, to je jen informace o tom, jaký je celý váš komentář. Argumenty byly v předchozím komentáři, vy jste jen napsal, že je to jinak, ale žádný důkaz jste neuvedl. Každý, kdo má účet na Google Calendar nebo na Dropboxu, a každý, kdo zná nějaký link na sdílení z některé z těch služeb, si to může ověřit. Tak abyste nemusel psát nesmysly o věcech, o kterých nic nevíte, podělím se s vámi o link na sdílení jednoho kalendáře, u kterého mi nevadí, že se zveřejní (ostatně, nejsem jeho autorem a dostal jsem se k němu právě tak, že mi někdo poslal odkaz): https://www.google.com/calendar/embed?src=jnv1189bt6iik6en4590n25fa4%40group.calendar.google.com&ctz=Europe/Prague . Sdílet s vámi nic ze svého Dropboxu nehodlám, ale jiní některé složky ze svého Dropbox účtu zveřejňují: https://www.dropbox.com/sh/d15vvo4h7h88xx2/aLdsKAd0qZ
Jaké nastavení URL netuším, to jste psal vy.
Vy jste použil sdílení s uživateli Google Calendar. Tam se ovšem k přístupu nepoužívá bezpečnostní token, ale přihlašovací údaje k Google účtu. Vedle toho ale ještě existuje sdílení pomocí bezpečnostního tokenu, Google to v české verzi nazývá "Soukromá adresa".
Sláva, aspoň u toho Dropboxu jste to konečně uznal. Možnost, jak veřejné sdílení obejít, je velice jednoduchá -- nezveřejňovat danou adresu, ale poskytnout ji jen tomu, s kým chcete složku sdílet.
A kolik firem asi používá účetní nebo fakturační software? Myslíte si, že když si něco koupíte ve velkém e-shopu jako Mall.cz nebo CZC, čekají tam až jim přijde papírový výpis z účtu a pak jej přepisují do e-shopu? Nebo má spíš e-shop automatický přístup k výpisu z účtu?
Ale vaše otázka je vlastně dobrá. Jaký je asi objem transakcí na osobních účtech a účtech malých živnostníků (kde výpis účtu vidí opravdu jen majitel) v porovnání s objemem transakcí na podnikatelských účtech, kde na výpis z účtu vidí jedna či více aplikací?
Píšete sice hezky, ale o něčem jiném, než jsem psal já. Vy jste si návrh procesoru v PC, který používáte, ověřoval? Dokázal jste, že je tam vše v pořádku? Pak jste dokázal, že je procesor vyroben podle toho návrhu? RSA jste si ověřil? Ověřil jste si ty matematické teorie, které jsou za tím? Dokázal jste, že P ≠ NP? Nebo tomu všemu (nebo alespoň něčemu) prostě věříte?
Já vůbec nemám problém s tím, že něčemu věříte – každý věří spoustě tvrzení. Problém je v tom, že vy sám nevíte, čemu a proč věříte, takže se rozhodujete naprosto iracionálně: Google ne, Intel ano, X ne, Y ano…
Pokud opravdu máte něco společného s bezpečností, musíte vědět, že na takhle nejasně položenou otázku se nedá jednoznačně odpovědět. Komunikace může být tunelována skrz SSL, ale k údajům je možné se dostat před začátkem tunelu (např. ve webovém prohlížeči, v OS, v klávesnici, v souboru na disku) nebo za koncem tunelu (na cílovém serveru). Je v takovém případě odpověď na vaši otázku ano nebo ne? Dál může být chybná implementace SSL (např. se vytváří slabé klíče), může být chyba v návrhu SSL, může někdo mít kvantový počítač, kterým dokáže faktorizovat i větší čísla než 12, může někdo mít důkaz P=NP. Každý (včetně vás, i když tvrdíte opak) věří, že něco z toho neplatí – a často i různě pro různé věci. Třeba pro e-mail věřím i tomu, že implementace SSL v daném programu je správně, pro získání výpisu z účtu taky, ale pro podání platebního příkazu už tomu nevěřím a chci nějaké další zabezpečení.
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.
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.
Jenže účetní nebo fakturační SW (nebo třeba tabulkový kalkulátor) může běžet na tvém počítači a můžeš od něj mít zdrojáky a zkontrolovat si, že je vše v pořádku a že nekrade a nezneužívá tvoje data.
Odeslat data na server třetí strany a doufat, že je nezneužije, je ale něco úplně jiného.
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.
Není žádný důvod Google věřit jako komukoliv jinému. Chápu, že pro vás je to bohatá firma, má peníze, vliv moc. Je to uhrančivé a lidé dnes hodnotí jen podle peněz. Ale ať tady nikdo nebrečí nad úpadkem Lupy, ať nenadává na Blesk, Novu a další. Jsou to zcela stejná média a monetizují svůj byznys model stejně jako Google. A jediné, co máme podle Vaší teorie udělat je to, že máme věřit těmto firmám jejich sliby a proklamace. Každá firma takové proklamace má, nejlépe od svého tiskového mluvčího, který má zametat špínu. Chci jen říci, že se posouváme od faktů k víře, kdy naším bohem jsou v tomto náboženství peníze a moc. Hodnotíme podle toho, jak silně pozlacené má která ta firma svoje zlaté tele. Můžete věřit proklamacím nějakého Hráčka a nebo lidí, které jste v životě neviděl a nikdy neuvidíte a nemáte sebemenší možnost, jak si ty proklamace ověřit. To je znak víry, nemáte důkazy, není možnost je ověřit a replikovat jako ve vědě. Nic proti víře, ale podle mne do vědy a do byznysu nepatří.
Promiňte, ale dávat dobrovolně soukromá data jakékoliv firmě nebo obecně nějakému subjektu, pokud to není nezbytně nutné, je podle mě činnost hraničící s demencí. Nevěřím nikomu, ani Google, ani bankám, ani naší vládě nebo poslancům. Můžu někomu pouze do jisté míry důvěřovat, to záleží na okolnostech. Co se týče slibů, netuším, o jakých jiných případech to píšete.
Mj. jde taky u pravděpodobnost odhalení – teoreticky můžou být v klávesnici zadní vrátka nicméně data je potřeba odtamtud nějak dostat – třeba je vysílat rádiově. Taky je možnost, že kterýkoli ze zákazníků svoji klávesnici rozebere a prozradí to ostatním… Oproti tomu, když svoje data někomu odevzdám, centralizují se u něj a nikdo ho nekontroluje ani kontrolovat nemůže, tak mi zbývá jen doufat, že je nezneužije – a on je klidně může zneužívat, aniž by se to na dlouho přišlo.
Obávám se, že stavíš na domněnkách a klišé. Já mám jinou metodu. Bezpečnost* musí být prokazatelná/prověř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.
Jasne ty implementatore, chodi to v jednom milionu jednou rocne, boze to jsou debilove tady. To ze pomahas s nejakym kodem jako elev je jiste dobry zacatek, ja dene paruju (respektive jsem pred tak osmi lety paroval, ted to dela kolega) desitky plateb z karet, dobirek apod. Je to radku jak indu v indii.
Jestli to chapu dobre, tak lidi si tady doted mysleli, ze banky nemaji API a ze pro parovani a zejmena pro placeni se musi nekam logovat a pet hodin kazdy den musi klikat a autorizovat SMS.
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.
Pan Hráček se podle mého soudu zachoval neprofesionálně. Mohla to být normální technická debata jakých jsou za den tisíce. Četla jsem diskuzi na G+ a pan Hráček zbytečně zaútočil a nenapsal tam nic věcného poté, co zazněl kritický komentář. Má komunikovat s vývojáři, vysvětlovat a pokud ho někdo kritizuje, má vysvětlit, ale nikdy nepřecházet do osobní roviny a ještě s invektivou. Má držet věcný obsah diskuze. Jeho postup pokládám za silně neprofesionální a je to ostuda pro Google a vzor toho, jak se zástupce firmy nemá chovat.
Na základě příspěvku uživatele Cohen, jsem se rozhodla přečíst si ještě jednou celý článek, odpověď pana Hráčka i diskuzi na G+ a na Lupě. A musím říci, že se opakuje situace z historie. Velkým problémem je pan Dočekal. Jeho články oscilují mezi až nenávistí vůči Facebook a jeho porušování privacy a kontrastují se servilitou vůči lidem nebo firmám, co si z nějakého důvodu oblíbil. Nemám nic proti kritice Facebooku, je zcela na místě, ale stejně tak je nutné mít vyváženou žurnalistiku, hodnotit stejně kriticky ostatní jako např. Google. Jsme přesvědčená, že kdyby něco takového předvedl evangelista Facebooku, Dočekal ho roznese na kopytech a obvinil by Facebook i ze zločinného jednání. Má snahu věci buď bagatelizovat a nebo extrémně přehnat, není to vyvážená reakce a už vůbec ne žurnalistika.
Profesionální žurnalista se má snažit psát vyváženě a z jeho práce nemá být cítit zaujatost a neobjektivita. A pan Dočekal roky ukazuje, že neumí hodnotit věci vyrovnaně a vyváženě. Jeho reakce jsou ve většině zbytečně útočné a tam, kde se tento pán objeví, to obvykle končí hádkou a nadávkami viz. diskuze na G+. Jako kdyby je tento pán přitahoval nebo vyvolával svojí povahou.
Už se o tom píše několik let a Lupa ho drží jen proto, že bulvár umí rozpoutat diskuze, to znamená imprese a to jsou peníze. Dlouhodobě ale kvalita klesá a pověst Lupy také. Pokud se chce Lupa posunou do bulváru, ať to veřejně deklaruje, je vše jasné a nemusíme si tu na nic hrát a ztrácet čas. Pak je Dočekal ten pravý autor. V opačném případě je to nejhorší pisatel, když pominu jeho sklony grafomana a sběratele dat.
Hracku Hracku, zatim me pripada podle vasich reakci, ze se o neuspesny trolling pokousite vy, vzhledem k tomu, ale pro koho pracujete me to ani neprekvapuje, Google se dlouhodobe programove vyhybava odpovedim na kontroverzni kroky, ktere pomalicku plizive prosazuje. (parovani emailovych uctu, vymahani telefonich cisel k temto...apod) pro Google je slovo soukromi uzivatele holt sproste slovo.
Pokud je vasi praci psat v co nejvice vetach a nerici nic, tak gratuluji, za toto budou premie :).
Uživatel Max nic takového nepředvedl. Ono to ani nejde. URL není žádný objekt, do kterého něco dám a ono to někde bude. Každý si může vytvořit URL, jaké chce, a nikdo mu v tom nezabrání. Když já zveřejním URL https://login.szn.cz/loginProcess?username=test@example.com&password=test , tak jsem tím právě zveřejnil přihlašovací údaje k e-mailové schránce na Seznam.cz, ale rozhodně to není chyba Seznamu. A hlavně Seznam s tím nemůže vůbec nic udělat, nijak mi v tom nemůže zabránit. I kdyby třeba zakázal přihlašování metodou GET, pořád tím nikomu nezabrání napsat si skript, který to URL rozparsuje a pošle je metodou POST s parametry pěkně v těle požadavku. Stejně, jako může někde „vyběhnout“ URL, může tam vyběhnout cokoli jiného – HTTP hlavičky, cookies, tělo požadavku.
Vaše právní hledisko lze snadno vyřešit tak, že do zdrojového kódu toho skriptu nebudu psát bezpecnostni_token=bflmpsvz, ale napíšu tam heslo=bflmpsvz.
Technicky nějaká magie frameworku nezachrání to, když programátor vůbec netuší, co dělá. Když ty přihlašovací údaje nebudou v URL, ale pošlou se v těle požadavku nebo v hlavičkách, WCF ani nikdo jiný s tím nic neudělá.
jak jistě víte, URL specifikace je nedoporučuje, protože jsou považovány za bezpečnostní riziko
Naštěstí nic takového nevím, protože autoři URL specifikace věděli, co je URL, a tak by netvrdili takový nesmysl. Bezpečnostní riziko je zveřejnění přihlašovacího jména a hesla, bezpečnostního tokenu nebo jejich ekvivalentů, a to bez ohledu na to, jak se zveřejní.
V prvním odstavci jsou dva odkazy, druhý zavolá přihlašovací formulář Seznam.cz metodou POST a předá zadané přihlašovací jméno, heslo a doménu. Můžete se přesvědčit třeba ve FireBugu nebo vývojářské konzoli Google Chrome.
Žádný příklad uvedený v druhém odstavci není vázán žádnou další metodou autentizace, schválně jsem vybral takové příklady, kde se veškeré údaje předávají jen v URL metodou HTTP GET. V případě OpenID a OAuth je to při přesměrování na poskytovatele autentizační služby a zpět, v případě Dropboxu je to při volání API (stejně jako u té Fio Banky), v případě Google Calendar je to tehdy, když chcete dát přístup do kalendáře někomu dalšímu.
Tvrdíte tedy, že existence URL s bezpečnostním tokenem k mému Google kalendáři znamená zveřejnění tohoto kalendáře? Dobře, co mám tedy v kalendáři na dnešek naplánováno?
Ten odkaz na přihlášení přes OpenID samozřejmě samotný fungovat bude (v případě OpenID omezenou dobu), jinak bych se s jeho pomocí nemohl přihlásit. Pokud by ho někdo v době jeho platnosti získal, normálně se mým účtem přihlásí.
Zaměnil jsem pořadí odkazů na kalendář a na Dropbox, omlouvám se.
S tím zveřejněním máte pravdu. Ale na druhou stranu se snad shodneme na tom, že pokud kromě uzavřeného okruhu osob tu informaci neví nikdo a nemůže ji nikde nalézt, je to informace privátní. Přičemž podle mne vůbec nezáleží na tom, zda se ta privátní informace skládá ze dvou částí -- jména a hesla, nebo zda je to jedna část -- bezpečnostní token.
Na Lupě neexistuje taková bezpečnostní díra, jakou si představujete. To je normální vlastnost OpenID protokolu -- někde se autentizujete, a následně jste z té autentizační stránky přesměrován zpět na stránku toho, kdo autentizaci vyžádal. Neexistuje tam žádný postranní kanál, všechny informace nutné k ověření se tedy musí předat v parametrech během toho přesměrování. Normálně tyhle údaje získá jen uživatelův prohlížeč a přesměrováním se dokončí přihlášení na původní stránku. Ale pokud je někdo zachytí (třeba kvůli nešifrovanému HTTP), může samozřejmě udělat úplně to samé, co by jinak udělal uživatelův prohlížeč. Cookies v tom nijak nepomohou, ty se posílají ve stejném požadavku jako ty ostatní údaje.
Replay útok je něco jiného, tam se jedná o zopakování stejných informací k nové akci (např. novému přihlášení). Já jsem ale psal o případu, kdy někdo ty autentizační informace získá a pošle je na Lupu dřív, než oprávněný uživatel. Pak bude oprávněný uživatel až druhý v pořadí a obrana proti replay útoku zastaví nanejvýš jeho.
Pravdu nemáte, mezi mým prohlížečem a serverem Lupa.cz neexistuje žádný nezávislý kanál, pomocí kterého by si mohly vyměnit nějaké další informace, a pokud se použije HTTP, neexistuje mezi nimi ani šifrované spojení. Ostatně je to úplně to samé, jako když se přihlašujete pomocí jména a hesla -- pokud někdo odchytí daný požadavek na server, přihlásí se pomocí něj místo vás. OpenID nijak neřeší (ani nemůže) ochranu přenášených informací, řeší jenom to, že se na Lupě můžete přihlásit pomocí přihlašovacích údajů třetí strany, ale Lupě ty přihlašovací údaje nedáte k dispozici. No a řeší se to právě přes ten bezpečnostní token -- Lupa si s OpenID poskytovatelem dohodne bezpečnostní token, vy se pak u OpenID poskytovatele přihlásíte třeba jménem a heslem a poskytovatel pak Lupě řekne, že onen bezpečnostní token je OK.
Zase špatně. Jediný správný odstavec je ta citace, kterou jste ovšem nepochopil. Nezáleží na žádném nastavení adresy, ale prostě na tom, komu tu adresu dáte. Když ji zveřejníte, sdílíte kalendář se všemi uživateli, když ji dáte konkrétním lidem, sdílíte kalendář s konkrétními lidmi. Na Dropboxu je to stejné. Přes adresu složky (obsahující bezpečnostní token) v Dropboxu se k souborům dostane bez přihlášení, dostane se tam i ten, kdo nemá na Dropboxu vůbec žádný účet, takže se ani nemůže nijak přihlásit. Kdybyste si kliknul na odkaz na složku v Dropboxu, který jsem dával o pár komentářů výš, tak byste to zjistil také. To samé s kalendářem. Ale zřejmě máte fóbii z klikání na odkazy, tak tady radši pořád dokola plácáte nesmysly.
A sám to velmi dobře tušíte. Protože jinak byste si ve svém účtu na Dropboxu založil nějakou složku, nahrál tam nějaké své soubory, kliknul na „Share link“ té složky a získaný odkaz pro sdílení zde zveřejnil. Tím byste dokázal, že sám věříte tomu, co píšete. Jenže vy tomu sám nevěříte, takže nic takového neuděláte. Do té doby, než na to budete mít odvahu, můžeme tuto diskusi přerušit.
Nestačím se divit. Pan Hráček zde zastupuje firmu Googlu a měl by se podle toho i chovat!
Místo toho svého klienta odpálkuje výroky ve stylu "sto nepochopil", "netroluj", "nic vo tom nevíš"....
Úplně tam chybí ještě nějaké opepření ve stylu "debile, vole, pyča"!
Opravdu je tohle styl, jakým má nadnárodní mocná firma komunikovat se svými českými uživateli????? Navíc v okamžiku, kdy se jedná o citlivou otázku soukromí a bezpečnosti!!!!
Dovolil by si tohle zaměstnanec nějaké automobilky, nebo nadnárodního řetězce? Pošlu dotaz na PR Google, třeba k tomu budou mít co říct!