Názory k článku Jaké změny čekají datové schránky?

Průser už trvá tři roky, a to je § 72 daňového zákona s jeho sankcí 2000 Kč.Což postihlo podle vikipedie 12 000 daňových poplatníků. Dobrý kšeft pro stát ca 24 000 000 za nic.

Autor nemá úplně pravdu v tom, že použitím certifikátu od Verisignu se uživatel nebude muset zabývat instalací (importem) kořenového certifikátu od PostSignumu.
V případě komunikace tomu tak skutečně bude (SSL), ale pokud má uživatel ověřovat uznávané elektronické podpisy OVM, které jsou v drtivé většině založeny na kořenovém certifikátu PostSignumu, stejně musí instalovat kořenový certifikátu od PostSignumu.
Stejně tak budou od 1. ledna 2010 v souladu s povinnou informací vydanou Ministerstvem vnitra České republiky vydávány zaměstnanecké certifikáty OVM s délkou klíče 2048 bitů a hashovací funkcí z rodiny SHA-2 (pravděpodobně SHA-256). Pro ověřování uznávaných elektronických podpisů tedy bude nutné instalovat i odpovídající kořenový certifikát. "Výhoda" certifikátu Verisignu s hashovací funkcí SHA-1 se mi jeví jako hodně malá, resp. nulová.
A na závěr: pokud se zabýváme bezpečností, pak bych patchování operačního systému (instalaci nejen SP3, ale i všech dalších patchu) předpokládal jako základ a nedovolil bych si to uvádět jako prolém.

S IP adresou už se točíme dost dlouho v kruhu, takže to dál nemá smysl. A nic jsem nevynechal, opět, to, že by byl útočník uživateli blízko je spíš mizivý procento útoků, a jinak to může pomoct.

Tak nekompatibility jsou. Někdy za to může chybně nastavenej server, někdy chyba v prohlížeči (je jich spoustu i v MSIE 8, dokonce takových, který MS odmítá opravit, a opraví je prej až v MSIE 9), ale to neznamená, že by to bránilo používání.

Ale diskuze byla zajímavá...

Odmítnutí autentizace klienta slabým algoritmem je oprávněné, protože to řeší bezpečnostní problém – kontrola IP adresy nic takového neřeší. Zvlášť když se používá (rozumně nastavené) SSL, protože pak je jediná možnost úniku session ID ze serveru nebo z prohlížeče uživatele – a v obou případech je kontrola IP adresy klienta k ničemu.

To nejdůležitější jste u MITM vynechal – totiž že útočník může být „velmi blízko“ uživateli. A tam právě kontrola IP adresy selže. Takže pokud chcete bránit MITM útoku u HTTP, kontrola IP adresy k tomu nestačí.

MD5 u digest autentizace zatím nevadí, ale je pravda, že pokud se má algoritmus změnit, mělo by se s tím začít co nejdřív, aby se to stihlo. U webu se momentálně řeší podružnosti typu HTML5 nebo videa, takže nějaká digest autentizace skoro nikoho nezajímá. Ani s tou lehkostí nasazení to není tak růžové – zrovna nedávno jsem narazil na problém (a zatím neznám řešení) mezi Apachem a MSIE7, kdy MSIE7 se na výzvu serveru sice uživatele zeptá na heslo, ale hlavičku Authorization pak nepošle. Proti jinému serveru (Jetty) to přitom fungovalo, takže MSIE7 vadí asi nějaká specifická kombinace parametrů výzvy. Člověk by čekal, že v roce 2009 už nebudou s implementací tak široce používaného protokolu, jakým je HTTP, problémy, ale opak je pravdou (jmenovaný problém samozřejmě není jediný).

Je to úplně to stejný, jako když server odmítne autentizaci u klienta, kterej mu na žádost serveru o inicializaci SSL odpoví zastaralým algoritmem s krátkou délkou klíče. Některý adminy fakt nezajímá, že uživatel pochází z Británie, kde komanči brzy asi zakážou i šifrování obecně, nebo z Číny, nebo má zastaralý prohlížeč MSIE s vynucenou krátkou délkou klíče ještě do nedávný doby. Zásady zabezpečení serveru má nastaveny od majitele nebo správce prostě takový, a basta. Kdo je z příslušný strany neschopnej (jestli uživatel/admin/vláda...) je serveru docela šumafuk.

MITM samozřejmě vůbec neznamená "uprostřed", ale i třeba těsně před serverem, nebo paralelně úplně někde jinde, takže zase jsme u pravděpodobnosti, co je ještě "k něčemu" a co podle vás "k ničemu".

Digest autentizace by byla zajímavá i do budoucna, kdyby se už odstřihla od MD5, protože jinak by to mohla být (až na to "ošklivý okno" generovaný prohlížečem, jak tu někdo zmínil) celkem slušná věc, i třeba jako nouzovka mimo SSL/TLS. Navíc je implementace primitivní, v zásadě to může obsluhovat server včetně toho, že se do kódu služby/stránek ani nešáhne (zvlášť na Apachi), což je i obrana proti chybné a relativně složité implementaci autentizace v kódu, a s úspěchem to bezpečně může realizovat i začínající správce stránek.

Jednorázový kód jsem nemyslel ohledně autentizace, ale autorizace. Ono, autentizace by byla útočníkovi k ničemu, když by pak už nemohl udělat vůbec nic, že.

To je od vás hezké, že víte o všech sítích na světě, jestli jejich administrátor má nebo nemá nějaký důvod pro to, aby se IP adresa v rámci jedné session změnila. Určitě vám nebude vadit, když správce nějaké sítě na oplátku usoudí, že jeho uživatelé váš web nepotřebují a na bráně jej zakáže. Je to rozhodnutí plně stejného druhu – rozhoduje o něčem, do čeho mu vůbec nic není.

Proti útokům MITM není kontrola IP adresy žádná ochrana. Je to ochrana proti útokům, kdy útočník není uprostřed, ale někde co nejdál od uživatele. Protože když bude útočník uživateli blízko, může vůči serveru snadno vystupovat se stejnou IP adresou, jako uživatel, a vaše kontrola IP adresy je pak k ničemu. Proti MITM pomůže buď šifrování nebo digest autentizace.

Proti únosu session nepomůže ani jednorázový kód, ale jedině autentizace každého jednotlivého požadavku.

Takže bych to ze svý strany uzavřel...

IP adresa
- Ano, jistě, je to na adminech příslušný sítě/clusteru/proxy, a na web adminech a jejich nadřízených (případně vlastníka domény/služby) je zase, jestli je nutný takový uživatele plně podporovat a nebo je nechat se co půl minuty znovu přihlašovat, protože dneska není žádnej rozumnej důvod měnit IP adresu v limitu menším než desítky minut. Stejně tak je na web adminech zvážení rozsahu podpory starých verzí prohlížečů, starých verzí proxyn, který někdy posílají v hlavičkách neplatný paskvily atd.

Ale proti útokům MITM je to silná ochrana (pokud si uživatel zkontroluje certifikát a prohlížeč kontroluje CRL), srovnávat to s kontrolou IP adresy je poněkud mimo
- Mluvíte o jednotkách procent uživatelů, kteří si skutečně správně zkontrolují hash, v prohlížeči zkontrolují zapnutí CRL (mnohde je ještě nutný nastavit jeho adresu pro jednotlivý CA), a kteří nemají zasviněný PC běžným malwarem. Ano, tam SSL nepomůže, jenže v drtivý většině pomůže třeba jednorázovej kód (s výjimkama typu: http://www.root.cz/clanky/bezpecnostni-stripky-socialni-site-v-centru-pozornosti-hackeru/nazory/318466/ ), a ten (v jakýkoliv podobě) jste třeba vůbec nezmínil jako dost slušný bezpečnostní řešení, kryjící jako pomocnej způsob další desítky procent hacků (když se dobře naimplementuje a je samozřejmě zcela mimo PC kanál, a zároveň i tento kanál je dobře ošetřen - SMS 3DES, včetně jeho změny...).
A nakonec: Kdo SSL/TLS srovnával s IP adresou? Nikdo, nikde.

Jsou totiž protiústavní.

Nechápu vaši snahu, kdy je možnost posílit bezpečnost, se tomu bránit,

To vidím, že nechápete, co se tady celou dobu snažím vysvětlit. Kontrola IP adresy není posílení bezpečnosti. Nebo je, ale zhruba stejně účinné, jako zakopat pod server kořen madragory a do CD-ROM mechaniky nacpat česnek.

Změna IP adresy co půl minuty na některých místních sítích vám nepřipadá jako čuňárna, no, mně, a některým implementátorům webových služeb a serverů, ano.

Není to v rozporu s žádnými internetovými standardy, takže není vaší úlohou posuzovat, zda to má některý správce takto nastavené správně nebo ne – je to jeho věc a vy s tím musíte počítat.

Ohledně autentizace odkážu jen na rozdíl autentizace a autorizace, dál určitě netřeba.

Netřeba, celou dobu se tady bavíme o autentizaci, webový prohlížeč s údaji o uživateli ani nikdy nic jiného nedělá – autorizaci dělá až serverová strana.

Co se týče SSL/TLS…

HTTPS stále jako prostředek k zabezpečení integrity spojení a nemožnosti odposlechu stačí, i proti naposledy oběvené slabině se lze bránit. SSL není spása, pokud si uživatel nainstaluje pochybný plugin nebo má na počítači keylogger, SSL jej nezachrání. Ale proti útokům MITM je to silná ochrana (pokud si uživatel zkontroluje certifikát a prohlížeč kontroluje CRL), srovnávat to s kontrolou IP adresy je poněkud mimo – když bych měl zabezpečení ohodnotit na stupnici od nuly do sta, bude mít SSL třeba nějakých 85 a kontrola IP adresy 0,0001.

Celou dobu tu píšu, že se jedná jen o "pomocné, přídavné..." zabezpečení autentizace,

To je přesně ono – řeší se pomocné a přídavné zabezpečení, které nezabezpečí skoro nic, a na skutečné zabezpečení se pak kašle – vždyť je tam přece hromada těch pomocných a přídavných, tak to musí stačit. DS by měly být zabezpečené víc, než jenom proti script kiddies, a zabezpečení proti schopným útočníkům samozřejmě zabere i proti těm script kiddies.

Nechápu vaši snahu, kdy je možnost posílit bezpečnost, se tomu bránit, protože "to je zbytečný", a uživateli to může přinést v případě nezakomponování do aplikace trochu nepohodlí. Tak buď jsou DS běžnej systém kluka/holky, co vyrobil/a místní chat (kde je přesto na místě z těchto pomocných způsobů zabezpečení některý použít, jestli se tedy nechce, aby to byl jeden velkej backdoor s používáním nicků kohokoliv kýmkoliv, a z toho totální chaoz, kdy by se to stejně chtě nechtě muselo předělat, nebo to zrušit), a nebo obrovsky důležitej systém, stejně tak jako např. příští rok základní registry. Tam je to úplně stejně neprůhledný, a může se stát, že to bude ještě otřesnější implementace. A vám to vůbec nevadí, evidentně.

Navázanost na IP adresu jsme už u DS odmítli, z důvodu především nutný co nejglobálnější funkčnosti. Změna IP adresy co půl minuty na některých místních sítích vám nepřipadá jako čuňárna, no, mně, a některým implementátorům webových služeb a serverů, ano. Ale budiž, každej se dle toho jistě zařídí dle svých priorit, jako čuňárna to zůstává (opakuju - v rámci relace, že se změní po běžné době vyřízení relace je již bezvýznamná věc, a ať si vytížené servery mají navenek klidně desítky IP adres).

Ohledně autentizace odkážu jen na rozdíl autentizace a autorizace, dál určitě netřeba.

Co se týče SSL/TLS, opět zapomínáte na to, jak to u DS začalo, a taky na to, jak to je v globálu aktuálně někde jinde. Kdyby bylo SSL zcela bez chyb, včetně implementace, pak ano. Bez chyb není, běžný hashe za chvíli přestanou stačit, dokonce se nekontrolují při instalaci certifikátů, CRL je kontrolováno v prohlížečích mnohdy mimo defaultní nastavení, v prohlížečích jsou chyby, jsou defaultně zapnuté volby pravěkého SSL 2.0, implementace má mnohde trhliny i na serverech, to všechno má za důsledek buď možné nabourání nebo obcházení SSL relací (malware, man-in-middle...), a vy mi tu budete tvrdit, že SSL/TLS je spása.

Celou dobu tu píšu, že se jedná jen o "pomocné, přídavné..." zabezpečení autentizace, kde je to teoreticky úplně to samé, jako si u wifiny zapnout maskování SSID a filtr MAC adres. Ano, samo o sobě je to k ničemu, ale jako přídavnej střípek do skládačky, zvlášť pro lamy, objíždějící s notebooky se script kiddies vilový čtvrtě, proč ne.
Dál je samozřejmě třeba řešit právě autorizaci, ale to už je poněkud jinej příběh, že.

Předvádíte klasickou ukázku amatérského pojetí bezpečnosti. Nejprve se vymyslí způsob autentizace, kdy se uživatel autentizuje jen na začátku práce a následně se mu už důvěřuje na základě toho, že se jedná o stejnou session – přičemž identifikaci session může v případě HTTP ukrást kdokoli po cestě, v případě HTTPS „pouze“ něco uvnitř prohlížeče. A pak se snažíte takto vytvořenou díru zalátat, přičemž se vůbec nehledí na to, jaké mají ony záplaty vliv na bezpečnost – hlavně to musí vypadat dostatečně sofistikovaně. A pokud to nefunguje, svede se to na neschopnost někoho jiného – třeba adminů koncového uživatele.

Žádné RFC ani nic podobného nevyžaduje, aby všechna HTTP spojení v rámci jedné session pocházela z jedné IP adresy – vyžadovat to ani nemůže, protože HTTP je bezestavový protokol, a session si vytváří až server tím, že některé požadavky podle určitých pravidel poskládá k sobě. Takže pokud někde vzniká problém s tím, že se odchozí IP adresy mění, není to neschopnost admina klientské sítě, ale neschopnost tvůrce aplikace. Proxy může (ale nemusí) posílat originální IP adresu, která je ale tvůrci aplikace k ničemu, protože ji stejně tak může podvrhnout útočník.

Změna session ID ničemu nepomůže, už jsem to psal. Za prvé tím znemožníte používat historii prohlížeče nebo otevřít aplikaci vícekrát (a nepřinese to nic), za druhé tím stejně nezabráníte únosu session – útočník ji může unést pořád stejně, akorát následující požadavek oprávněného uživatele bude vyhodnocen jako útok a uživatel bude odhlášen. Může se pak pokoušet účet okamžitě zablokovat, ale to už je jenom souboj, zda bude rychlejší útočník nebo běžný uživatel – a útočník bude pravděpodobně připraven a bude systém dobře znát.

Pořád ještě jste nevysvětlil, k čemu je dobrá kontrola IP adresy. Jak zabrání únosu session, pokud je útočník za stejným proxy serverem nebo za stejným NATem? Já myslím, že nijak. Takže musíte mít stejně nějaké jiné opatření, které tomuhle zabrání. Jenže to bude fungovat i pro všechny ostatní případy, takže kontrola IP adresy je pak zbytečná.

Kontrola IP adresy jako prevence únosu session může mít smysl jedině v případě, kdy web není zabezpečen vůbec nijak – pak kontrola IP adresy zamezí alespoň takovým útokům, kdy by se k session ID dostal někdo víceméně náhodně. Proti cílenému útoku na daného uživatele ale nepomůže nijak.

Když se používá HTTPS spojení, je kontrola IP adresy úplně zbytečná – jediný rozumný způsob, jak session ID získat, je z prohlížeče uživatele. A když má útočník pod kontrolou prohlížeč uživatele, může samozřejmě provádět akce z jeho IP adresy.

Ano průser jak Brno. Jen asi bude ještě dlouho trvat než bude první kauza. A pak...? Všechny konverze do listiné podoby půjdou do kytek.

U DS jsem psal, že kontrola IP adresy je z důvodu neschopných adminů nepoužitelná. A ohledně session id vás opravdu lituju, že vám nebude fungovat Back v prohlížeči, nebo dokonce historie suburl DS, strašlivá to killer feature, zvlášť když se uvedený dá zařídit v rámci aplikace.

Jestli je něco killer feature, tak je to autorizovaná konverze s certifikátem v CRL, případně dokumentu s porušenou integritou. Dokonce to není killer feature, ale totální průser jako Brno.

Možná se té změny session id a detekce změny IP adresy nakonec dočkáte. Zní to totiž jako super killer feature, jak otrávit uživateli přístup do DS. Při detekci změny IP adresy by se mohlo šáhnout k blokaci přístupu do DS z daných IP adres a směle to vydávat za další výrazné posílení bezpečnosti dat.

Pak by byl rozdíl zcela zanedbatelný, a to byste měl samozřejmě pravdu :-) Vzhledem k tomu, co všechno už u DS vyplavalo na povrch jsem se tomu ani nedivil, a zmíněná možnost mě napadla až když jste to zmínil :-)

Ani jedno zbytečné není, pokud se jedná o bezpečnostní hledisko.

Nedělat kontrolu IP adresy u DS bych pochopil, bohužel i z toho důvodu, že teoreticky by proxy měla posílat i mohla posílat původní IP, ale to bychom už byli u adminů v rámci sci-fi procentuálního pokrytí.

Jinak i ty nejprimitivnější programovací jazyky pro web umožňují řešit změnu session id v rámci oné funkce. Že to třeba php nemá jako defaultní hodnotu je hodný kritiky, ale dle mě se to v budoucnu změní.

Čemu nerozumíte na "změna session id při každém načtení stránky"?

Já tomu rozumím – když je nějaký web udělaný blbě, musí se to zmršit pořádně, třeba změnou session ID při každé změně stránky a zneplatněním předchozích. Když předchozí session ID nezneplatníte, nijak jste si proti ukradení session nepomohl, když je zneplatníte, znemožníte používat historii prohlížeče nebo otevřít aplikaci ve více záložkách. A přitom je to vše zbytečné…

Změna IP adresy během relace ve skutečnosti nastává jen v málu sítí, a pokud je to rychlejší než řekněme 30 minut, tak to je jenom prasárna, a s rozložením zátěže nebo s rozumným nastavením clusteru/proxy serveru to nemá nic společnýho.

Typický argument někoho, kdo potřebuje nějak obhájit kontrolu IP adresy. Mně úplně stačí to, že kontrola IP adresy může způsobit problém, a bezpečnost rozumně zabezpečeného systému to nezvýší.

Já jsem to pochopil tak, že autor pracoval v prohlížeči na počítači, a ten počítač byl k internetu chvíli připojen přes jedno připojení a chvíli přes jiné. V tomto případě o tom věděl, pokud na síti funguje vyvažování zátěže nebo záložní konektivita, děje se úplně to samé, ale bez vědomí uživatele. Session je dělána buď pomocí cookie nebo pomocí parametru v URL, a ani jedno není svázáno s odchozí IP adresou (kterou ostatně prohlížeč často ani neví).

Čemu nerozumíte na "změna session id při každém načtení stránky"?

Změna IP adresy během relace ve skutečnosti nastává jen v málu sítí, a pokud je to rychlejší než řekněme 30 minut, tak to je jenom prasárna, a s rozložením zátěže nebo s rozumným nastavením clusteru/proxy serveru to nemá nic společnýho.
A navíc jsou weby/služby, který vůbec nejsou postavený na návštěvnosti, a kde maj holt uživatelé, co mají nad sebou idioty adminy, smůlu. Buď ať si stěžujou u nich, na hlavním nádraží, a nebo ať tam nechoděj, neubude.

Autor šel do DS přes kabelový internet a následně přes mobil, tudíž to co tvrdí by muselo být tak, že tam žádné session ani cookies nepoužívají.

To, co je popsáno v komentáři, může být v pořádku – pokud uživatel pořád z prohlížeče pracoval s DS a pouze se mu změnila IP adresa, není to žádný bezpečnostní incident. V tomto případě o změně IP adresy autor věděl, stejně tak ale mohl dostat novou IP adresu od DHCP… Problém by to byl, pokud by se otevřenou session podařilo získat někomu jinému. Což podle jiných informací udělat lze*), ale nebyl to zrovna tento případ.

*) Ono to musí jít, protože na možnosti ukradení session je současný web datových schránek postaven – ukrást session prohlížeče potřebuje 602XMLFiller. Kdyby byl každý požadavek autentizován přístupovými údaji, session ukrást nejde, jenže pak by uživatel musel údaje zadávat dvakrát – jednou do prohlížeče, podruhé do 602XLFilleru. Takže právě onen plugin je důvod, proč musí být kradení session v DS povoleno – ale jak je vidět z informací popsaných v článku, i to lze obrátit zcela naruby a vydávat to za posílení bezpečnosti.

Otázka je spíš opačně – kdo IP určitě v průběhu session nezmění. A to jsou jenom domácí uživatelé někde na ADSL. Firmy, velké školní sítě, mobilní internet – tam všude jdete na web většinou přes nějaký proxy server, který může mít víc odchozích IP adres (třeba kvůli rozkládání zátěže), pokud jdete na přímo a máte veřejnou IP adresu, máte ji zpravidla přidělenou DHCP serverem a za pár minut můžete dostat jinou.

Stejně musíte počítat i s možností únosu session i IP adresy. Takže musíte udělat opatření i pro takový případ – třeba SSL a přihlášení klientským certifikátem (pro každé spojení), nebo aspoň SSL a HTTP autentizace (také pro každé spojení). Pak máte autentizovaný každý HTTP požadavek, a únos session vás netrápí. Jenže k čemu je pak dobré ještě hlídat IP adresu, když její změna stejně nemusí znamenat žádný problém, takže to může být jedině měkká kontrola (kterou pak ale může potvrdit jak oprávněný uživatel, tak útočník)?

To je vůbec úžasná móda to přihlašování k webům přes webové formuláře, když přitom existuje HTTP autentizace (dokonce i ve variantě digest, takže ani přes nezabezpečené spojení nejde heslo v otevřeném tvaru). Pak se složitě řeší krádeže session nebo skryté přihlášení odkazem z jiného webu… Jistě, proč to dělat jednoduše, když to jde i složitě.

Pokud váš web uživatele při změně IP adresy automaticky odhlásí, pak s nimi samozřejmě problém nemáte – protože váš web nepoužívají.

Cože? Kontrola IP není žádné zabezpečení, jen buzerace? Jaká buzerace, kdo mění IP v průběhu session? Kontrola IP je i u většiny webmailů a hazardéři si jí můžou vypnout. Souhlasím že můžu unést session i s IP adresou, ale aspoň tím zabráním tomu, aby někdo snadno hackoval nechráněné připojení někoho, kdo zrovna brouzdá v DS. Přiznám se, že já s uživateli, kteří by měnili svou vlastní IP adresu v průběhu jedné relace, problémy nemám. Pokud se k vám hlásí na web přes TOR, tak je možné, že máte odlišné zkušenosti.

Lajosi, děkuji za pěkný rozbor. Ačkoli úředníci jsou mí nepřátelé a vyhýbám se jim (jsem OSVČ, mám své zkušenosti), v tomto vás upřímně a bez postranních úmyslů lituji. Nechtěl bych nyní pracovat ve státní správě a celý den znuděně kroužit myší po monitoru, protože čekám až naběhne zaseklá aplikace datové schránky.

Také jsem zvědavý, kdy se dostanou datové schránky před Ústavní soud. Doufám, že brzy.

Bohužel tu miliardu do státního rozpočtu už asi pan Langer nevrátí...

Kontrolou samotné IP adresy jistě ne, ale pak tu máme session s jejich možnou automatickou obměnou po každém načtení stránky, cookies navázané striktně na SSL...
To, co autor popsal, je hnus fialovej, a pokud by to tak skutečně bylo, nemá to se zabezpečením nic společnýho, leda s parodií, a taky s neskutečnym amatérismem. Ostatně, to vidíme od začátku tohoto seriálu, některý vyjádření "bezpečnostních expertů" by se daly tesat do kamene (nebo z nich zvracet).

Ano, platí, ale v případě fyzické osoby máte možnost ve smyslu § 41 správního řádu požádat o prominutí zmeškání lhůty (to u DS nelze). takže pokud jste na dovolené, najdete ve schránce výzvu s poučením a pokud jste aktivní, není problém vám lhůtu prominout - jako úředník dělám běžně.

No za sebe jakožto úředníka - uživatele ISDS z donucení. Jsem právník, nemám problém s počítačem, osobně se domnívám, že hlupák nejsem. Moje hodnocení je takové, že to, co se dříve dělalo "postaru" - vytisknout rozhodnutí, orazítkovat, podepsat, vytisknout adresu na obálku, vložit, zalepit ... zabralo 2 minuty, nyní se slavnými datovými schránkami trvá minut 15. Především proto, že spisová služba v podmínkách velkého úřadu se výrazně zkomplikovala, (časem se to snad uživatelsky zlepší), samozřejmě lze časem úkony, které se musí odklikat zrychlit :), ale má to své limity. Většinu času však zabere hledání majitele datové schránky - je to právnická osoba, má ičo, vím co hledám, jak se jmenuje, psát umím (viz k tomu vtipy o úřednících) a zadám a čekám, čekám, čekám.... (tedy hlavně má asistentka, na toto jsem opravdu pro úřad drahý). Produktivita šla v tomto případě docela dolů, úspory nevidím - stejně to někdo platí, ne všichni účastníci mají datové schránky, takže něco se tiskne a posílá postaru, něco se autorizovaně konvertuje (další ztráta času navíc). Holt se bude privatizovat Česká pošta a potřebuje být bohatou nevěstou:(. Aby státní správa nezkolabovala, postupují úřady tak, že co se musí posílat pomocí DS - písemnosti určené ven (účastníci řízení) se posílají DS, meziúřední pošta chodí postaru (vzájemně se telefonicky ujištujeme, že vodu šlapou všechny úřady, a pokud by striktně dodržovaly povinnost užívat DS, tak se chod státu zhroutí.
Samozřejmě chápu, že obecná obliba úředníků v rámci společnosti není velká, ale opravdu toto není pokrok, ale řízená destrukce už tak zmršené veřejné správy. A to se můžeme těšit na krok č. 2 - základní registry veřejné správy, elektronické občanské průkazy, které se mají spouštět dle zákona od 1. 7. 2010 a hotovo není vůbec nic. Co jsem se účastnil připomínkových řízení, výsledek byl takový, že stát nevybere daně a nevyplatí důchody - což je poslední stádium před anarchií. Připomínky byly vyřízeny prostě - resorty nepochopily, kraje nepochopily, obce nepochopily. Náměstek Zajíček rozvrtá stát a uteče od toho jak malý kluk. Už se těším, jak zavede Ds na ministerstvu spravedlnosti.
Toto jsou technické problémy, které se časem vyladí, jako právník se spíš těším, až se v plné nahotě ukážou legislativní mezery ohledně písemností doručovaných DS - to je však na jiné fórum a delší diskusi.

Jestli si pošta myslí, že přes ně budu posílat elektronický fa někde za 20,- kus, tak na to můžou zapomenout: nebudu.

Vůbec nechápu jako mohl někdo po 10 rutinního fungování stovek systémů IB, mailů, web-mailů a všeho možného vymyslet takovýhle proprietární paskvil, kde jen pro přihlášení se musí člověk 4x trefovat než se mu podaří se vloupat do vlastní schránky.

Bohužel i samotný výstup z DS je pořádným krokem zpět. 1 státní úřad nám takhle začal posílat objednávky: z DS se pracně vytáhne zpráva, což je několikastránkový pdf s nesmyslnými (většinou z papírové podoby) údaji a nesmyslnými hlavičkami, ze které se pracně extrahují ty 1-2 strány, o které se jedná. To, co pomocí mailu zabralo 1 minutu, vyžaduje nově jen na naší straně čtvrthodinu + řádově několikahodinová nebo několikadenní prodleva než se s tím vůbec začne pracovat.
Škoda, že tady není zavedená Šaríja, na veřejné potrestání těch ..., co to vymysleli a realizovali, bych si rád zašel.

Za posílání tzv. komerčních zpráv budou chtít spoustu peněz. Tak to nebudu používat, nenechám lumpy vydělávat, v životě jsem neposlal fakturu jinak, než obyčejnou poštou za desetikačku, občas i obyčejným mailem, a nikdy se nestalo, že bych s tím měl problém. Ani při komunikaci s berňákem, sociálkou či jinými ouředními Ouřady. Upozorňování na SMS zpoplatnili, už jsem to zrušil, nenechám lumpy vydělávat, notifikace na mail mi stačí.

Nevíte, z čeho vyplývá praxe, že při změně zápisu do OR je jednateli datová schránka zrušena a vytvořena nová, s jiným identifikátorem?

Doufám, že ne. BTW, jedna z posledních odstávek testovacího prostředí byla odůvodněna přípravou dalšího testovacího prostředí.

Bohuzel vsak 10tidenni fikce doruceni plati i na papirove zasilky....takze jen zrusenim DS tomu stejne neuniknete.

Kontrola IP adresy není žádné zabezpečení, je to pouze buzerace uživatele. Takže do datových schránek by se to vlastně hodilo... Je to ale k ničemu, protože jednak nikde nemáte zaručeno, že se IP adresa uživatele v průběhu práce nemění, za druhé je možné spojení uživatele unést i s tou IP adresou, takže kontrolou IP adresy únosu spojení nezabráníte.

Děkuji, to jsem přehlédl. Vycházel jsem z nějakého článku, kde se psalo, že po aktivaci už nelze datovou schránku zrušit. Ale asi se to týká jen právnických osob.

Uz jednou jsem zazil co to je "neohlasena" zmena testovaciho prostredi DS a to 1.7. 2009. Proto verim autorovi, že si ho klidne 1.1.2010 vypnou a bude vse v naprostem poradku.

Jen pro informaci, 1.7.2009 mi prisly udaje do testovaciho prostredi a po pul dni zase jine udaje. Kdyz jsem se zacal dotazovat, co se jako deje a proc ruzna testovaci prostredi, tak me bylo sdeleno proste proto a pouzivejte prostredi XYZ.

Proto si dovedu predstavit, ze 1.1.2010 proste prostredi nebude a na dotaz, kde je, bude odpoved neni a sbohem.

Uznate sami, ze je radost pro DS neco vyvijet.

Tohle je mimo můj obor, ale není to normální, že se u některých připojení (dřív to byli AOL dialupisti a nevím, jestli to přetrvává u současných připojení) mění v průběhu session IP adresa? Takže drtivé většině uživatelů sice zvýšíte bezpečnost vůči únosu session, ale menší části znemožníte používat službu.
U triviálních chatů to jistě nevadí, ale jinde bych si tím nebyl tak jist. A rád se nechám poučit.

fikce doručení platí i bez DS. Vítejte mezi nevolníky.

Mám čerstvou zkušenost - a to hroznou. Zkoušel jsem kamarádovi aktivovat datovou schránku, připojili jsme notebook na internet od UPC, připojili se přes internet na datovou schránku, vyťukali šílené ID a heslo, změnili heslo, překonali nové děsné zabezpečení v podobě čtených čísel a ...
Vypadl kabelový internet. No co se dá dělat, kamarád vytáhl mobil a připojil se pomalu přes mobil. A v aplikaci datových schránek POKRAČOVAL bez jakéhokoliv problému!!!! Sodoma, Gomora, tohle jsem fakt nečekal. Že nemají ani nejzákladnější zebezpečení proti únosu komunikace je pro mne šokující zjištění. Tohle píšu když programuji i triviální chat a pokládám to za základní zabezpečení, že se kontroluje IP adresa. Obdivuji a oceňuji že někdo dokázal získat 900 milionů Kč za takovouto práci. Klobouk dolu!

co takhle VPN nebo at ti doma nekdo zapne pocitac s logmein
hm?

Mělo by to jít, viz http://www.datoveschranky.info/fyzicka-osoba/ a tento odstavec:

"Ministerstvo znepřístupní datovou schránku fyzické osoby rovněž na žádost osoby, jíž byla datová schránka zřízena, nebo administrátora, jde-li o datovou schránku, kterou ministerstvo zřizuje na žádost."

Slyšel jsem, že datovou schránku nelze po zřízení už zrušit, je to pravda?

Bohužel jsem udělal nebetyčnou hloupost, že jako FO (NEpodnikatel) jsem si schránku dobrovolně zřídil v bláhovém domnění, že budu moct při pobytech v zahraničí komunikovat s úřady (což pan Langer sliboval). Ale teď toho lituji. V zahraničí nebo mimo vlastní PC nelze se schránkou pracovat.

Chystám se na nějakou dobu do ciziny a při pomyšlení, že mi mezitím přijde dopis z úřadu a já si ho nepřečtu (ale "přijmu" podle 10tidenní fikce doručení) mě jímá mráz po zádech, co všechno se může během mé nepřítomnosti stát.

Všiml jsem si třeba, že při zapomenutí hesla musí člověk osobně na CzechPoint. Nevím, kde budu v Anglii hledat CzechPoint :-(

Jsem trochu v háji :-(

Pro uživatele musí být veškerý provoz zadarmo. Dodavatelská firma přece už za to dostala zaplaceno několik miliard Kč. Takže má předplaceno na 200 let dopředu.

Bezpečnosní expert RS ? Proč tohle pouští před novináře (možná proto, že novináři bezpečnosti nerozumí). Ty citace by se na odborných fórech dali předhazovat jako titulky Večerníku Praha, protože mají úroveň pouťového plátku. Filler zabezpečuje internet ! Bezpečnost zvýšíme předáním dat uživatelům do jejich aplikací ! Touringův test až po přihlášení ! Přihlášení certifikátem je bezpečnější než jméno a heslo ! S fillerem na věčné časy a nikdy jinak.

Nicméně oceňuji stoický klid autora článku, že se udržel ve věcné a nektritické rovině, ať si názor udělá každý sám.