Hlavní navigace

Třetina českých e-shopů má bezpečnostní problémy

Sdílet

Vláďa Smitka 29. 1. 2020
Notebook bezpečnost zámek

Ve spolupráci s nástrojem Marketing Miner se pro Datablog konference Reshoper provádějí různé průzkumy české e-commerce, především z marketingového pohledu. V rámci těchto aktivit proběhl koncem prosince i jednoduchý bezpečnostní scan více než 35 tisíc českých e-shopů. Výzkum se zabýval nastavením HTTPS, používáním bezpečnostních HTTP hlaviček a zapomenutými nástroji a soubory, které by rozhodně neměly být veřejně přístupné. V rámci scanu došlo i k velmi základnímu otestování ošetření uživatelských vstupů.

Problémy byly nalezeny na třetině e-shopů a na desetině byly tyto problémy kritické.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 29. 1. 2020 16:14

    Row

    Jenom vloni se mi minimalne 3x stalo, ze pri registraci na eshop, jsem sve v registraci pouzite heslo dostal obratem "pro jistotu" emailem. Pokud se pak o tom pokousim bavit s podporou, jsem tak akorat ujisten ze "bezpecnost dat svych zakazniku neberou na lehkou vahu".... ale jeste se mi nestalo ze by to nekdo zmenil. :-/
    Kdyz navic uvazim jak prebujely trh s eshopy u nas mame tak se divim, ze problemy u nas ma "jen" tretina eshopu.

  • 29. 1. 2020 17:19

    Filip Jirsák

    To je ale problém webových standardů a prohlížečů. Když váš prohlížeč klidně vaše heslo předá serveru, neměl byste se divit, že server to heslo zná (a třeba vám ho pošle e-mailem). Mně nijak neuklidňuje, když mi e-shop heslo e-mailem nepošle – protože to nic nemění na tom, že to heslo může znát. Připomíná mi to malé děti, které si myslí, že když někoho nevidí, nemůže ani on vidět je – a schovávají se tak, že si zakryjou oči. Podobně se chovají (poučenější) uživatelé: „Já nechci vidět, že znáte mé heslo. Dělejte si s mým heslem, co chcete, jenom mi nedávejte najevo, že ho znáte.“ Zjevně to spoustě lidí k pocitu bezpečí stačí…

  • 29. 1. 2020 18:00

    Row

    Ja jsem take nic nepsal o tom, ze bych byl klidny diky tomu ze 100 jinych eshopu mi ho tim mailem neposle.
    Tim ze mi ale kdokoliv posle uzivetelske jmeno a heslo pohromade, potazmo nezabezecenym kanalem, ilustruje jak jeho postoj k bezpecnosti uzivatelskych dat (at jiz z neznalosti nebo ignorance), tak i to ze si pristup k heslum v citelne podobe apriory nejakym zpusobem zajistuje cilene. Pak uz muzeme akorat polemizovat o tom, jestli je heslo ulozene v DB rovnou v plaintextu, jen zahashovane a nebo zda mi ho poslal pred zadnym zasifrovanim, ale to nic nemeni na tom, ze bez ohledu na standardy to ukazuje ze ten pristup je uz od zacatku blbe a je bohuzel velice casty.
    Stoprocentne bezpecne neni nic, ani chodit pesky po ulici, ale to neznamena prece ze nazdarbuh poleze kazdej do silnice bez rozmyslu protoze umrit muze tak jako tak a tudiz je to jedno.
    Kdyz mi kdysi prisel mail z tusim X-zone ze je jim to lito, ale ze navzdory "vysokemu zabezpeceni sifrou MD5" jim byla ukradena a desiforvana hesla k uctum uzivatelu, nevedel jsem jestli se smat nebo brecet.

    29. 1. 2020, 18:02 editováno autorem komentáře

  • 30. 1. 2020 16:13

    Filip Jirsák

    Jistěže se můžeme bavit o tom, jestli to, že nám někdo nepošle heslo e-mailem, je nějakou zárukou toho, že není heslo uložené v DB. A zda to, že není uložené v DB, je zárukou toho, že není uložené třeba v logu. To ale nic nemění na tom, že na škále nebezpečnosti je zasílání hesla z prohlížeče za 100 bodů, a zasílání hesla e-mailem za 1 bod, ukládání hesla v DB v otevřeném tvaru za 1 bod, ukládání hesla v DB se slabým hashem za 1 bod – a pak se vedou velké diskuse o tom, který z těch jednobodových prohřešků je 1,1 a který je 0,5. Ale těch 100 bodů nikdo neřeší.

    Stoprocentně bezpečné opravdu není nic, ale to nikdo nechtěl. Akorát mi připadá nesmyslné dohadovat se, zda je větší problém škrábanec v laku nebo okno ušpiněné od mušek, když to auto nemá motor, má jen tři kola a chybí mu volant.

    Opakovaně se ukazuje, že provozovatelé webů nejsou schopni hesla zabezpečit. To, že to po nich opakovaně chceme, místo aby to řešil prohlížeč, to je opravdu k pláči.

  • 30. 1. 2020 16:29

    turista

    Správná by byla autentizace asymetrickou kruptografií. Jako u SSH (kde je public klíč v authorized_hosts). Ale SSH používají profesionálové a jsou schopní to pochopit. Laik chápe sotva to jméno a heslo.

  • 30. 1. 2020 19:35

    Vít Šesták

    Bylo by fajn mít nějakou autentizaci, která nevyžaduje, abych posílal serveru heslo. Tady se shodneme. Problém je, že by byla potřeba kooperace tří stakeholderů:

    1. Prohlížeče. Pokud to prohlížeč nepodporuje, není moc o čem se bavit. Dnes mají prohlížeče podporu klientských certifikátů, ale jak moc je to user friendly? Kolik lidí zvládne ten certifikát přenést mezi počítačem a telefonem? A kolik lidí to udělá bezpečně, aby nešel nikým zneužít?

    2. Webové stránky. Nebude-li podpora odtud, není sebelepší systém kde použít.

    3. Uživatelé. Největší a nejrůznorodější skupina. Podle mého nevědeckého průzkumu tu vidím nejvíce problémů, které jsou i důvody, proč dnes nepoužívají správce hesel. Vytvoření jediného místa, kde lze zaútočit a získat všechno. Obava, že se člověk nebude schopen přihlásit na jiném stroji. Otázka, jak sdílet s nějakým strojem jen část přístupů – například na pracovním stroji budu chtít si koupit jízdenku ze svého účtu, ale nebudu chtít tam dát přístup ke svému IB. Rozhodně netvrdím, že vždy jde o racionální obavy (zvlášť vzhledem ke zvolené alternativě), ale jsou tu a nebude snadné to vyřešit.

    Když řešení prakticky selže u jedné ze skupin, nepřinese to (skoro) žádný užitek, protože to (skoro) nebude používáno.

    Proti tomu zde máme správce hesel (a vygenerovaná unikátní silná hesla). Neříkám, že jde o dokonalé řešení. Má proti třeba certifikátům své nevýhody. Třeba když útočník získá dump DB ze serveru, kde ukládají hesla v plaintextu, může se na mě na tom jednom serveru přihlásit – ale všude jinde má smůlu, což je za mě hlavní. (V případě plného ovládnutí serveru mi o moc víc nepomůže ani asymetrická kryptografie.) Proti teoreticky lepším řešením založeným nejspíše na asymetrické kryptografii tu ale jsou významné výhody. Projdeme si jednotlivé stakeholdery:

    1. Prohlížeče – samy mají typicky vestavěný správce hesel, plus lze různé správce doinstalovat.
    2. Webové stránky – nepotřebují speciální podporu, stačí nevymýšlet příliš kreativní řešení jako třeba input type="text" nastylovaný jako heslo. Jako má RegioJet. I tak ale na drtivé většině stránek to funguje.
    3. Uživatelé – tady to částečně drhne a zdaleka ne všichni je používají. Ale asi jde o řešení poněkud uchopitelnější než asymetrická kryptografie, takže čekám, že i přijatelnější. Když chci přidat přístup na jiný počítač, prostě přepíšu heslo. Dokonalé to není, uchopitelné ano.

  • 31. 1. 2020 8:58

    Filip Jirsák

    Klíčové jsou prohlížeče.

    Velká část uživatelů bude používat to, co jim poskytne prohlížeč. Obavu, že se nepřihlásí na jiném stroji, podle mne velká část uživatelů neřeší. Z těch, kteří to řeší, jich zase velká část zná synchronizaci hesel přes uživatelský profil v cloudu. Navíc kdyby prohlížeče zacházely s hesly příčetně, ta obava by byla neopodstatněná – uživateli by stačilo jediné heslo.

    Problém s externími správci hesel je v tom, že jsou do prohlížečů dohackované. A všechny správce hesel jsou dohackované do webových stránek – vždy jen hádají, kam se asi má heslo předvyplnit, co je asi vytvoření nového hesla, co asi změna hesla. Navíc spoustu bezpečnostních problémů přináší to, že se hesla vyplňují do webové stránky, heslem je chráněný jediný požadavek a pak už vše závisí na nějaké podobě session identifikátoru.

    Rozumná implementace by byla taková, že je autentizován každý požadavek, citlivé údaje (heslo) uživatel zadává jen do prohlížeče (nebo jeho rozšíření, ale prostřednictvím nativního UI, ne přes webovou stránku) a z prohlížeče se řídí přihlášení, odhlášení, vytvoření hesla, změna hesla. Bylo by fajn, kdyby k tomu prohlížeče poskytovaly API, aby ta implementace „správce hesel“ nemusela být jen integrovaná v prohlížeči, ale aby si uživatel mohl zvolit vlastní správce hesel.

    Webové stránky bude snadné donutit k používání jiného systému – stejně, jako už dlouho prohlížeče varují, že se heslo odesílá přes nezabezpečené spojení, mohou varovat před tím, že se heslo zadává do webového formuláře.

  • 31. 1. 2020 18:23

    Vít Šesták

    > Obavu, že se nepřihlásí na jiném stroji, podle mne velká část uživatelů neřeší. Z těch, kteří to řeší, jich zase velká část zná synchronizaci hesel přes uživatelský profil v cloudu.

    To by mi možná znělo uvěřitelně, kdybych podobné protiargumenty neslýchával tak často, jako slýchávám. Na druhou stranu musím uznat, že nemám asi reprezentativní vzorek celé populace. Řekl bych, že toto není překážka pro dvě skupiny lidí:

    1. Lidé orientovaní na bezpečnost. S nějakým přenosem (např. synchronizací) si poradí a z cizích strojů se zásadně nepřihlašují. Pokud synchronizují, dost možná použijí řešení, které hesla šifruje a poskytovatel k nim nemá přístup. Když náhodou budou chtít se přihlásit třeba na nákup jízdenky na cizím stroji, heslo třeba opíší z telefonu.
    2. Lidé, kteří bezpečnost moc neřeší, ale jde jim o pohodlí. Taky používají jen pár strojů a odjinud se nepřihlašují. Nejspíš nemá tušení, zda provozovatel cloudové služby má přístup k jeho uloženým heslům, nebo jestli jsou zašifrovaná hlavním heslem.

    Je tu ale spousta lidí, kteří vidí různé (byť třeba domělé) překážky, například:

    * Člověk zvyklý se přihlašovat kdekam ze školních počítačů.
    * Člověk, který se z nějakého důvodu nepřihlašuje ze smartphonu.
    * Člověk, který sice nemá důvod se přihlašovat z cizích strojů a má možnost použít svůj smartphone, ale má zvyky z doby, kdy tomu tak nebylo. Mám pocit, že do této kategorie patří dost odmítačů správců hesel.
    * Člověk, který nechce posílat hesla do cloudu. (Ano, lze to šifrovat, ale tuto obavu reálně slýchávám. Ne každá obava je racionální.)
    * Člověk, který nechce dávat všechna hesla do jednoho místa, protože mu to přijde moc riskantní. (Celkem by mě zajímalo, kolik z těchto lidí bude používat jedno univerzální heslo. Ne každý postoj je vždy racionální.)

    Není to vědecky zpracované, ale ani vycucané z prstu. Zakládám to na tom, co si vzpomínám, že mi lidi říkají jako důvody proti správcům hesel. Jak těmto lidem chcete „prodat“ řešení postavené na asymetrické kryptografii?

    > Problém s externími správci hesel je v tom, že jsou do prohlížečů dohackované.

    Existují i API pro správce hesel. Má to Android, má to iOS. Ve WebExtensions jsem to neviděl, ale i tak mi přijde mnohem realističtější to se přidat než razit novou metodu autentizace.

    > A všechny správce hesel jsou dohackované do webových stránek – vždy jen hádají, kam se asi má heslo předvyplnit, co je asi vytvoření nového hesla, co asi změna hesla.

    Ano. V praxi to ale funguje IMHO mnohem lépe než hypotetické dnes publikované řešení za pět let. Není to hezké, ale je to realita.

    > Navíc spoustu bezpečnostních problémů přináší to, že se hesla vyplňují do webové stránky, heslem je chráněný jediný požadavek a pak už vše závisí na nějaké podobě session identifikátoru.

    Jistě tu je určitý prostor něco pokazit v případě třeba generování tokenu, museli bychom to ale srovnávat s jinou variantou, která by nejspíš část potenciálních chyb vyřešila a část vytvořila.

    > Webové stránky bude snadné donutit k používání jiného systému – stejně, jako už dlouho prohlížeče varují, že se heslo odesílá přes nezabezpečené spojení, mohou varovat před tím, že se heslo zadává do webového formuláře.

    Prohlížeče mohou varovat před lecčím. Mohly by varovat i při použití TLS 1.2, protože je zastaralé. Pokud ale varování bude na každé druhé stránce, lidé to přestanou vnímat. A podobně pokud varování nebude vypadat jako dostatečná hrozba. Myslím, že není náhoda, že zmíněné upozornění prohlížeče (byť není dokolané) přišlo teprve relativně nedávno v době masivního nasazení HTTPS a se snahou to omezit na případy, kdy by to uživatele nejspíš mohlo zajímat. Neříkám, že je HTTPS třeba na zpravodajském serveru bez přihlášení zbytečnost, ale při přihlašování ten psychologický efekt asi bude někde jinde…

    Neberte mě špatně. Taky bych rád používal technicky vyspělejší řešení. Jenže pokud jeho výhodám rozumí hrstka lidí a jeho úspěch stojí na masivním použití, prosadí se spíše méně vyspělé řešení, které je jednodušší nebo levnější nebo přišlo dříve.

  • 31. 1. 2020 20:53

    Filip Jirsák

    Jak těmto lidem chcete „prodat“ řešení postavené na asymetrické kryptografii?
    Já lidem nechci prodávat řešení postavené na asymetrické kryptografii. Já bych se spokojil i s řešením založeným na klasických heslech, kde by prohlížeč neposílal heslo v otevřeném tvaru ani jeho ekvivalent. Uživatel by tím pádem mohl docela bezpečně používat všude stejné heslo, pokud by bylo dost silné na to, aby odolalo útokům hrubou silou. Proti dnešku by to byl pořád obrovský pokrok. Samozřejmě by byla ideální varianta, že by web povinně musel implementovat více algoritmů a uživatel by si mohl vybrat, zda chce používat heslo nebo asymetrickou kryptografii, ale to by bylo řešení hodné roku 2020 – mně by prozatím stačilo, kdybychom měli alespoň řešení hodné roku 2000.

    O asymetrické kryptografii jsem psal jen proto, že jsem (marně) doufal, že si Scrappy Coco uvědomí, že server opravdu nemusí znát nic, co by bylo možné zneužít pro přihlášení.

    Existují i API pro správce hesel. Má to Android, má to iOS.
    Desktop má pořád ještě na webu docela silné zastoupení.

    V praxi to ale funguje IMHO mnohem lépe než hypotetické dnes publikované řešení za pět let.
    Nefunguje. Jaký je podíl uživatelů, kteří používají správce hesel, a navíc ho používají správně – tj. používají unikátní generovaná hesla? Ne, nebude fungovat nic založeného na tom, že se musí uživatel o bezpečnost aktivně starat a ještě si komplikovat život. Jediné reálné řešení je takové, že prohlížeče prostě postupně znemožní posílat hesla přes webové formuláře. Stejně jako postupně tlačí na HTTPS.

    Jistě tu je určitý prostor něco pokazit v případě třeba generování tokenu, museli bychom to ale srovnávat s jinou variantou, která by nejspíš část potenciálních chyb vyřešila a část vytvořila.
    Běžný přístup je, že se vytvoří identifikátor session, uloží se do cookie (v horším případě do URL) a posílá se s každým požadavkem. Některé weby ještě ani nemají implementován HttpOnly session cookie. Tím se jenom obchází to, že prohlížeče neimplementují pořádný způsob autentizace. A vytváří to zcela novou třídu problémů – únosy sezení nejsou možné, když je autentizován každý HTTP požadavek. Stejně tak je spousta útoků založena na tom, že uživatel heslo vyplňuje do webové stránky. V tomto případě má alternativní řešení opravdu podobný typ útoku – bylo by možné snažit se napodobit dialog prohlížeče pro zadání hesla. Jenže prohlížeč má mnohem víc možností, jak se tomu bránit, než webová stránka.

    Pokud ale varování bude na každé druhé stránce, lidé to přestanou vnímat. A podobně pokud varování nebude vypadat jako dostatečná hrozba.
    Nepřipadá mi, že by tlak prohlížečů na zavádění HTTPS byl neúčinný. Nebo tlak na to, aby se přestaly používat SHA-1 certifikáty nebo staré verze SSL a TLS. Zdá se, že autoři prohlížečů dobře zvládají to časování, kdy nejprve jen „straší“ provozovatele webů a skutečné varování zapnou až v případě, kdy se s ním uživatel reálně potká jen málo často.

    Myslím, že není náhoda, že zmíněné upozornění prohlížeče (byť není dokolané) přišlo teprve relativně nedávno v době masivního nasazení HTTPS a se snahou to omezit na případy, kdy by to uživatele nejspíš mohlo zajímat.
    Varování při odeslání formulářových dat přes HTTP měl už Internet Explorer 4.0. Mozilla mu tenkrát konkurovala mimo jiné tím, že tuhle hlášku odstranila. To varování přece hned nemusí být modální dialog, který bude muset uživatel potvrdit. Nejspíš by se zase začalo nějakou červenou ikonou buď u políčka pro heslo nebo v adresním řádku. Nebo by prostě stačilo v políčku pro heslo maskovat vstup – sice by to bylo plus z hlediska UX a bezpečnost by to nijak výrazně nesnížilo, ale ty správné uživatele by to nejspíš správně vyděsilo.

  • 1. 2. 2020 0:25

    Vít Šesták

    > Já bych se spokojil i s řešením založeným na klasických heslech, kde by prohlížeč neposílal heslo v otevřeném tvaru ani jeho ekvivalent. Uživatel by tím pádem mohl docela bezpečně používat všude stejné heslo, pokud by bylo dost silné na to, aby odolalo útokům hrubou silou.

    To v principu zní jako stateless password managery. Má to několik nedostatků řešitelných více či méně klasickými stateful password managery:

    * Jak zmiňujete, heslo musí být silné, aby odolalo bruteforce. Bez toho po leaku jednoho hesla na mě může kdokoliv udělat offline útok.
    * Nelze změnit heslo jen na jedné službě. Docela se to hodí po leaku.
    * Nelze sdílet jen část přístupů. Na firemním počítači může zaměstnanec chtít třeba GitHub (vývojář), LinkedIn (HR), dopravce nebo hudební službu. Přitom ale pochopitelně nechce všechny dát firemnímu počítači bšechny přístupy.

    > Existují i API pro správce hesel. Má to Android, má to iOS.
    > Desktop má pořád ještě na webu docela silné zastoupení.

    Ano, ta API dnes neřeší všechno. Ale ukazují, že nejde o principiální problém.

    > Nefunguje. Jaký je podíl uživatelů, kteří používají správce hesel, a navíc ho používají správně – tj. používají unikátní generovaná hesla?

    Statistiky nemám. Pro obojí ale bude cca stejná cílová skupina. Password manager dnes může použít kdo chce na skoro kterékoliv stránce, heuristikám navzdory. Pokud byste vytvořil nový protokol, na jeho reálné nasazení na podobném počtu webů si počkáte. Za pět let by to IMHO bylo stále dost omezené.

    > Některé weby ještě ani nemají implementován HttpOnly session cookie.

    Httponly je pěkný způsob, jak v případě XSS zabránit ukrad… Teda on si útočník může z oběti udělat proxy a stejně udělat, co potřebuje, až tak velké omezení to reálně není. Byť v rámci principu least privilege je dobré httponly zapnout, kde to jde.

    > Nepřipadá mi, že by tlak prohlížečů na zavádění HTTPS byl neúčinný.

    Ten tlak nezačal od píky. A zejména negativní motivace se začíná objevovat až v posledních letech, kdy si to prohlížeče mohou dovolit. To se netýká nového způsobu autentizace.

    > Nepřipadá mi, že by tlak prohlížečů na zavádění HTTPS byl neúčinný. Nebo tlak na to, aby se přestaly používat SHA-1 certifikáty nebo staré verze SSL a TLS

    Nepřipadá mi, že by se to tlačilo podobným způsobem ve chvíli, kdy to používala drtivá většina webů. Tady začínáte od píky.

    > Varování při odeslání formulářových dat přes HTTP měl už Internet Explorer 4.0.

    OK, ale to varování, které tak 99 % lidí odklikne bez rozmyslu asi nechcete dávat za vzor, že ne?

    > Nebo by prostě stačilo v políčku pro heslo maskovat vstup

    Jakože by se políčko pro heslo zobrazilo na webové stránce? Webová stránka má dnes možnsoti jak něco takového napodobit, pak by bezpečnost používání jednoho hesla šla do kytek…

  • 1. 2. 2020 10:06

    Filip Jirsák

    Správci hesel dnes existují a někteří lidé je používají. Přesto dochází k únikům hesel, ze kterých plyne, že uživatelé používají slabá hesla a používají stejná hesla, která server zná, na více webech. Já z toho vyvozuju, že možnost používat správce hesel k vyřešení problému nestačí. Vy z toho děláte jiný závěr?

    Já si z toho zároveň vyvozuju, že nebude fungovat nic, kde dáte lidem do ruky možnost používat něco jinak. Jediné reálné řešení je, že uživatelé budou dělat to, co dělají doteď – psát své jedno heslo do prohlížeče – akorát ta technologie pod tím musí být jiná. Už jenom když prohlížeč vezme uživatelem zadané heslo, přidá k němu základní doménu webu a uživatelské jméno, výsledek zahashuje a pošle serveru jako heslo, bude to mnohem bezpečnější, než dnes. Slabá hesla stejně pořád půjde lámat hrubou silou, ale budete to muset dělat po jednom uživateli na každém serveru. Ve srovnání se stavem, kdy máte heslo v otevřeném tvaru, je to pokrok o světelné roky.

    Dnes uživatelé mohou změnit heslo jen na jedné službě a mohou sdílet přístupy nebo část přístupů, takže když se to z jejich pohledu bude chovat stejně, tato možnost samozřejmě zůstane zachována.

    Mimochodem, sdílení přístupů sdílením hesla je jiný problém, i když daleko méně závažný než to, že neustále unikají hesla z prohlížečů. Zajímalo by mne, kdy třeba e-shopům dojde, že nenakupují jenom jednotlivci, ale i rodiny, firmy a další skupiny, takže by bylo vhodné mít k jednomu účtu více přístupových údajů.

    HttpOnly na cookies se používá proto, aby nebylo možné je číst z JavaScriptu. Protože u typického webu je těžké dohlédnout, kdo všechno má v rámci webu možnost JavaScriptem cookies číst, a session cookie obvykle v JavaScriptu číst nepotřebujete.

    Jak v případě HTTPS, verzí SSL/TLS nebo hashovacích algoritmů byl tlak prohlížečů zpočátku pozvolný a postupně se přitvrzuje, a trvá to roky. Nikde jsem nepsal, že by se hesla v otevřeném tvaru přestala používat za půl roku. Jenže o tom problému s hesly se ví řádově dvacet let, za tu dobu už opravdu mohlo být zasílání hesel v otevřeném tvaru vymýcené. Můžeme klidně čekat dalších dvacet let, zda se lidé nezmění a nezačnou používat správce hesel, ale na to vám mohu odpovědět rovnou – nezačnou. Ono se totiž nejspíš s hesly nebude dělat nic, a než naučit prohlížeče pracovat s hesly rozumně, to radši donutíme lidi používat FIDO nebo něco takového.

    Jakože by se políčko pro heslo zobrazilo na webové stránce?
    Ne. Byla by to součást nátlaku na tvůrce webů, aby přestali používat zadávání hesla ve webové stránce – prostě by se input[type='pas­sword'] začal zobrazovat úplně stejně, jako input[type='text'], tj. zadané heslo by nebylo maskované ale bylo by vidět. Zlepšilo by se UX, bezpečnost by se moc nesnížila a spousta lidí, kteří nepoužívají správce hesel z různých obskurních důvodů, by takové weby odmítla dál používat.

  • 1. 2. 2020 22:17

    Vít Šesták

    Já jsem netvrdil, že správci hesel tyto problémy již vyřešili. Já tvrdím, že je řeší, a že k praktickému vyřešení jsou blíže než nějaký váš abstraktní nápad, který zatím není ani přesně popsaný (nebo ano?), natož aby ho někdo začal implementovat nebo dokonce používat.

    Věřím, že postupem času se vyřeší různé věci, které by password managery mohly řešit lépe a zvýší se jejich použití. Nemám přesný scénář, ale je tu několik faktorů, které by tomu mohly pomoci:

    * Zlepšení integrace a UX nejen na telefonu, ale i na desktopu. Když to bude jednodušší použít, nechá se přesvědčit více lidí.
    * Mám (čistě subjektivně) pocit, že propagace password managerů z bezpečnostních důvodů je spíše záležitostí posledních let, dříve se od toho spíše odrazovalo. Proto si získávaj důvěru až teď.
    * Zlepšují se správci hesel integrovaní do prohlížečů. Můžeme se jejich možnostem smát, ale narovinu: Je to první volba pro spoustu uživatelů a pro masové rozšíření to může být klíčové.
    * Snad cokoliv, co dnes není ideální u správců hesel, lze v principu evolučně přidat. Lze například přidat API na přihlašování, odhlašování a změnu hesla. Některé stránky to mohou implementovat, a password manager tam bude lépe plnit svou roli. Některé stránky to neimplementují, tam bude password manager fungovat aspoň nějak.

    Všimněte si toho, že jde o čistě evoluční cestu, která se nesnaží najednou změnit. Bude to dlouhá cesta (a překážky vidím spíše v postupném přesvědčování uživatelů k jinému chování), ale vidím světlo na konci tunelu.

    Naproti tomu vy, pokud to dobře chápu, vidíte cestu v nějakém zákazu.

    > Jediné reálné řešení je, že uživatelé budou dělat to, co dělají doteď – psát své jedno heslo do prohlížeče – akorát ta technologie pod tím musí být jiná.

    Toto zhruba splňuje i password manager s hlavním heslem.

    > Už jenom když prohlížeč vezme uživatelem zadané heslo, přidá k němu základní doménu webu a uživatelské jméno, výsledek zahashuje a pošle serveru jako heslo, bude to mnohem bezpečnější, než dnes.

    No, muselo by se to ale implementovat, a to i na webových stránkách. Dokud bude fungovat i stará cesta, bude tu prostor pro downgrade attack a prakticky nulové zlepšení. Ti, kteří dnes ukládají hesla v plaintextu nebo hashují slabě, to nejspíš stejně neimplementují. Navíc se to bude těžko implementovat do stávajících webů, kde hashujete už podle jiného schématu. Neříkám, že je to nemožné, řeší to dvojí hashování, ale zvýšíte tím komplexitu, protože hashování původně prováděné na straně serveru musí nově provést prohlížeč, a server mohl používat bambilión různých schémat. Navíc zpětně kompatibilní řešení nejspíš povede k určitým únikům informací, protože prohlížeč bude potřebovat vědět, jak má hashovat (což může odhalit legacy hesla zahashovaá postaru), jakou má použít sůl, apod. Možná by i to šlo implementovat bezpečně, ale vidím tu spoustu nástrah, kvůli kterým se na to nejspíše vykašlou i ti, kteří bezpečnost řeší – právě z bezpečnostních důvodů, kvůli riziku implementační chyby.

    V neposlední řadě to může mít negativní vliv na bezpečnost kvůli falešnému pocitu bezpečí: Sám jste zmiňoval, že používat všude jedno heslo by s tím bylo OK. Stejného dojmu by mohli nabýt i různí lidé, kteří znají trochu principů. Jenže pak hesla leaknou z webu, který používá legacy způsob přihlášení, a v ničem si nepomůžete.

    > Slabá hesla stejně pořád půjde lámat hrubou silou, ale budete to muset dělat po jednom uživateli na každém serveru. Ve srovnání se stavem, kdy máte heslo v otevřeném tvaru, je to pokrok o světelné roky.

    Je to pokrok ve srovnání se stateful správci hesel je to krok zpět. Ano, v případě cloudové synchronizace můžete zkusit lámat hlavní heslo, ale stále je dost rozdíl mezi online a offline útokem. Online útok lze omezit třeba zvyšující se dobou přihlašování nebo pomocí CAPTCHA. Offline útok je omezen pouze výpočetní kapacitou útočníka.

    Navíc i online útok by byl jednodušší než u správců hesel s cloudovou synchronizací. Na online útok by stačilo vybrat si jeden server s nejslabší ochranou proti online útokům. Případně se opřít o více serverů.

    > budete to muset dělat po jednom uživateli na každém serveru

    Co si pod tím mám představit? Když na jednom serveru prolomím heslo uživatele, který všude používá stejné heslo, udělám to pro toho uživatele jednou a mám jeho heslo všude.

    Přijde mi, že chcete technologii, která něco řeší relativně dobře, zpětně kompatibilně a pomalu, ale jistě se dostává do používání a zpřístupňuje masám (password managery), nahradit něčím zatím neexistujícím, méně bezpečným a bez pořádného řešení zpětné kompatibility.

    Ad httponly – přijde mi to v této diskuzi okrajové téma, ale když už: Jsem pro použití httponly, kde to jde, ale nepřeceňoval bych význam. Když už uděláte XSS, můžete si z prohlížeče oběti udělat proxy a session cookie nepotřebujete. Nebo můžete zobrazit přihlašovací dialog, ani pozorný uživatel nemá moc šanci si všimnout, že je něco špatně, doména v adrese přece sedí…

  • 2. 2. 2020 11:51

    Filip Jirsák

    Vy se pořád věnujete jen technické stránce věci a úplně ignorujete lidi. Aby problém vyřešili správci hesel, musel byste ke změně zvyků přesvědčit několik miliard lidí. Aby to vyřešily prohlížeče, musíte přesvědčit několik stovek lidí, kteří mají reálně vliv na webové standardy a jejich implementaci. Takže k praktickému vyřešení mají správci hesel mnohem dál.

    Správci hesel se samozřejmě mohou evolučně zlepšit. Mohou se dokonce zlepšit tak, že nebude potřeba, aby uživatelé změnili své chování. Aby to celé vedlo k tomu, že uživatelé nebudou mít stejné heslo na více službách, které zároveň to heslo znají, musí se začít už u vytváření hesla. Nemůže to fungovat tak, že kdokoli bude po uživateli chtít, aby si zadal nové heslo. Ne, jediná možnost, kdy to bude fungovat, je ta, že někdo uživateli to heslo vytvoří. Aby to bylo spolehlivé a uživatelé to opravdu používali, nemůže to být implementované tak, že se správce hesel bude pokoušet uhodnout, která stránka zakládá nový účet. Naopak, musí to dát vědět ta stránka. To samé platí pro přihlášení heslem – správce hesel musí vědět, ne hádat, že se uživatel chce přihlásit, k jakému webu se chce přihlásit a musí vědět, jak má předat přihlašovací údaje. Takže musí vzniknout nějaké API, kterým spolu budou komunikovat správce hesel a webová stránka nebo webový server. No a když už takové API bude existovat, kdo říká, že přes něj musí putovat heslo, které uživatel zadal na klávesnici? I kdyby uživatel trval na tom, že si nenechá heslo vygenerovat správcem hesel, ale zadá si svoje, může přece prohlížeč tohle heslo zahashovat (spolu s dalšími údaji) a přes to API poslat až ten hash. Pokud to budou všechny prohlížeče dělat stejně, bude dál fungovat to, že uživatel kdekoli zadá svoje heslo a přihlásí se.

    Nebo-li vaše řešení se správci hesel nebude fungovat, pokud uživatel z nějakého důvodu správce hesel nechce používat. A aby fungovalo se správcem hesel, stejně vyžaduje vytvoření nějakého API. Přičemž když se to API jenom malinko dotáhne, bude to to mnou navrhované řešení, které bezpečnost zvýší všem, ať správce hesel používají nebo nepoužívají, a zároveň odstraní celé třídy problémů způsobené tím, že se dnes přihlašujeme přes webové formuláře.

    Naproti tomu vy, pokud to dobře chápu, vidíte cestu v nějakém zákazu
    Ne, vidím cestu v tom, že prohlížeče nabídnou novou metodu autentizace, a postupně budou tlačit na to, aby se přestala používat metoda založená na webových formulářích. Tak, jako postupně tlačí na používání HTTPS, aktuálních verzí TLS apod.

    Toto zhruba splňuje i password manager s hlavním heslem.
    Akorát to vyžaduje používání správce hesel, pokud uživatel používá více prohlížečů (např. v počítači a v mobilu), vyžaduje to synchronizaci hesel. Moje řešení dává uživateli volbu – funguje i se správcem hesel i bez něj.

    No, muselo by se to ale implementovat, a to i na webových stránkách.
    Ano, ale na to mají prohlížeče páky, jak víme z příkladů s HTTPS, verzemi TLS apod.

    Ti, kteří dnes ukládají hesla v plaintextu nebo hashují slabě, to nejspíš stejně neimplementují.
    Ale implementují, protože to, že by to neimplementovali, by bylo na první pohled vidět, prohlížeč by na to uživatele pokaždé upozornil. To, že někdo zachází špatně s hesly, není vidět do té doby, než ta hesla uniknou.

    Je to pokrok ve srovnání se stateful správci hesel je to krok zpět.
    Jenže to, že budou všichni používat stateful správce hesel, je jen vaše zbožné přání. Já neřeším, jaké jsou teoretické možnosti. Já píšu o tom, co se dá reálně dělat pro zvýšení bezpečnosti na webu.

    Co si pod tím mám představit? Když na jednom serveru prolomím heslo uživatele, který všude používá stejné heslo, udělám to pro toho uživatele jednou a mám jeho heslo všude.
    Dneska si to heslo uživatele jako provozovatel webu prostě přečtete ze své databáze. Kdybyste už od prohlížeče dostal jen hash login+heslo+doména, budete ta hesla muset louskat uživatele po uživateli (protože součástí hashe je i login, takže i dva uživatelé se stejným heslem na vašem serveru budou mít různé hashe).

    Přijde mi, že chcete technologii, která něco řeší relativně dobře, zpětně kompatibilně a pomalu, ale jistě se dostává do používání a zpřístupňuje masám (password managery), nahradit něčím zatím neexistujícím, méně bezpečným a bez pořádného řešení zpětné kompatibility.
    Já nechci správce hesel nahrazovat, v mém řešení fungují stejně dobře, jako dnes. Já jen nesdílím vaše přesvědčení, že do pár let budou správce hesel používat všichni uživatelé. Moje řešení je podstatně bezpečnější, než používání správců hesel bez samostatného API pro komunikaci mezi webem a správcem hesel. A zpětná kompatibilita je přesně to, co v tomto případě chceme porušit – pokud budou mít provozovatelé webů dál přístup k heslům uživatelů, kteří to samé heslo používají na spoustě jiných webů, není potřeba nic řešit, takhle to funguje i dneska. Takže to zrušení zpětné kompatibility, tedy odstranění hesel z databází provozovatelů webů, je cíl.

    Jsem pro použití httponly, kde to jde, ale nepřeceňoval bych význam. Když už uděláte XSS, můžete si z prohlížeče oběti udělat proxy a session cookie nepotřebujete. Nebo můžete zobrazit přihlašovací dialog, ani pozorný uživatel nemá moc šanci si všimnout, že je něco špatně, doména v adrese přece sedí…
    To záleží na tom, co vše si s tím XSS můžete dovolit. Každopádně „zabezpečení“ pomocí session cookie je velmi děravé a opět musí všichni autoři webů implementovat spoustu různých ochran jenom kvůli tomu, že prohlížeče neumožňují rozumně implementovat přihlášení jménem a heslem. Jednou z oblíbených ochran dříve bylo svázání session s konkrétní IP adresou…

  • 2. 2. 2020 13:47

    Vít Šesták

    > úplně ignorujete lidi. Aby problém vyřešili správci hesel, musel byste ke změně zvyků přesvědčit několik miliard lidí.

    Nemyslím si, že bych ignoroval lidi. Lidi postupně svoje návyky mění a mají tendenci si zjednodušovat život. Děje se to postupně a nemusí to být na první pohled patrné, ale děje se to. Například:

    * Ústup papírových diářů ve prospěch elektronických.
    * Podobně i jízdních řádů.
    * Ústup řetězových e-mailů ve prospěch Facebooku. (Super věc, že se člověk může lépe od těchto kravin izolovat.)
    * Nástup smartphonů a jejich využívání ke všemu možnému. (PM)
    * Nástup eshopů.
    * Nástup platebních karet, později nástup bezkontaktního placení, placení telefonem, placení hodinkama.
    * Ústup dobírky a nástup platby předem: https://www.novinky.cz/finance/clanek/dobirka-uz-neni-nejoblibenejsim-zpusobem-platby-za-zbozi-40031751
    * Vyšší důvěra v cloudové služby. (PM)
    * Dnes si lidé online účet nezřídka zakládají i kvůli operačnímu systému a prohlížeči. (PM)
    * Synchronizuje se dnes kdeco. (PM)
    * Lidi dnes tolik nependlují mezi různými cizími zařízeními, školními počítači a internetovými kavárnami, a spíše používají pár zařízení (telefon, přenosný počítač, pracovní počítač, …) (PM)

    Ne všechno z toho přímo souvisí s password managery, některé věci jsem uváděl jen pro doložení faktu, že lidé jsou schopni akceptovat změny, zvlášť když to přinese pohodlí. Ale nemálo z toho seznamu (vizte značku „PM“) vliv má. Někde to ještě potrvá, ale šanci tu vidím.

    Podstatným důvodem hrajícím do karet nástupu password managerů možná nebude bezpečnost, ale právě pohodlí. Při registraci je jednodušší ťuknout do tlačítka, které nabízí vygenerování hesla. Zvlášť když se pěkně nabídne. Při přihlášení je taky jednodušší heslo nepsat. S password managerem ostatně nemusíte typicky psát ani uživatelské jméno/e-mail, on vám to vyplní. Myslíte, že uživatelé budou ignorovat pohodlnější variantu, kterou jim budou prohlížeče a OS strkat čím dát tím víc pod nos?

    > Aby to vyřešily prohlížeče, musíte přesvědčit několik stovek lidí, kteří mají reálně vliv na webové standardy a jejich implementaci.

    To rozhodně nestačí. Těmi standardy se musí i někdo řídit. A to nejen prohlížeče, ale i autoři webů. I kdybyste jim sebral password fieldy, mají dnes kupu možností si je vytvořit pomocí HTML+CSS nebo HTML+JS (což by mimochodem poněkud zkomplikovalo password managery). A vzhledem k technické složitosti pro existující weby je prakticky jisté, že by to někdo udělal a nabídl knihovnu…

    > Nemůže to fungovat tak, že kdokoli bude po uživateli chtít, aby si zadal nové heslo. Ne, jediná možnost, kdy to bude fungovat, je ta, že někdo uživateli to heslo vytvoří.

    Tomu se už přiblužujeme… TODO

    > No a když už takové API bude existovat, kdo říká, že přes něj musí putovat heslo, které uživatel zadal na klávesnici?

    Pak máte stateless správce hesel, se všemi nevýhodami, které jsem zmiňoval.

    > Nebo-li vaše řešení se správci hesel nebude fungovat, pokud uživatel z nějakého důvodu správce hesel nechce používat

    Každé řešení může selhat na uživateli. Ve chvíli, kdy mizejí důvody, proč správce hesel nepoužívat, toto nevidím jako zásadní problém.

    > Dneska si to heslo uživatele jako provozovatel webu prostě přečtete ze své databáze.

    To předpokládá, že provozovatel ukládá hesla v plaintextu. Neříkám, že se tak nikdy neděje, ale po někom takovém těžko očekávat, že přejde na nový způsob přihlašování a že to implementuje správně. Ono to není až tak jednoduché udělat správně.

    A pokud jde o správce, kteří to udělají úmyslně, tady si taky nepomůžete. Jak jsem psal výše, s možností vyrobit si něco jako password field vlastními silami těžko zabráníte tomu, aby získal heslo v plaintextu.

    U provozovatelů, kteří hashují hesla správně a nemají zlé úmysly hesla na vydolovat, si nepomůžete. Naopak, přinesete nová rizika související třeba s komplikovanou změnou způsobu hashování. Vámi navrhované řešení je ve skutečnosti technicky složité, vezmeme-li v úvahu stávající databáze hashů hesel, jejich solí, změny v hashovacích funkcích a jejich parametrech. Tato složitost vede k riziku chyb.

    > Já nechci správce hesel nahrazovat, v mém řešení fungují stejně dobře, jako dnes.

    Vizte výše, vaše řešení přináší spíše komplikace než zvýšení bezpečnosti. Pravda, s password managerem by mohlo být bezpečnější, ale to už můžeme rovnou použít samotný password manager a nebudeme muset řešit různé side channely…

    > Moje řešení je podstatně bezpečnější, než používání správců hesel bez samostatného API pro komunikaci mezi webem a správcem hesel.

    O tom jste mě zrovna nepřesvědčil, vizte výše.

    > A zpětná kompatibilita je přesně to, co v tomto případě chceme porušit

    Máte řádově složitější problém než zaříznutí staré verze TLS nebo použití TLS pro formuláře. Autoři webů mají spoustu možností, jak to obejít, pokud jim neseberete CSS a JS. Co si myslíte, že se stane?

    a) Všichni autoři webů se začnou přizpůsobovat, řešit side channely apod. Začnou také řešit hashe hesel stávajících uživatelů, které z různých důvodů nejsou kompatibilní s novým schématem. Prostě udělají fúru práce, jen aby bezpečnost přihlašování na svém webu… v mnoha případech vlastně prakticky nezvýšili, protože již hashují a solí správně.
    b) Začne se to obcházet vlastní implementací password fieldů, což ztíží práci password managerů.

  • 2. 2. 2020 14:15

    Vít Šesták

    Zapomněl jsem místo „TODO“ hodit screenshot: https://photos.app.goo.gl/t1ic1MRfQHZStJxv5

    Myslím, že není problém si představit další iteraci, kdy to generování hesla bude mít ještě více v popředí a na psaní vlastního textu bude potřeba vynaložit větší úsilí…

    Jo, a nereagoval jsem na to XSS. V rámci XSS můžete dělat prakticky libovolné requesty na aktuální doménu, a pošlou se s tím všechny cookies., včetně těch httponly. Potom vidíte obsah, který můžete někam odeslat. Exfiltrace není problém, lze použít například websockets, CORS nebo různé workaroundy s kódováním dat do URL obrázku*. A nebo lze kompletně změnit obsah stránky a chtít třeba jméno a heslo, uživatel se ochotně znovu přihlásí, a heslo lze odelat útočníkovi. Těžko tomu bránit, protože útočník zde jen využívá toho, co legitimní stránka celkem běžně potřebuje. Takže httponly je fakt spíše takový drobek, který teda zapnu, když už to jde, ale nemám od něj prakticky žádná očekávání.

    A není mi jasné, jak to souvisí s tématem. Přihlašování lze řešit separátně od udržování přihlášeného stavu v nějaké session. Je to i žádoucí, třeba kvůli rate limits.

    *) Tyto workaroundy jsou dnes celkem zbytečné, spíše ukazují, že i kdybychom se zbavili CORS a websockets, nepomůžeme si, protože možnosti tu budou stále.

  • 2. 2. 2020 15:47

    Filip Jirsák

    V rámci XSS můžete dělat prakticky libovolné requesty na aktuální doménu, a pošlou se s tím všechny cookies., včetně těch httponly. Potom vidíte obsah, který můžete někam odeslat.
    Kde ten obsah vidíte? Vidíte ho na serveru, ovšem tam byste zase musel mít nějaký kód, který vám tu cookie (nebo třeba celý požadavek i s hlavičkami) pošle zpět do prohlížeče.

    A není mi jasné, jak to souvisí s tématem. Přihlašování lze řešit separátně od udržování přihlášeného stavu v nějaké session
    S tématem to souvisí tak, že při přihlašování přes webový formulář je pouze přihlašovací požadavek „chráněn“ heslem, všechny ostatní požadavky od téhož uživatele už si musí aplikace nějak chránit sama, resp. sama si je musí spárovat s daným uživatelem. K čemuž se často používají cookies. Když se používá autentizace na úrovni HTTP protokolu, je autentizován každý jednotlivý požadavek. Tím pádem odpadá celá třída bezpečnostních problémů – únosy session.

  • 2. 2. 2020 17:27

    Vít Šesták

    > Kde ten obsah vidíte? Vidíte ho na serveru, ovšem tam byste zase musel mít nějaký kód, který vám tu cookie (nebo třeba celý požadavek i s hlavičkami) pošle zpět do prohlížeče.

    Ale já jako útočník nepotřebuju tu cookie. Já potřebuju přečíst nějaká data nebo vykonat nějakou akci. To pomocí XMLHttpRequest nebo Fetch API udělat mohu.

    Ano, získat tu cookie by mohlo být o něco lepší, ale i toto může často stačit.

    A zobrazení přihlašovací obrazovky přímo na stránce serveru, kam útočím, může být taky dost účinné.

    Posílat něco odvozeného z hesla v každém požadavku a následně to ověřovat možné samozřejmě je. Řeší to session fixation, a to je asi tak vše. Neřeší to třeba CSRF (aspoň ne v podobě dnešní HTTP autentizace) a těžko se taky sleduje nové přihlášení. A taky to předpokládá, že se secret z prohlížeče dál hashuje maximálně nějakou rychlou funkcí – což nemusí nutně vždy vadit, ale je dobré s tím počítat.

  • 2. 2. 2020 21:50

    Filip Jirsák

    Ano, autentizace každého HTTP požadavku neřeší všechny problémy světa, ale řeší to problémy, které měly být vyřešeny už před dvaceti lety – a my s nimi zápasíme dodnes a řešení je v nedohlednu.

  • 3. 2. 2020 8:52

    Filip Jirsák

    Dodnes zápasíme s tím, že není autentizován každý požadavek, ale vše je závislé na session, často pomocí session cookie. Takže musíme řešit, aby neunikl identifikátor sezení, aby se stránkou nešlo manipulovat z jiného okna prohlížeče, aby sezení netrvalo věčně, když uživatel zavře okno prohlížeče. Ne že by to nijak řešit nešlo, ale řešíme zbytečné problémy a řešení samozřejmě nejsou dokonalá.

  • 8. 2. 2020 20:07

    Vít Šesták

    Jestli dobře rozumím, Vaše řešení je ekvivalentní tomu, že bychom místo náhodného session id, které po vypršení/odhlášení utrácí hodnotu, nahradili něčím, z čeho lze brutit heslo offline? To bychom mohli i dnes, jen nemám zrovna pocit, že to bude mít pozitivní vliv na bezpečnost.

    Naopak by to mělo různé jiné nepříjemné důsledky, například:

    * Vyšší praktická zneužitelnost útoků jako https://www.rc4nomore.com/ nebo POODLE.
    * Motivovalo by to ke slabému server-side hashování (zátěž CPU).

  • 9. 2. 2020 10:48

    Filip Jirsák

    Nikoli. Podívejte se třeba na HTTP Digest (primitivní řešení, ale po aktualizaci hashovacího algoritmu by to pořád bylo milionkrát bezpečnější, než posílat heslo v otevřeném tvaru). Pak existují komplikovanější metody, které ale mají proti Digestu další výhody – např. SCRAM. Při použití SCRAMu ani údaje uložené na serveru nestačí k úspěšnému přihlášení, nebo-li i pokud by ze serveru unikla databáze přihlašovacími údaji, nepůjde ji zneužít ani pro přihlášení přímo na ten server. Samozřejmě nepíšu o útoku hrubou silou – tam je jedinou systémovou obranou to, že útočník musí hádat každé jednotlivé heslo zvlášť, a dál už pomůže jenom silné heslo.

    Mimochodem, když píšete o tom offline bruteforce útoku, zase jste zapomněl na to, že dnes se heslo posílá v otevřeném tvaru. Nemyslím si, že byste našel ještě méně bezpečné řešení.

  • 2. 2. 2020 14:52

    Filip Jirsák

    Jenže k pohodlí je právě potřeba to API. Pokud password manažer nebude ve 40 % případů fungovat, protože se mu nepodaří uhodnout, co je na stránce, nebude to pohodlné.

    Tvůrci prohlížečů a webových standardů jsou ti rozhodující. Na provozovatele webů mají dostatečné páky – jak je vidět na příkladu HTTPS nebo verzí TLS. Jistěže se tomu někteří uživatelé i provozovatelé webů snaží vzepřít. Ale v souboji provozovatel webu × prohlížeč tahá provozovatel webu za podstatně kratší konec provazu. Ano, web může použít CSS a JavaScript – ale prohlížeč u spousty uživatelů zná heslo, protože je uložené v interním password manažeru. Takže je triviální detekovat, že uživatel někam napsal text, který je shodný s jeho heslem. A i kdyby automatická detekce nefungovala, prohlížeč pořád může mít blacklist, který bude ručně spravovaný.

    Tomu se už přiblužujeme…
    Nepřibližujeme. Dnes musí uživatel ručně otevřít kontextové menu políčka, tam vybrat vygenerování hesla; strachovat se, že si správce hesel rozumí se stránkou alespoň do té míry, aby pak to heslo šlo uložit; potvrdit správci hesel uložení hesla, ne úplně výjimečně ručně upravit záznam ve správci hesel a někdy ho dokonce ručně vytvořit. To dělají přesvědčení uživatelé správců hesel, ale běžný uživatel tohle nikdy dělat nebude. Nehledě na to, že často selže už první krok, generování hesla – protože heslo obsahuje pro daný web nepovolené znaky, je příliš dlouhé apod.

    Pak máte stateless správce hesel, se všemi nevýhodami, které jsem zmiňoval.
    Nikoli. Řešení, kdy se bude přihlašovat přes API a nebude se zasílat heslo v otevřeném tvaru, funguje se stateful správci hesel, stateless správci hesel i bez správců hesel.

    To předpokládá, že provozovatel ukládá hesla v plaintextu.
    Což musíte předpokládat u každého provozovatele, u kterého si nejste jist opakem. On je úplně zvrácený ten předpoklad, že ty statisíce nebo miliony provozovatelé webů po celém světe se chovají slušně. Vždyť víme, že se běžně prodávají e-mailové adresy i osobní údaje – proč bych si měl myslet, že s hesly je to jinak? Že zrovna k heslům se všichni chovají uctivě?

    Neříkám, že se tak nikdy neděje, ale po někom takovém těžko očekávat, že přejde na nový způsob přihlašování a že to implementuje správně. Ono to není až tak jednoduché udělat správně.
    Dříve bylo přihlašování implementováno přímo ve webovém serveru. To teprve s tím, jak se přešlo na přihlašování přes webové formuláře, začalo být nutné, aby si to každý naimplementoval znovu. Navíc to, co jste napsal, je argument pro moje řešení. Pokud není jednoduché implementovat správně přihlašování, pak samozřejmě do takové implementace nebudu strkat svoje heslo v otevřeném tvaru, ale poskytnu jí jenom hash. Pokud bude na implementaci něco špatně, přinejhorším se nepřihlásím – ale nemůže nastat to, že moje heslo unikne ven.

    A pokud jde o správce, kteří to udělají úmyslně, tady si taky nepomůžete. Jak jsem psal výše, s možností vyrobit si něco jako password field vlastními silami těžko zabráníte tomu, aby získal heslo v plaintextu.
    Pomůžu. Protože postupem času bude uživatelům divné, že mají heslo zadávat do webové stránky a ne do speciálního dialogu prohlížeče. Stejně jako dnes reagují na to, když web nemá „zelený zámeček“.

    U provozovatelů, kteří hashují hesla správně a nemají zlé úmysly hesla na vydolovat, si nepomůžete. Naopak, přinesete nová rizika související třeba s komplikovanou změnou způsobu hashování. Vámi navrhované řešení je ve skutečnosti technicky složité, vezmeme-li v úvahu stávající databáze hashů hesel, jejich solí, změny v hashovacích funkcích a jejich parametrech. Tato složitost vede k riziku chyb.
    Za prvé, vy to jako uživatel z venku nevíte, zda provozovatel webu správně hashuje. On může deklarovat, že to dělá, může být přesvědčen o tom, že to dělá správně, a stejně může mít někde chybu a třeba omylem logovat hesla v otevřeném tvaru do logu.

    V té nejjednodušší variantě, kdy by se z prohlížeče při přihlášení posílal stále stejný hash, by provozovatel nic měnit nemusel – prostě by jako heslo dostal hash zakódovaný třeba v BASE64 nebo jenom hexadecimálně, takže by to pro něj bylo, jako kdyby si uživatel zvolil dlouhé textové heslo. Jediný problém by byl při přechodu na tento nový systém přihlašování, kdy by si provozovatel musel nejprve vyžádat heslo v otevřeném tvaru, aby si na jeho základě mohl vypočítat hash. Ale to není žádný problém, pro většinu uživatelů by to provozovatel zvládl během běžného přihlašování, než by se přepnul na nové API.

    Vizte výše, vaše řešení přináší spíše komplikace než zvýšení bezpečnosti.
    Nikoli, nenapsal jste jedinou komplikaci, kterou by přinášelo moje řešení.

    Máte řádově složitější problém než zaříznutí staré verze TLS nebo použití TLS pro formuláře.
    Ne, ten problém je řádově jednodušší. Za prvé, je možné pořád dál používat formulářové přihlašování – jediné, co hrozí, je že v určitém okamžiku někdy v budoucnosti před tím bude prohlížeč varovat a případně ještě později se to bude snažit blokovat. Z vypnutí podpory starých verzí TLS je nějaký užitek teprve tehdy, když se podpora v prohlížečích reálně vypne – a pak web používající jen starou verzi TLS prostě přestane fungovat. Za druhé, implementace TLS je mnohem náročnější a jediné místo, kde to lze implementovat, je webový server. Přihlašování lze řešit buď přes HTTP API nebo v kombinaci s JavaScriptovým API (čistě JavaScriptové API by nebylo vhodné). Obojí mají v ruce vývojáři webových aplikací, tedy to mohou implementovat hned, bez ohledu na to, zda to jejich server podporuje či nepodporuje.

    řešit side channely
    Ty musí provozovatelé webů řešit teď. Pokud by za ně zodpovědnost za nakládání s heslem převzal prohlížeč, o tuhle starost přijdou.

    Začnou také řešit hashe hesel stávajících uživatelů, které z různých důvodů nejsou kompatibilní s novým schématem.
    Což dělají pokaždé, když přecházejí na nový hashovací algoritmus. Pokud to dělají opravdu správně, jak tvrdíte, už tenhle problém museli v minulosti řešit.

    v mnoha případech vlastně prakticky nezvýšili, protože již hashují a solí správně
    Jak je vidět i na vašem příkladu, v mnoha případech by tím bezpečnost prakticky zvýšili – protože by si nemysleli, že dělají všechno správně, když správně solí a hashují. Těch možností, co dělat špatně, je mnohem víc. Právě proto nemá heslo v otevřeném tvaru vůbec opustit chráněnou část prohlížeče.

    Začne se to obcházet vlastní implementací password fieldů, což ztíží práci password managerů.
    Kdo to myslí s bezpečností opravdu vážně, ten zajásá, že má konečně k ruce nástroj, se kterým tu bezpečnost opravdu může řešit. A ostatní – podívejte se, jak je dnes rozšířené HTTPS. Spousta lidí brblá, že pro jejich web to není potřeba, ale podíl HTTPS pořád roste. Takže někteří z ostatních by to implementovali rovnou, někteří by chvíli přesvědčovali uživatele, že ten červený vykřičník v políčku s heslem mají ignorovat, že je to zas nějaký výmysl prohlížečů, a pak by to stejně implementovali. A někteří by to zkoušeli obejít, ale prohlížeče a hlavně uživatelé by to odhalili – a ono by to pak přestalo bavit i tyhle provozovatele. Koneckonců, pokud by pak uživatelé věděli, že „zadávám heslo přímo do webové stránky heslo musím považovat za veřejné“, sami by se pídili po tom, jak na takovém webu použít heslo, jehož zveřejnění by jim nevadilo.

  • 2. 2. 2020 17:15

    Vít Šesták

    Možná je na čase tomu Vašemu řešení dát přesnější obrysy:

    * Co bude ta hashovací funkce? Půjde o jednu funkci, nebo bude konfigurovatelná?
    * Pokud bude konfigurovatelná, jak se bude konfigurovat?
    * Jak se bude řešit změna hashování?
    * Jak se bude řešit salt?
    * Jak se bude řešit pokus o přihlášení neexistujícího uživatele? Neleakne zde informace, že ten uživatel neexistuje?
    * Když se uživatel nějakou dobu nepřihlásil, a tedy nemohl přehashovat svoje heslo dle libosti, jak to utajíte, když se hashuje v prohlížeči?
    * Jak si to poradí s offline útoky na hashe ve srovnání se stateful password managerem?

    Už na toto může být problém odpovědět nějak konzistentně. Až na to odpovíte, můžeme se bavit třeba o side channels, které jsem měl namysli. Ale možná Vám to po sepsání bude jasné. Já jsem kdysi taky byl pro podobné schéma, ono to na první pohled vypadá dobře, ale jak přibývají detaily, člověk zjišťuje, jak komplexní problém to je.

    > Na provozovatele webů mají dostatečné páky

    Jak jsem psal, nemyslím si, že by zde tato analogie fungovala, a psal jsem proč. Pokud si to myslíte, zkuste napsat, jak takovéto páky vypadají. Představte si, že vámi navržené řešení dnes implementovaly prakticky všechny prohlížeče. Co se bude dít dál? Kdo bude co na existujících stránkách měnit a jakou k tomu bude mít motivaci? Kdy se projeví první benefity Vašeho řešení?

    Nechci odpověď „prohlížeče budou viditelně varovat uživatele“. Prohlížeče prakticky nemohou varovat před něčím, co dělá každý, protože to nikdo nebude brát vážně. Prohlížeče mohou varovat před něčím, co se děje vzácně. Což znamená, že prohlížeče touto cestou spíše pomohou v závěrečné fázi, ale do té doby to musí hnát jiné síly.

    > Jenže k pohodlí je právě potřeba to API. Pokud password manažer nebude ve 40 % případů fungovat, protože se mu nepodaří uhodnout, co je na stránce, nebude to pohodlné.

    Myslím, že těch 40 % je dost nadsazené číslo. Ale i kdyby, dovedu si představit postupné evoluční zlepšování. Bude motivací každého správce webu mít web kompatibilní s password managery, jinak přijdou o uživatele. Dopad tu je celkem jasný.

    > Nepřibližujeme. Dnes musí uživatel ručně otevřít kontextové menu políčka, tam vybrat vygenerování hesla;

    Není vždy pravda. Ukazoval jsem screenshot, kde rovnou po ťuknutí do políčka s heslem jsem dostal tlačísko na vygenerování hesla. A jde to posouvat ještě dál – tlačítko pro vygenerování bude to hlavní, abych napsal něco vlastního, musím něco rozkliknout.

    > > To předpokládá, že provozovatel ukládá hesla v plaintextu.
    > Což musíte předpokládat u každého provozovatele, u kterého si nejste jist opakem.

    Promiňte, ale toto je jednoznačně vytrženo z kontextu. Napsal jsem toto: „To předpokládá, že provozovatel ukládá hesla v plaintextu. Neříkám, že se tak nikdy neděje, ale po někom takovém těžko očekávat, že přejde na nový způsob přihlašování a že to implementuje správně. Ono to není až tak jednoduché udělat správně.“

    > Dříve bylo přihlašování implementováno přímo ve webovém serveru. To teprve s tím, jak se přešlo na přihlašování přes webové formuláře, začalo být nutné, aby si to každý naimplementoval znovu.

    No, v obou případech si to lze implementovat vlastními silami a v obou případech lze využít knihovny.

    > Navíc to, co jste napsal, je argument pro moje řešení. Pokud není jednoduché implementovat správně přihlašování, pak samozřejmě do takové implementace nebudu strkat svoje heslo v otevřeném tvaru, ale poskytnu jí jenom hash. Pokud bude na implementaci něco špatně, přinejhorším se nepřihlásím – ale nemůže nastat to, že moje heslo unikne ven

    Pokud je na implementaci něco špatně, je určitě správně tam nestrkat heslo, které by se dalo využít jinde. To řeší stateful password manager. Váš návrh to řeší částečně (hash odvozený z hesla je náchylný offline útokům), a přináší komplexitu. Mohou uniknout i další údaje, jako poslední přihlášení, nebo zda uživatel vůbec existuje. A i to může na některých webech být citlivý údaj. Je sice těžké některé údaje ochránit stoprocentně, ale to není důvod zavádět falší problémy. Pokud o tom mám diskutovat dál, poskytněte detailnější návrh, jak jsem zmiňoval na záčátku.

    > Protože postupem času bude uživatelům divné, že mají heslo zadávat do webové stránky a ne do speciálního dialogu prohlížeče.

    Možná. Někdy časem. Pokud se změní chování uživatelů, k čemuž jste sám byl skeptický. A hlavně to znamená, že reálný bezpečnostní benefit odsouváte někam do vzdálené budoucnosti, až totéž udělá spousta provozovatelů webů.

    > Nikoli, nenapsal jste jedinou komplikaci, kterou by přinášelo moje řešení.

    Vizte výše, dejte přesnější návrh, možná si těch komplikací všimnete i sám.

    > Za prvé, je možné pořád dál používat formulářové přihlašování – jediné, co hrozí, je že v určitém okamžiku někdy v budoucnosti před tím bude prohlížeč varovat a případně ještě později se to bude snažit blokovat.

    A teď si představte, že chcete u zaměstnavatele obhájit, že budete svůj čas věnovat podobné úpravě. Jak vysvětlíte benefity? Kdy přijdou? Někdy možná, až se prohlížeče rozhodnou brojit proti formulářům s hesly na webech?

    > > Začnou také řešit hashe hesel stávajících uživatelů, které z různých důvodů nejsou kompatibilní s novým schématem.
    > Což dělají pokaždé, když přecházejí na nový hashovací algoritmus. Pokud to dělají opravdu správně, jak tvrdíte, už tenhle problém museli v minulosti řešit.

    To ano, ale mají poněkud volnější ruce. Mohou počítat s tím, že dostanou heslo v plaintextu a mohou si to pořešit podle sebe. Tady se velmi reálně může stát, že jejich stávající mechanismus hashování nebude kompatibilní s Vaším návrhem, a tedy budou muset nechat nějakou dobu klasický formulář, jak píšete.

    > Kdo to myslí s bezpečností opravdu vážně, ten zajásá, že má konečně k ruce nástroj, se kterým tu bezpečnost opravdu může řešit.

    Už si představuju hovor zaměstnance, který chce tu změnu implementovat:

    A: Rád bych zde implementoval nový způsob přihlašování.
    B: Co to přinese a kolik to bude stát MD?
    A: Umožní to hashovat hesla přímo u zákazníka, takže to bude bezpečnější. U nás se budou ukládat hashovaná, takže kdyby se někdo dostal k databázi…
    B: A teď je nehashujeme?
    A: No, hashujeme, ale až na serveru.
    B: Takže když se někdo dostane k DB, stejně dostane jen zahashovaná hesla, ne?
    A: No ale někteří uživatelé zaměření na bezpečnost…
    B: Ti si to vyřešili password managerem. A konkurence nic podobného taky nedělá. Získáme tím tak 0.0001 % navíc, ta práce se nezaplatí.

    No, mnohem realističtější mi přijde, že někdo bude web dělat více friendly pro password manager, protože si někdo z analýz vyčetl, že registrační nebo přihlašovací stránka často bývá ta poslední, na kterou se uživatel podívá. Tady je ekonomický dopad zřejmý.

    > podívejte se, jak je dnes rozšířené HTTPS.

    U HTTPS jde o mnohem jednodušší problém s větším dopadem. To, že si někdo může hesla přečíst po cestě, zní mnohem hůře. Úprava stránky routerem taky. Náročnost řešení záleží. Někdy si to může vyžádat nový hosting nebo upravit absolutní URL, někdy (hlavně v počátcích) vyřešit 3rdparty skripty. To může být pořád nic proti řešení bezpečné implementace Vašeho návrhu.

  • 2. 2. 2020 22:49

    Filip Jirsák

    Možná je na čase tomu Vašemu řešení dát přesnější obrysy
    Prohlížeč zavolá webový server s požadovaným URL, které bude chráněné autentizací. Server odpoví kódem 401 Unauthorized a v hlavičce WWW-Authenticate pošle údaje nutné pro autentizaci – podporované protokoly, doménové jméno a výzvu. Prohlížeč získá login a heslo (z password manažera, od uživatele, jakkoli jinak) a pošle serveru spolu s požadavkem zvolený typ autentizace, login a podpis požadavku, přičemž podpis vznikne z údajů, které má uložené server, z výzvy a z klíčových údajů požadavku (metoda, URL, další kritické hlavičky). Údaje, které má uložené server, mohou být např. hash loginu, doménového jména a hesla, nebo to může být třeba náhodně vygenerovaný klíč, pokud uživatel používá stateful password manažer.

    Změna hashování se bude řešit podobně, jako změna hesla – prohlížeč pošle serveru nové údaje, které si má server uložit. Akorát změna hashování proběhne bez zásahu uživatele a jen v případě, že to bude změna na bezpečnější algoritmus.

    Sůl je uživatelské jméno, pepř je doménové jméno.

    Pokud o přihlášení neexistujícího uživatele bude probíhat stejně, jako dnes. Prohlížeč pošle login a přihlašovací údaje, server zjistí, že takového uživatele nezná, a odpoví jak uzná za vhodné – že uživatel neexistuje, že má uživatelské jméno chybný formát, nebo že uživatelské jméno neexistuje nebo je chybné heslo. Nebo jakkoli jinak, jak bude chtít.

    Když se uživatel nějakou dobu nepřihlásil, a tedy nemohl přehashovat svoje heslo dle libosti, jak to utajíte, když se hashuje v prohlížeči?
    Co bych měl tajit? Dokud se uživatel nepřihlásí a nemůžu heslo přehashovat, buď budu držet starou slabou variantu hashe a nebo hash vymažu a při příštím přihlášení bude uživatel muset heslo resetovat. Ony by se ty hashovací funkce zase neměly měnit každé dva měsíce, a pokud se někdo nepřihlásil tři roky, asi mu ten reset hesla nebude tak vadit. Spousta uživatelů ho stejně bude muset provést rovnou, protože si heslo stejně nebudou pamatovat.

    Jak si to poradí s offline útoky na hashe ve srovnání se stateful password managerem?
    Nic nebrání uživateli používat stateful password manager, takže srovnávat netřeba – když chcete, můžete použít obojí. Za to je ale potřeba offline útoky na hashe porovnávat s offline útoky na hesla v otevřeném tvaru. Protože to je současný stav a od něj se chceme posunout do bezpečnějšího stavu. A – přiznejme si to – hesla v otevřeném tvaru si v offline útocích nevedou moc dobře.

    Až na to odpovíte, můžeme se bavit třeba o side channels, které jsem měl namysli.
    Ano, můžeme se o tom bavit. Těším se na porovnání side channels s tím, že se heslo pošle v otevřeném tvaru. Jestli se vám podaří dokázat, že existuje ještě nebezpečnější způsob autentizace, než posílání hesla v otevřeném tvaru, bude kvůli vám muset být zavedena Nobelova cena za IT.

    Jak jsem psal, nemyslím si, že by zde tato analogie fungovala, a psal jsem proč. Pokud si to myslíte, zkuste napsat, jak takovéto páky vypadají. Představte si, že vámi navržené řešení dnes implementovaly prakticky všechny prohlížeče. Co se bude dít dál? Kdo bude co na existujících stránkách měnit a jakou k tomu bude mít motivaci? Kdy se projeví první benefity Vašeho řešení?
    Měnit to v prvním kole budou všichni, kdo dnes deklarují, že hesla ukládají bezpečně. Protože to bude důkaz místo slibů. Další v pořadí to udělají ti, kteří dnes ukládají hesla bezpečně, ale nemluví o tom – protože jim na bezpečnosti záleží, nebo se bojí úniku hesel, a v obou případech získají zlepšení oproti současnému stavu. A jako bonus budou mít ten důkaz místo slibů.

    No, a to pro prvotní rozšíření bohatě stačí. Benefity se projeví hned, jakmile to nasadí první web – protože budeme mít jistotu, že ten web zachází s hesly bezpečně a hesla z něj nemohou uniknout.

    Nechci odpověď „prohlížeče budou viditelně varovat uživatele“. Prohlížeče prakticky nemohou varovat před něčím, co dělá každý, protože to nikdo nebude brát vážně.
    Vy jste byl posledních patnáct let mimo naši sluneční soustavu? Nebo si vážně nepamatujete, jak se prosazovalo a prosazuje HTTPS? Nejprve to chtěl, kdo chtěl a zaplatil si certifikát, pak se postupně začalo mluvit o tom, že by tom měl mít aspoň každý, kde se posílají hesla nebo jiné citlivé údaje, pak přišel Let's Encrypt, který dramaticky snížil náklady, dnes už některé funkce prohlížečů jsou dostupné jen přes HTTPS, prohlížeče klidně zobrazují červený zámeček nebo dokonce uživatele na stránku vůbec nepustí, a už se řeší označován HTTP webů jako nezabezpečené. Tak mi netvrďte, že to nejde.

    To řeší stateful password manager.
    Neřeší, protože drtivá většina uživatelů password manažer s generováním hesel nepoužívá. Přičemž jakékoli bezpečnostní řešení, které závisí na tom, že uživatel dobrovolně dělá pro bezpečnost něco navíc, je špatné. Aby to opravdu pomáhalo bezpečnosti, uživatel nesmí mít možnost chovat se nebezpečně, nebo to pro něj alespoň musí být značně komplikované.

    A hlavně to znamená, že reálný bezpečnostní benefit odsouváte někam do vzdálené budoucnosti, až totéž udělá spousta provozovatelů webů.
    Pořád je ta budoucnost mnohem blíž, než budoucnost, kdy spousta uživatelů dobrovolně používá správce hesel.

    tedy budou muset nechat nějakou dobu klasický formulář
    Vzhledem k tomu, že ten webový formulář používají už o dvacet let déle, než by bylo vhodné, další tři pět let už je nezabije. Vždyť nejde o zhoršení stavu, jde jen o prodloužení dnešního nevyhovujícího stavu. Mimochodem, vaše řešení s password managery tohle řešení přes webové formuláře prodlužuje donekonečna – tak která varianta je horší?

    Už si představuju hovor zaměstnance, který chce tu změnu implementovat
    U toho by snad měl být někdo, kdo bezpečnosti aspoň trochu rozumí, ne? Ten váš rozhovor je nerealistický – reálně by to v téhle situaci bylo: „Nehashujeme, máme je bezpečně uložená v databázi a do databáze se nikdo nedostane.“

    No, mnohem realističtější mi přijde, že někdo bude web dělat více friendly pro password manage
    Já bych to upřesnil. Někdo se bude snažit udělat web password manager friendly. Ale zjistí, že se každý password manager chová jinak, a že to nejde udělat tak, aby vyhověl všem. Protože k tomu by bylo potřeba API, aby se web s password manažerem dohodly, ne aby web hádal, co asi chce password manager, a password manager hádal, co asi chce web.

    protože si někdo z analýz vyčetl, že registrační nebo přihlašovací stránka často bývá ta poslední, na kterou se uživatel podívá
    Takovou analýzu, ze které plynulo to, že je to dané nevlídností k password managerům, bych fakt rád viděl.

    To předpokládá, že máte správce hesel
    Pro odhalení webu, který podvádí, stačí velmi málo uživatelů. I kdyby vhodné podmínky byly splněné u 0,1 ‰ uživatelů, pořád to je pro autory prohlížeče dost a dost materiálu.

    U HTTPS jde o mnohem jednodušší problém s větším dopadem.
    Nikoli, je to nesrovnatelně komplexnější problém, který se dotýká většího množství subjektů.

    To, že si někdo může hesla přečíst po cestě, zní mnohem hůře.
    To je právě ten problém, že se místo skutečné bezpečností řeší to, co jak nebezpečně „zní“. Každý si představí útočníka, který může po cestě odposlechnout údaje. Ale provozovatel webového serveru je vždy ten hodný, ten uživatelské údaje nikdy nemůže zneužít…

    Blacklist není zrovna pěkné řešení…
    Je to jen dočasné řešení, než se ty podvádějící weby podaří úplně vymýtit. Vzhledem k tomu, že se whitelist používá třeba pro HSTS preload, kde je to dočasně trvalé řešení, bych ošklivost blacklistu vůbec neřešil. Ostatně podobné blacklisty se používají třeba pro detekci webů napadených malwarem.

  • 8. 2. 2020 19:58

    Vít Šesták

    > Server odpoví kódem 401 Unauthorized a v hlavičce WWW-Authenticate pošle údaje nutné pro autentizaci – podporované protokoly, doménové jméno a výzvu. Prohlížeč získá login a heslo (z password manažera, od uživatele, jakkoli jinak) a pošle serveru spolu s požadavkem zvolený typ autentizace, login a podpis požadavku, přičemž podpis vznikne z údajů, které má uložené server, z výzvy a z klíčových údajů požadavku (metoda, URL, další kritické hlavičky).

    OK, s tímto se už pracuje lépe. Ale ještě to není úplně rozvedené. Řekněme, že mezi možnosti bude patřit bcrypt a scrypt s různými parametry. Někdy vznikne potřeba přehashovat všechny uživatele. Zřejmě tedy bude existovat mechanismus, který umožní přihlašovat různé uživatele s různými hashovacími funkcemi nebo jejich parametry. Z Vašeho popisu mi není jasné, jak tento mechanismus bude vypadat. A toto právě je jedna z těch věcí, která není až tak jednoduchá – zkuste to navrhnout tak, aby z toho nešlo poznat dlouho nepřihlašovaného uživatele ani existujícího/ne­existujícího uživatele. Možná přijdete s nějakým geniálním a prakticky použitelným řešením, možná uznáte, že toto není až taková sranda.

    > Sůl je uživatelské jméno, pepř je doménové jméno

    Nedoporučuje se mít veřejně dostupnou sůl. Útočník si pak může pro konkrétního významného uživatele předpřipravit rainbow table. Pokud útok vzbudí pozornost (třeba nějaký monitoring anomálií provozu), má útočník větší šanci heslo zneužít ještě před reakcí.

    > Nic nebrání uživateli používat stateful password manager, takže srovnávat netřeba – když chcete, můžete použít obojí. Za to je ale potřeba offline útoky na hashe porovnávat s offline útoky na hesla v otevřeném tvaru. Protože to je současný stav a od něj se chceme posunout do bezpečnějšího stavu. A – přiznejme si to – hesla v otevřeném tvaru si v offline útocích nevedou moc dobře.

    Obojí srovnání má smysl. Můžeme srovnávat všechny čtyři varianty (kombinace).

    > Pořád je ta budoucnost mnohem blíž, než budoucnost, kdy spousta uživatelů dobrovolně používá správce hesel.

    Problém je v tom, dlouho ty benefity nejsou naprosto žádné. Až časem by teoreticky mohly být, pokud budou lidé dostatečně uvědomělí. K čemuž jsem skeptický.

    Oproti tomu password managery přinášejí pozvolné zlepšování bez nutnosti spolupráce velké skupiny lidí. Tu někdo vylepší password manager, tu někdo vydá článek o password managerech, tu někdo třeba upraví registrační formulář. Benefity každého kroku mohou být sice relativně malé, ale zde skoro každý malý krok dává smysl, aniž by se spoléhal na nejistou spolupráci mnoha dalších stran. To je hlavní důvod, proč password managery vidím v reálném světě jako vítěze nad oběmi nastíněnými alternativami (asymetrická kryptografie a Vaše nové schéma pro HTTP Auth), nezávisle na tom, co je lepší. Teda vlastně asymetrická kryptografie by možná mohla být přirozenou evolucí password managerů (ze kterých by se staly access managery).

    > vaše řešení s password managery tohle řešení přes webové formuláře prodlužuje donekonečna – tak která varianta je horší?

    Čemu to vadí při používání password manageru?

    > Někdo se bude snažit udělat web password manager friendly. Ale zjistí, že se každý password manager chová jinak, a že to nejde udělat tak, aby vyhověl všem. Protože k tomu by bylo potřeba API, aby se web s password manažerem dohodly, ne aby web hádal, co asi chce password manager, a password manager hádal, co asi chce web.

    Myslíte něco jako https://developer.apple.com/documentation/security/password_autofill/enabling_password_autofill_on_an_html_input_element ?

    > Takovou analýzu, ze které plynulo to, že je to dané nevlídností k password managerům, bych fakt rád viděl.

    Spousta webů používá například Google Analytics, které umožní mimo jiné najít místa, kde uživatelé opouští web. Bude-li to registrační formulář, dává to prostor k zamyšlení. Pravda, stále tu může být více důvodů. Ale přijde mi realističtější, že lidé budou brát zpětnou vazbu odtud (s motivací vlastního zisku), než že uvědomělí vývojáři přesvědčí uvědomělý management, že je potřeba věnovat úsilí postupnému přechodu na nový autentizační mechanismus pro blaho lidstva, bez přímé vazby na zisk firmy.

    > U toho by snad měl být někdo, kdo bezpečnosti aspoň trochu rozumí, ne?

    Záleží, kdo s kým má takový rozhovor. Šéf obvykle má nějaký přehled, případně si něco nechá vysvětlit. Pointa nicméně byla, že si nedovedu představit, jak přesvědčuju šéfa nebbo kolegu, že něco takového je potřeba udělat a že stojí za to tomu věnovat čas. Vy si to dovedete představit?

    > Pro odhalení webu, který podvádí, stačí velmi málo uživatelů. I kdyby vhodné podmínky byly splněné u 0,1 ‰ uživatelů, pořád to je pro autory prohlížeče dost a dost materiálu.

    To záleží. Jednak to neřeší cílené útoky, jednak je to http://www.lamer.cz/quote/50132 .

    > Měnit to v prvním kole budou všichni, kdo dnes deklarují, že hesla ukládají bezpečně. Protože to bude důkaz místo slibů.

    OK, kolik jich bude? Řékl bych, že pár. Co pak dál? Varování na plain HTTP se taky neobjevilo ihned poté, co to zavedlo pár webů.

    > Nebo si vážně nepamatujete, jak se prosazovalo a prosazuje HTTPS?

    Pamatuju. Jen si nemyslím, že ten postup lze úplně znovupoužít zde. Třeba omezování funkčnosti webů se dělá těžko, když většinu funkcí může stejně dobře chtít i stránka, která nikde žádné přihlašování nemá.

    > Benefity se projeví hned, jakmile to nasadí první web – protože budeme mít jistotu, že ten web zachází s hesly bezpečně a hesla z něj nemohou uniknout.

    No. Dnes jsou možnosti něco podobného implementovat v JS. Benefity i nevýhody by byly zhruba podobné. Proč se to tedy neprosadilo již dnes? A proč si myslíte, že řešení vyžadující dostatečně nový prohlížeč dopadne lépe?

    > Aby to opravdu pomáhalo bezpečnosti, uživatel nesmí mít možnost chovat se nebezpečně, nebo to pro něj alespoň musí být značně komplikované.

    Mám udělat mockup password fieldu, který to bude splňovat?

    > > U HTTPS jde o mnohem jednodušší problém s větším dopadem.
    > Nikoli, je to nesrovnatelně komplexnější problém, který se dotýká většího množství subjektů

    HTTPS stačí implementovat na serverech a v prohlížečích. Občas kvůli tomu je potřeba dělat nějaké úpravy, jako třeba změnit hardcodované „http://“. Není potřeba řešit žádnou migraci hashů hesel a nové způsoby autentizace v řádově větším množství autentizačních knihoven.

    > To je právě ten problém, že se místo skutečné bezpečností řeší to, co jak nebezpečně „zní“.

    Ale ono to je právě to, co má vliv na to, jestli se tím bude někdo zabývat. Ne vždy z toho jsem nadšený, ale je to realita, se kterou musíme pracovat. Budeme-li tuto realitu ignorovat, můžeme udělat krásné řešení reálného problému, který ale prakticky nikdo nepociťuje. Jaké bude mít takové řešení dopad.

    > Je to [blacklist] jen dočasné řešení, než se ty podvádějící weby podaří úplně vymýtit.

    Jak docílíte stavu, že nikdo nebude podvádět?

  • 9. 2. 2020 11:10

    Filip Jirsák

    OK, s tímto se už pracuje lépe. Ale ještě to není úplně rozvedené.
    Jistěže to není úplně rozvedené. Je to jen náznak základních principů pro někoho, kdo se teď začal zabývat autentizací. Pokud bychom se bavili o tom, co se má reálně použít, odkázal bych vás například na SCRAM. Ale to už není úplně jednoduchý protokol pro začátek diskuse.

    zkuste to navrhnout tak, aby z toho nešlo poznat dlouho nepřihlašovaného uživatele ani existujícího/ne­existujícího uživatele
    Tohle se řeší velice snadno – i na neexistujícího uživatele server reaguje stejně, jako kdyby uživatel existoval, a pokračuje v autentizaci.

    Nedoporučuje se mít veřejně dostupnou sůl.
    Jenom bych připomněl, že to stále porovnáváme s variantou, kdy se odesílá heslo v otevřeném tvaru. Proti tomu je veřejně dostupná sůl vrchol bezpečnosti.

    Dnes jsou možnosti něco podobného implementovat v JS. Benefity i nevýhody by byly zhruba podobné. Proč se to tedy neprosadilo již dnes?
    Protože by to bylo k ničemu. Pořád byste musel důvěřovat provozovateli webu. Přičemž celý problém s hesly v otevřeném tvaru je v tom, že provozovateli webu důvěřovat nelze.

    Mám udělat mockup password fieldu, který to bude splňovat?
    Žádný password field nebude splňovat to, že bude bezpečný. Bezpečné zadání hesla bude jedině takové, kdy se heslo bude zadávat do UI prohlížeče, které webová stránka nedokáže napodobit.

    HTTPS stačí implementovat na serverech a v prohlížečích.
    A v proxy serverech, antivirech, na firewallech. Potřebujete infrastrukturu certifikačních autorit, odvolávání certifikátů. Potřebujete mít seznam důvěryhodných certifikačních autorit. A také ta implementace TLS je mnohem mnohem těžší, než hashování hesel.

    Jak docílíte stavu, že nikdo nebude podvádět?
    Jednoduše plynutím času. Implementovat nově přihlašování pomocí standardních mechanismů bude mnohem jednodušší, než podvádět. Takže proč by to někdo dělal? Navíc uživatel bude vědět, jak vypadá UI prohlížeče pro zadání hesla, takže podvod „před 10 lety vypadaly přihlašovací formuláře takhle“ na něj fungovat nebude.

  • 7. 3. 2020 9:33

    Vít Šesták

    Tak jsem věnoval čas sepsání srovnávací tabulky:

    https://docs.google.com/spreadsheets/d/17XXbY5w618CZSdiq8ovcpLrifqLRI3O8DPsXqp9ETZM/edit?usp=drivesdk

    * Váš způsob přihlašování jsem nazval „FJ SCRAM“. Vaše iniciály jsem tam přidal, protože samotný SCRAM nepopisuje všechno podstatné.
    * Plus jsem tam přidal i přihlašování asymetrickou kryptografií (ve stylu SSH klíčů).
    * Snažil jsem se nejlepší variantu pro daný řádek obarvit nazeleno. Těch nejlepších variant v dané kategorii může být více.
    * Protože jsme se o přihlašování asymetrickou kryptografií původně moc nebavili a protože v některých kategoriích vyšla jako suverénně nejlepší (byla by jediná zelená), označil jsem zde druhé místo jiným odstínem zelené.

    Srovnání z hlediska bezpečnosti předpokládá, že se řešení podaří prosadit a uživatelé jej pochopí. (Naplnění těchto předpokladů je řešeno níže):

    * Asymetrická kryptografie je jednoznačný vítěz.
    * Úplně jednoznačného poraženého (tzn. ve všech kategoriích) nemáme, ale pro většinu situací se asi shodneme, že znovupoužitá hesla s plain autentizací jsou nejhorší varianta.
    * Nelze jednoznačně určit vítěze mezi password managery a FJ SCRAM. Za mě to jsou password managery.
    * Password managery + FJ SCRAM vycházejí jednoznačně lépe než FJ SCRAM samotný, nevycházejí jednoznačně lépe než password managery samotné.

    V dokonalém světě bychom prostě vybrali to nejlepší řešení z hlediska bezpečnosti (tj. asymetrickou kryptografii) a bylo by. Jenže otázkou je, jak náročné to bude nasadit a vysvětlit všem, jak to správně použít:

    * Tady už nemáme úplně jednoznačné (tj. ve všech parametrech) vítěze ani poražené.
    * Nicméně password managery mají ve většině věcí navrch.
    * FJ SCRAM naopak ve většině věcí propadá a vychází jednoznačně hůře než samotné password managery.
    * Asymetrická kryptografie IMHO v obou kategoriích vychází celkově lépe než FJ SCRAM.
    * Asymetrické kryptografii mohou cestu uhladit právě password managery, ze kterých by se staly obecnější access managery.
    * Za mě tedy bych viděl cestu 1. password managery (=nedokonalé, ale praktické řešení) a 2. asymetrická kryptografie.

    Máte k tomu nějaké námitky? Případné námitky by asi šlo rozdělit do třech kategorií:

    a. Nesouhlas s tím, co v tabulce je.
    b. V tabulce chybí podstatný údaj.
    c. Nesouhlas s celkovým hodnocením.

  • 2. 2. 2020 17:31

    Vít Šesták

    > ale prohlížeč u spousty uživatelů zná heslo, protože je uložené v interním password manažeru. Takže je triviální detekovat, že uživatel někam napsal text, který je shodný s jeho heslem.

    To předpokládá, že máte správce hesel (nechtěl jste se náhodou obejít i bez něj?) a heslo máte v paměti v čitelném stavu (což taky nemusí s hlavním heslem být vždy pravda). Ale se správcem hesel tento problém vlastně nemusíte mít vůbec, tam nemáte důvod to heslo psát. Bez něj naopak ten problém nevyřešíte.

    EDIT: A navíc je to řešení na způsob http://www.lamer.cz/quote/50132 .

    > A i kdyby automatická detekce nefungovala, prohlížeč pořád může mít blacklist, který bude ručně spravovaný.

    Blacklist není zrovna pěkné řešení…

    2. 2. 2020, 17:32 editováno autorem komentáře

  • 30. 1. 2020 12:14

    JVr

    A to, že bezpečně dorazí heslo do schránky (pokud k tomu dojde) také neřeší úplně efektivně bezpečnost, protože pak se vám někdo nabourá do e-mail schránky a zná i hesla, která vám tam tímto způsobem někdo předal.

    Tedy musíte takový e-mail vymazat. Kdo to neudělá má smůlu. Pokud jej pak ale musíte vymazat, proč vám to heslo vůbec posílají? :)

    E-mailem jedině OTP.

  • 30. 1. 2020 16:04

    Filip Jirsák

    Heslo se z prohlížeče neposílá, protože z prohlížeče teče v plaintextu (byť třeba k provozovateli webu šifrovaným kanálem – ale u provozovatele se z šifrovaného kanálu vybalí). Aha, teda z prohlížeče se vlastně posílá, ale u prohlížeče je to v pořádku, u e-mailu ne.

  • 31. 1. 2020 10:40

    BlackRider

    Rozdil je, ze i kdyz se posle plain textovy heslo pres https, tak ho zna jen uzivatel a server (to jak s nim server nalozi uz je jina vec). U emailu si ho ale muze precist kdokoli po trase... to je dost podstatnej rozdil...

  • 31. 1. 2020 15:38

    Filip Jirsák

    I e-maily už se dnes docela často při přenosu šifrují. No a když to heslo zná server, tak ho mimo jiné může poslat e-mailem, čímž to převedete na ten druhý případ.

  • 9. 4. 2020 11:29

    BlackRider

    Emaily sifruji mozna tak v 0.0001% pripadu. resp. nikdy sem zadnej sifrovanej email nevidel jen sem o tom slysel. Ty eshopy samozrejme emaily nesifruji, protoze by si nejdriv museli vymenit klice s uzivatelem a to je tolik prace navic ze to ani nedava smysl...

  • 29. 1. 2020 18:43

    null null (neregistrovaný) 149.254.248.---

    @FIlip Jirsák

    Je úplně jedno co na ten server pošle, něco tam poslat musí a pokud Vám to "musi" někdo pošle zpět veřejně, nebo s tím údělá kdovi co, tak je výsledek stejný. Jistě by se dalo přihlášovat pomoci treba uzitim nejake asimetricke metody, nicméně pro běžné uživatele (většina) je to nepraktické a "slozite" - a ani to neni siroce implementovane. Vždyť se zatim ani nepodarilo lidem vysvetlit aby pouzivali silna hesla - nic proti nim, jenom to tak prostě je.

    29. 1. 2020, 18:45 editováno autorem komentáře

  • 30. 1. 2020 16:00

    Filip Jirsák

    Svou první větu jste vyvrátil svou druhou větou, já jen doplním, že existují i další řešení. Že to není široce implementované, to jenom opakujete můj komentář.

  • 30. 1. 2020 18:06

    null null (neregistrovaný) 80.68.37.---

    @Filip Jirsák

    Nevyvrátil. Ať použijete cokoliv, něco té druhé straně poslat musíte a pokud se k tomu něco někdo dostane, dokáže to využít. Těžko se asi přihlásíte k druhé straně, když jí nikdy nic nepošlete. Normu na telepatii zatím nemáme. (nějaký) Server stejně musí mít přístup k tomu co posíláte a nějakým způsobem to ověřit - je úplně co to je, je to něco co máte jenom Vy a jenom Vy se tím můžete prokázat - jestli je to heslo, cert nebo zbožné přání je jedno. A pokud to něco zveřejní, nebo jinak zmanipuluje pro sebe, tak jste v háji jako s tím heslem.
    Ale klidně mě poučte, rád se něco dozvím.

    30. 1. 2020, 18:07 editováno autorem komentáře

  • 31. 1. 2020 8:46

    Filip Jirsák

    Ale vyvrátil. Sám jste jako příklad uvedl asymetrickou kryptografii. Když se něco rád dozvíte, poučím vás. Asymetrická kryptografie funguje na principu dvou klíčů, které jsou provázané – veřejného a soukromého. Veřejný klíč je odvozený od soukromého, ale opačná cesta je dnešními prostředky neproveditelná – tj. nelze z veřejného klíče odvodit ten soukromý. A dále pro ty klíče a algoritmus platí to, že co transformujete („zašifrujete“) jedním klíčem, převedete do původní podoby („odšifrujete“) tím druhým. Takže server pošle náhodnou výzvu, klient jí zašifruje svým privátním klíčem, výsledek zašle serveru, server dešifruje veřejným klíčem klienta a porovná, zda dostal to samé, co poslal jako výzvu. Pokud ano, ví, že klient má soukromý klíč odpovídající tomu veřejnému klíči. Server tudíž zná jen veřejný klíč a po síti se posílá náhodně vygenerovaná výzva a pak zašifrovaná výzva – k opakovanému přihlášení to nestačí, protože výzva příště bude jiná.

    A to je jenom jedna z možností. Existují i jiné algoritmy pro přihlašování, kde informace, které musí znát server, nepostačují pro úspěšné přihlášení klienta. A také jednodušší algoritmy, kde informace uložené na serveru sice je možné použít pro přihlášení na stejném serveru, ale server nezná heslo ani jeho ekvivalent, takže se s těmi údaji nepřihlásíte nikde jinde. Takový způsob přihlašování je dokonce součástí protokolu HTTP jako autentizační metoda HTTP Digest. Akorát je v prohlížečích implementována otřesně, tudíž se nepoužívá a tudíž je dnes už beznadějně zastaralá (je založená na MD5).

  • 31. 1. 2020 10:53

    BlackRider

    Jenze tohle resi jen pripad, ze ten server nekdo napadne a ten nema hesla dostatecne zabezpeceny. Pokud nekdo napadne klienta, tak sme tam kde sme byly s heslem...

  • 31. 1. 2020 13:35

    null null (neregistrovaný) 213.205.241.---

    @Black Rider

    Ale pořad, tak nebo tak, ta strana ke které se chcete přihlásit po Vás bude něco chtít a pokud to něco zveřejní a někdo to něco pošle za Vás, máte stejný problém jako s tím když to něco bylo heslo.

  • 31. 1. 2020 15:44

    Filip Jirsák

    @BlackRider: Nějak netuším, kam míříte tím, že konstatujete všeobecně známou pravdu, která nemění nic na tom, o čem diskutujeme. Ano, dostatečně silný obušek dokáže eliminovat libovolně silné zabezpečení, protože uživatel nakonec raději sám přístup odemkne. A co?

  • 9. 4. 2020 11:37

    BlackRider

    "@BlackRider: Nějak netuším, kam míříte tím, že konstatujete všeobecně známou pravdu, která nemění nic na tom, o čem diskutujeme. Ano, dostatečně silný obušek dokáže eliminovat libovolně silné zabezpečení, protože uživatel nakonec raději sám přístup odemkne. A co?"

    Jen rikam, ze privatni klic nic neresi, protoze pravdepodobnost napadeni klienta je radove vyssi nez pravdepodobnost napadeni serveru...

  • 31. 1. 2020 12:07

    null null (neregistrovaný) 80.68.37.---

    @Filip Jirsák

    Asymetrická kryptografie sama o sobě neověří že jste to skutečně Vy, jenom že někdo posílá něco zašifrované vaším klíčem - což přenáší problém na uživatele který má běžně problémy i nastavit si silné heslo, jak už jsem psal a jak je běžně prokazováno - a pokud server zveřejní to co jste mu poslal (ten váš "podpis" užitím asymetrické kryptografie) jako to heslo, máte zhruba stejný problém - ano, můžete si handshakovat nový key, jenže ten se nebrání MITM (takže tak i tak potřebujete zabezpečení přenosu) a nepotvrzuje vaši identitu - něco stejného jako jste tu argumentovat u elektronických občanek. A pokud zabezpečíte přenos, můžete klidně posílat heslo a nemusíte se otravovat s certifikátem.

    Ok, můžete přesunout odpovědnost na klienta, v podstatě obdoba SSH, pak ale začnete na uživatele klást pro ně bohužel absolutně nesrozumitelné požadavky. Pokud to přenecháte jakékoliv prostřední autoritě, jste tam kde s bezpečností klientů na hesla a problémy Certifikačních autorit.
    S HTTP Digest sice přenesete odpovědnost ze serveru, ale naložíte ji na běžného klienta a opravdu si nevsadím jestli je to dobrý krok, protože denně můžeme číst o tom co všechno dělají běžní uživatelé špatně. Ale ano, můžete se pak v odpovědích vysmívat uživatelům že je to jejich problém. To by pak šlo.

    Svůj komentář jste vyplýtval na rádoby poučné, spíš výsměvné, poučení o základech asymetrické kdryptografie (což je vlastně stejně nedostatečné a válí se na kdejaké wikipedii) ale k tomu jak skutečně vyřešíte jste nenapsal zhola nic, jenom popsal řešení které přenáší odpovědnost někam jinam, IMHO na slabší článek řetězu - IMHO je jednoduší vyškolit správce serverů a programátory v bezpečnosti než běžné uživatele. Ale možná to vidíte jinak ...

  • 31. 1. 2020 16:06

    Filip Jirsák

    Asymetrická kryptografie sama o sobě neověří že jste to skutečně Vy
    Jste si jist, že znáte kontext, ve kterém diskutujete? Heslo také neověří, že jsme to skutečně já. Heslo se ovšem používá tak, že provozovatel webu má u mého účtu uložené údaje, na základě kterých mne dokáže pomocí hesla ověřit. A místo těchto údajů může mít uložený veřejný klíč a ověří, že já vlastním odpovídající privátní klíč.

    Stručně řečeno: to, k čemu se dnes na webu používají hesla, lze nahradit (mimo jiné) asymetrickou kryptografií.

    pokud server zveřejní to co jste mu poslal (ten váš "podpis" užitím asymetrické kryptografie) jako to heslo, máte zhruba stejný problém
    Vždyť jsem vám v předchozím komentáři vysvětloval, jak autentizace pomocí asymetrické kryptografie funguje. Pokud to nechápete, tak se prostě jen smiřte s tím, že není pravda vaše tvrzení, že pokud server něco zveřejní, je to stejný problém, jako když unikne (byť unikátní) heslo. Naopak, žádný problém to není – veřejný klíč se jmenuje „veřejný“ proto, že je opravdu veřejný, může ho znát kdokoli, můžete ho vystavit na internetu. Např. každý HTTPS server, včetně např. root.cz, posílá při navázání HTTPS spojení svůj veřejný klíč klientovi – a ničemu to nevadí, ten klíč je určený ke zveřejnění.

    něco stejného jako jste tu argumentovat u elektronických občanek
    Ne, ničím takovým jsem neargumentoval – já vím, jak funguje asymetrická kryptografie.

    pak ale začnete na uživatele klást pro ně bohužel absolutně nesrozumitelné požadavky
    Já nechci na uživatele klást žádné nové požadavky, já bych dokonce chtěl na uživatele klást méně požadavků, než dnes – aby nemuseli řešit, že mají pro každý web používat jiné heslo, aby nemuseli složitě zjišťovat, kam heslo mohou zadat a kam ne, aby nemuseli kontrolovat, zda heslo nezadávají do jiného webu atd. Já mám požadavky jen na autory webových prohlížečů, webových standardů, webových serverů a posléze by prohlížeče měly požadavky na provozovatele webů.

    S HTTP Digest sice přenesete odpovědnost ze serveru, ale naložíte ji na běžného klienta
    Nikoli, oproti dnešku by se ta odpovědnost uživatele zmenšila. Mimochodem, ten současný stav bych nenazýval odpovědností uživatele, ale alibismem tvůrců prohlížečů.

    Svůj komentář jste vyplýtval na rádoby poučné, spíš výsměvné, poučení o základech asymetrické kdryptografie
    Které bohužel evidentně nedopadlo na úrodnou půdu, když si stále myslíte, že zveřejnění veřejného klíče je problém.

    k tomu jak skutečně vyřešíte jste nenapsal zhola nic
    Ale napsal, a už jsem to napsal mnohokrát dříve. Heslo si má uživatel vyříkat s prohlížečem, prohlížeč je ten nástroj, kterému uživatel musí z principu důvěřovat. Prohlížeč to heslo má chránit jako oko v hlavě, nesmí heslo ani jeho ekvivalent zpřístupnit nikomu jinému. Uživatel má heslo zadávat do GUI prohlížeče, které bude snadno odlišitelné od webové stránky tak, aby jej nešlo napodobit, prohlížeč pak má uživateli umožnit i vytvoření účtu, změnu hesla a odhlášení. Po uživateli se pak bude chtít jediné – aby heslo nepsal kamkoli, kam napsat jde, ale jenom do toho speciálního dialogu prohlížeče. Už je pak implementační detail, zda tam bude psát master heslo, nebo heslo ke konkrétnímu webu (které klidně může být shodné s heslem pro jiné weby).

    jenom popsal řešení které přenáší odpovědnost někam jinam, IMHO na slabší článek řetězu
    Moje řešení přenáší odpovědnost na prohlížeč. Kam ta odpovědnost patří. Prohlížeč píší odborníci, používají ho laici.

    IMHO je jednoduší vyškolit správce serverů a programátory v bezpečnosti než běžné uživatele
    Není, správci serverů a programátoři webových aplikací jsou na tom se znalostmi bezpečnosti úplně stejně, jako běžní uživatelé. Je naivní myslet si, že jsou na tom výrazně lépe, než uživatelé. A pokud si to snad někdo kdysi myslel, měly ho z toho dávno vyléčit neustálé a další a další úniky hesel.

  • 31. 1. 2020 20:17

    null null (neregistrovaný) ---.as43234.net

    @Filip Jirsák

    "Jste si jist, že znáte kontext, ve kterém diskutujete? Heslo také neověří, že jsme to skutečně já"

    Spíš si nejsem jistý že umíte pochopit psaný text. Už dvakrát jsem napsal že řešení pomocí certifikátů nic neřeší a trpí stejnými problémy, abyste mi, samozřejmě s poznámkou ad hominem jak je Vaším zvykem, řekl že si myslím to o čem jsem napsal že ne. Pokud nerozumíte tomu co píšu, což je možné z mnoha důvodů, tak se zeptejte, tak probíhá komunikace - tohle není soutěž kde musíte vždy aspoň něco odpovědět a počítají se písmenka.

    "A místo těchto údajů může mít uložený veřejný klíč a ověří, že já vlastním odpovídající privátní klíč."

    A pokud udělá to samé co s heslem - tedy že tu zprávu zašifrovanou Vaším privátním klíčem pošle zpět mailem - aby ji někdo mohl případně poslat znova a prokázat se tím, tak jste tam kde s tím heslem. Sice si pak znova ověří že jste ji opravdu vytvořil Vy - a to zaručuje asymetrická kryptografie - ale neověří si že je skutečně poslána tou protistranou kterou má být.* Stejně jako u hesla které vrátí mailem.
    * Kdyby to šlo zaručit, nemusely by existovat certifikační autority.

    "Já mám požadavky jen na autory webových prohlížečů, webových standardů, webových serverů a posléze by prohlížeče měly požadavky na provozovatele webů."

    Jinými slovy na majitele stanic kde tento SW běží - jak z pohledu bezpečnosti, tak řešení potíží.

    "Není, správci serverů a programátoři webových aplikací jsou na tom se znalostmi bezpečnosti úplně stejně, jako běžní uživatelé. "

    "Které bohužel evidentně nedopadlo na úrodnou půdu, když si stále myslíte, že zveřejnění veřejného klíče je problém."

    Nevymýšlejte voloviny které nikdo nepsal. Vaše snaha udělat ze mě hlupáka přichází díky tomu, že si vymýšlíte a mluvíte o věcech které nikdo nepsal, vniveč, anebo toto má být "zveřejnění veřejného klíče"?
    "a pokud server zveřejní to co jste mu poslal (ten váš "podpis" užitím asymetrické kryptografie)"

    :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D :-D

    Měl byste někdy vyjít mezi skutečné lidi.

    31. 1. 2020, 20:20 editováno autorem komentáře

  • 31. 1. 2020 20:30

    null null (neregistrovaný) ---.as43234.net

    @Filip Jirsák

    PS:
    "Ale napsal, a už jsem to napsal mnohokrát dříve. Heslo si má uživatel vyříkat s prohlížečem"

    No to jste napsal, já to chápu a nic proti tomu v zásadě nemám, nicméně stále neodpovídáte na mou poznámku, že ať už ten browser nebo cokoliv zpracuje heslo do jakékoliv podoby, nějaké něco, tak to něco na server poslat musí - a pokud to něco server zveřejní (třeba dá v šanc posláním zpět přes mail) tak se může stát že tomu serveru to něco přiletí zpět v dalším požadavku od kohokoliv.
    Pravdou je že server nebude znát plain-text heslo, nicméně bude znát identifikační něco. Jen tak ze vzduchu si Vás server neověří a já se Vás celou dobu ptám, jak zajistíte aby se s tím něco nestalo to samé co s tím heslem, tedy že ho někdo třeba vrátí zpět mailem - jak to použití toho něco vylepší bezpečnost vůči serveru oproti heslu.

    31. 1. 2020, 20:34 editováno autorem komentáře

  • 29. 1. 2020 17:48

    Miroslav Šilhavý

    Těch problémů e-shopů je daleko víc i mimo "klasický" obor bezpečnosti.
    Jedním nejčastějším nešvarem je, že uživatelský účet = e-mailová adresa. Ne každý vyžaduje jakoukoliv komunikaci, naprosto není potřeba e-mail mít jako primární (a tím pádem povinný identifikátor). E-shopy pak neumějí ani realizovat GRPR právo na zapomenutí atd. atd. Stejně tak e-shop nepotřebuje znát trvale jméno a adresu pro doručení, ta mu musí stačit do doby doručení balíku + 6 měsíců fikce odpovědnosti dodavatele.

    Heslo, párované na e-mail, rozšifrovatelné a zasílané na e-mail je už jen třešnička na dortu s velmi zkaženým korpusem.

  • 29. 1. 2020 18:13

    martyd -f

    Jedním nejčastějším nešvarem je, že uživatelský účet = e-mailová adresa.
    To ale není nešvar. Nešvar je, že třeba zde na rootu si nemůžu dát jako login svůj email a jsem nucen vymýšlet si nějakou "přezdívku", kterou se budu přihlašovat, což pro mě je náhodný string (dle místních pravidel tohleto můžu, támhleto už nemůžu...), jelikož nikde jinde to nepoužívám, žádný nickologin nemám. Email je unikátní identifikátor, současně nutný pro např. obnovení hesla a tak by to měl být vždy primární přihlašovací údaj.
    V případě eshopu pak vyžaduje komunikaci ten eshop - zaslání dokladu po platbě, atd..
    Osobně opravdu nenávidím registrace, kde je zavináč, nebo tečka v loginu bráno jako nebezpečný znak a i rootu jsem odolával až do zavedení povinné registrace. Ne že bych dřív nechtěl, několik registrací jsem měl, ale nikdy jsem si nezapamatoval co jsem vyplnil jako login, jelikož mě to nenechalo můj login použít a na email to nereaguje.
    Vrcholově absurdní nešvar je pak více registrací (loginů) na jeden email..
    Nechci někoho nutit, třeba tady asi ta komunuikace není potřeba, takže by email ani nemusel být... ale to není důvod to jiným zakazovat :) Je to nejunikátnější dostupný údaj, téměř nezapomenutelný, jako stvořený pro přihlašování :)

  • 29. 1. 2020 18:58

    Miroslav Šilhavý

    Vše, to co píšete, je pravda, ale mělo by být na základě dobrovolnosti.

    Založím account, a pokud si k němu nepřiřadím žádnou cestu pro obnovu hesla, mám smůlu. Pokud k accountu přidám e-mail nebo telefon, hned mám možnost obnovit heslo.

    Někdy to vede i k neřešitelným situacím. Stává se (pravda, ne často, ale stává), že telefonní číslo či e-mail si předávají lidé mezi sebou - např. ve stejné funkci ve firmě, telefonní číslo můžete od operátora dostat po někom, ... Zdaleka není ZAJIŠTĚNO, že se jedná o unikátní identifikátor.

    Sledování zásilek nemusí být na e-mailu, mohu si je sledovat v e-shopu, pokud nechci svůj e-mail prozrazovat.
    Doklady si mohu z e-shopu stáhnout - tam také neexistuje NUTNOST e-mail uvádět.
    Dokonce i zboží si mohu nechat poslat to P. O. boxu nebo na nějaké úložné místo - v takovém případě e-shop nemusí znát ani moje jméno, ani moji poštovní adresu.

    Kdo chce, nechť ho používá a na účet si e-mailovou adresu napáruje, ale kdo nechce, nemusí a neměl by být k tomu být nucen!

    29. 1. 2020, 19:01 editováno autorem komentáře

  • 29. 1. 2020 20:39

    Zdeno Sekerák

    Nejvetsim peklem pri "login = email" je, ze spousta lidi (ja napriklad) bezmyslenkovite napise heslo na ten email. Takze jestli si to velke eshopy odchytavaj pak po case maji spoustu email-password kombinaci ktere budou pre vstup do posty funkcni.

  • 29. 1. 2020 18:15

    Row

    Co si budeme povidat, eshop by vubec nemel trvat na registraci (v samosce v cizim meste se taky neregistruju kdyz si tam jednou koupim rohliky ke svacine) a presto takove jsou, stejne tak nechapu, proc je potreba, ne jen dorucovaci, ale hlavne fakturacni adresa (v samosce taky nedavam obcanku k opisu) zejmena pak pri osobnim odberu ci platbe pri prevzeti.

    GDPR je kapitola sama pro sebe, ma byt vyjadreno vyslovnym souhlasem (potvrzenim konkretnich odsouhlasenych ucelu) a presto se plno subjektu omezuje na pasivni informovani a predpokladany souhlas (zejmena se zacatkem platnosti GDPR chodily takto casto maily z mist kde byl uzivatel registrovan - ne jen eshopu). Zprava pak obvykle obsahuje odkaz na zruseni nebo informaci jak zruseni dosahnout, ale souhlas dan nebyl a tudiz jsou data uchovavana v rozporu s narizenim GDPR a taky na to kazdej kasle. :-/

    29. 1. 2020, 18:16 editováno autorem komentáře

  • 29. 1. 2020 18:13

    Vláďa Smitka

    @Row problémy bude mít určitě více než třetina e-shopů, jen třeba nebudou okamžitě odhalitelné primitivním scanem...

    Vždycky mám nepopsatelné pocity, když nahlašuji nějakou amatérskou chybu, která zpřístupňuje celou databázi a čtu na daném webu "XY považuje bezpečnost osobních údajů zákazníků za jednu ze svých priorit", "XY přistupuje odpovědně ke zpracování osobních údajů a zejména dbá na jejich zabezpečení" a podobné.

  • 29. 1. 2020 20:15

    bez přezdívky

    Po odoslaní registračného formulára má skript bežiaci na servery eshopu heslo k dispozícií v čitateľnej podobe, a práve v túto dobu Vám ho môže skript poslať na zadaný email v uvedenej čitateľnej podobe. To však neznamená, že ho následne v ďalšej milisekunde do databázy neuloží zahešované (nepliesť si so šifrované) a čitateľné heslo "zahodí". Takže Vaša domnienka o tom, že automatický každý kto Vám taký email pošle ukladá heslo v čitateľnej podobe je nesprávna.

    Avšak v prípade, že si pri obnove hesla Vám na email príde pôvodne zadané heslo, je jasné, že daný server pôvodné heslo uložil do DB v čitateľnej alebo šifrovanej podobe, čo je samozrejme nesprávne.

  • 30. 1. 2020 23:08

    bez přezdívky

    Tady je zas odborníků na kryptografii. Nesvarem eshope je ze nepodporuji single-sign on a vyzaduji registraci kterou neumeji a ukladaji pak hesla kdovi jak. Sifrovat hesla je spatne, hesla se maji hashovat se saltem na strane klienta v prohlížeči. Uplne idealni by bylo zadna hesla nemit a pouzivat webauthen/fido nebo alespon pbkdf2. Pak se uzivatel overuje challenge podepsanou privatnim klicem unikatnim pro dany web.

  • 31. 1. 2020 1:00

    m1x

    Jestli server s heslem nakládá dobře nebo špatně je jedna věc. Ale když ho rovnou a bez vyžádání pošle nepříliš bezpečným e-mailem... pak už je to prostě jedno.

    A když ještě odepíšou že bezpečnost berou vážně... pak asi o bezpečnosti nic nevědí?

  • 29. 1. 2020 20:16

    bez přezdívky

    V mnohých informáciach je štúdia možno prínosná, hlavne pri odhalení malého počtu eshopov so skutočným bezpečnostnými rizikami. No myslím, že sa až príliš snažili dosiahnuť bulvárneho nadpisu "1/3 eshopov má bezpečnostný problém".

    HTTP/2
    Štúdia sa zameriava na bezpečnosť, na základe čoho vyvodzujú aj závery, ale presne som nepochopil aké bezpečnostne riziko je v tom (akú to malo váhu vo výsledkoch), ak eshop nepoužíva HTTP/2, keďže používanie daného protokolu z bezpečnosťou moc nesúvisí.

    TLS 1.3
    Rovnako by nemal byť penalizovaný ani eshop, ktorý nepodporuje protokol TLS 1.3 ale "len" TLS 1.2, keďže aj používanie daného protokolu je stále bezpečné.

    Security.txt
    Ak na eshpe používam všetky bezpečnostné prvky ale nevyužívam "security.txt", mám bezpečnostný problém? Nie, nemyslím si!

  • 30. 1. 2020 8:36

    Vláďa Smitka

    To "odhalení malého počtu eshopov so skutočným bezpečnostnými rizikami" se týká přes 4000 e-shopů, to mi zase tak malé číslo nepřijde. A u dalších skoro 2000 ještě zůstal otazník "možná" a chtělo by je to ručně zkontrolovat na XSS a SQLinjection.

    HTTP/2 jsem zkoumal, protože mi to přišlo zajímavé z technického pohledu jako doplněk k HTTPS. Máš pravdu že to s bezpečností přímo nesouvisí (jen někde ukazuje na neaktualizovanou OpenSSL). Weby bez HTTP/2 nebyly samozřejmě počítány bez ty s bezpečnostními problémy.

    To samé TLS 1.3, opět jsem to zkoumal především ze zájmu (i když zde se již o bezpečnost jedná) a weby bez něj nebyly počítány mezi ty s bezpečnostními problémy.

    Security.txt, jeho absenci také neberu jako bezpečnostní problém, beru ho ale jako signál, že se bezpečnost někdo pokoušel zabývat.

    Do čísla 1/3 patří právě těch 4000 e-shopů s prokazatelnými kritickými problémy (především prokázané XSS, přístupné zastaralé Adminery, přístupné zálohy a dumpy db, přístupné konfigurace s hesly, s file managery bez autentifikace, napadnutelným SSL = F v SSL Labs a podobně). K tomu se přidá velká skupina webů s výpisem phpinfo(), weby exponující své error logy, debug informace, části konfigurací a podobně.

  • 30. 1. 2020 10:02

    Miroslav Šilhavý

    Samozřejmě. To ale neznamená, že je žebříček bezcenný. Musíte ho umět interpretovat.
    Například musíte vědět, že na SSLLabs nelze dosáhnout score A+, pokud máte zapnuté TLS 1.3. Stejně tak musíte umět posoudit i ostatní kritéria.

    V pásmu vyšších score je to už na individuální posouzení, jestli se opravdu jedná o riziko.
    Poměrně cenný je v pásmu horších score. Tam si dovoluji usuzovat, že to opravdu svědčí o zanedbávání.

    Některé firmy pochopily, že digitální prodej je důležitý a věnují se mu. Je však spousta těch, kteří ho berou jen jako nutné zlo. Pak se to projevuje tím, že ani nechtějí být technologickými leadery, neinvestují do rozvoje tak, jak by bylo potřeba. Pentesty se dělají jen jako firemní policy a spokojí se s tím, že projdou a mají podnikový cíl z krku.

    Je dobře, že aspoň nějaká snaha o reflexi stavu existuje.

  • 30. 1. 2020 11:49

    Miroslav Šilhavý

    Beru zpět, už to vidím taky. Weby, které mi shazoval na A, už mi ukazuje taky A+.
    Dříve to shazovalo kvůli TLS_AES_128_GCM_S­HA256, kvůli AES128. Ta je ale v TLS 1.3 povinná, takže A+ nešlo dosáhnout.

    Dobře že to fixnuli.

  • 30. 1. 2020 11:02

    hawran.diskuse

    Za obzvláště velkou prasárnu považuji to, že některé e-shopy nebudou fungovat bez 3d-party sušenek.

    Umožní registraci, ale pak se bez těch kukin nepřihlásíte. K přihlášení k takovému eshopu aby jeden pouštěl prohlížeč v safety módu (tj. kompletně bez addonů) a ještě si v tom prohlížeči explicitně vypnul blokování těch 3-rd party objektů.
    (které snad už většina moderních prohlížečů defaultně blokuje)

    Proč?

  • 30. 1. 2020 14:18

    Bleble

    To je jednoduché, 80% eshopů jsou garážovky, které nemají kapacitu na to zaměstnávat na full time tým vývojářů a staví eshopy na dostupných univerzálních modulových systémech. A prakticky každou další funkčnost zajistí 3rd party služba nasazením scriptu do hlavičky webu.

    Nejlépe je na tom v tomto ohledu alza, ty mají 3rd party jen GA, PayPal a GTM, zbytek mají nadrátovaný přímo v jejich scriptech, ale také mají tým 200 IT pracovníků. Na druhou stranu, díky tomuto, já s mými schopnostmi již nedovedu na jejich webu zamezit trackování, zatímco když to řeší 3rd party script, jde jednoduše vypnout, stejně jako 3rd party cookie nebo iframe. Takže pro Power Usera jsou ty služby třetí strany nakonec lepší.

  • 30. 1. 2020 11:31

    Bleble

    Celý ten článek je jen PR nějakého pána, co si říká bezpečnostní expert. Posuzuje tam i naprosto nepodstatné věci, které nemají s bezpečností nic moc společného a při jejich implementaci může dojít k omezení funkčnosti u spousty zákazníků. A eshop je od toho aby prodával a ne vysvětloval lidem, že si mají koupit nové PC, vystudovat IT obor a korektně si nastavit systém.

    Dále k příspěvkům ohledně zasílání hesla na email. Nevidím v tom žádný problém. Pokud si dá někdo na eshop heslo, které má i k nějaké důležité službě, tak je prostě hlupák. Naopak spoustu zákazníků ocení, že heslo si při opakovaném nákupu najde v emailu a nemusí řešit reset hesla atd.

    K příspěvkům ohledně osobních údajů. Eshop musí znát fakturační a dodací údaje a uchovávat je 5 až 10 let a říkají to zákony o účetnictví a o DPH, kdy jste povinni uchovávat doklady a není to v rozporu s GDPR. A celé právo na výmaz je nesmysl, jelikož musíte zaevidovat žádost o výmaz společně s údaji, které vymažete. Takže je na jedné straně vymažete a jinde zase zavedete.

  • 30. 1. 2020 15:05

    Miroslav Šilhavý

    K příspěvkům ohledně osobních údajů. Eshop musí znát fakturační a dodací údaje a uchovávat je 5 až 10 let a říkají to zákony o účetnictví a o DPH, kdy jste povinni uchovávat doklady a není to v rozporu s GDPR.

    Absolutně nemusíte. Doklad může být bez jména a naopak si tím zjednodušíte ochranu údajů v účetnictví. Jediným případem, kdy opravdu musíte uchovávat údaje jsou případy, kdy je kupec plátce DPH a vyžaduje vyplněný daňový doklad kvůli svému účetnictví. Pak musíte údaje vyplnit a uchovávat. Ale ani ty nemusíte uchovávat na e-shopu, stačí odděleně v účetnictví.

    Nic Vám tedy nebrání provozovat e-shop, který vystavuje faktury bez jména a to doplníte jen na vyžádání. Stejně fungují i kamenné prodejny (IKEA, Datart, ...), tam také nakoupíte klidně za 100 tis. Kč a na účtence jméno nemáte, dokud o to nepožádáte. Jakmile balík odešlete, je ve Vašem (oprávněném) zájmu trackovat balík a uchovat si informace po dobu půl roku, kdy platí zákonná fikce odpovědnosti dodavatele. Po půl roce můžete smazat i ty, protože pak už je břemeno prokazování na straně zákazníka.

    Pokud někdo tvrdí, že uchovávat údaje je oprávněný zájem podle GDPR a odkazuje se na zákon o účetnictví a DPH, pak je to chybný výklad. Oprávněný zájem je pouze po tu dobu, co jsem psal o odstavec výše a v případech daňových dokladů s vyplněným odběratelem.

    Nedělejte z té problematiky větší vědu, než je.

  • 30. 1. 2020 15:58

    Bleble

    Na toto se obtížně reaguje, je to takový mix pravdy s totálními nesmysly.

    Takže jen krátce, uvádíte kamenné obchody, které by Vám u vchodu nejraději zavedli podkožní čip, aby mohly shromažďovat Vaše zájmy, takže jestli máte na účtence jméno nebo ne je vedlejší.

    Představte si obsluhovat systém, kde v objednávce máte pouze doručovací údaje, objednávka na eshopu se po přenosu do dalšího systému očistí od doručovacích údajů a eshop je bude volat zpět pokaždé, kdy zákazník vleze do historie, v dalším systému pro dopravce zůstanou ty doručovací údaje s odkazem na číslo objednávky. Tam se smažou za půl roku. A za rok bude chtít ten dotyčný zákazník zboží reklamovat. Ne, tohle prostě nemůže reálně fungovat, asi jste nikdy pro žádný eshop nedělal, že ne? Nebo co když řidič doručovací služby zdrhne s dobírkovným nebo zákazník odvolá platbu kartou, jak budete řešit tohle, když ani nevíte, kdo zboží kupoval?

  • 30. 1. 2020 19:56

    Miroslav Šilhavý

    objednávka na eshopu se po přenosu do dalšího systému očistí od doručovacích údajů a eshop je bude volat zpět pokaždé, kdy zákazník vleze do historie

    Nic Vám nebrání mít zákaznickou zónu, kde uvidíte objednávky i historii, ale nemusí tam být jediný údaj o zákazníkovi. Třeba zákazníci, co vždy vyzvedávají zboží osobně. Dokonce Vám nic nebrání nabídnout zákazníkovi i uchovávání údajů, pokud o to stojí a dokud o to stojí.

    A za rok bude chtít ten dotyčný zákazník zboží reklamovat.

    K reklamaci potřebujete na účtence mít jméno? Já tedy v obchodech reklamuji s obyčejným paragonem a není na překážku, že tam jméno není. E-shop pro vyřízení reklamace taky nepotřebuje vidět doklad se jménem - ostatně v praxi často eshopy řeší reklamaci s účtenkou na jiné jméno (dary, prodané zboží, ...).

    Nebo co když řidič doručovací služby zdrhne s dobírkovným nebo zákazník odvolá platbu kartou, jak budete řešit tohle, když ani nevíte, kdo zboží kupoval?

    Řidič doručovací služby je problém té doručovací služby. Oni od vás převzali k přepravě balík na dobírku a musí Vám vrátit buďto balík, nebo poslat doběrečné. Jakou roli v tom hrají údaje o zákazníkovi?

    V kamenném krámě vracíte peníze zákazníkovi, o kterém taky nevíte zhola nic. Prostě přijde vrátit zboží a vy mu dáte peníze (nebo pošlete na kartu). Pokud je to potřeba pro doklad o převzetí peněz (kvitanci), mohou být tyto údaje jen na tom dokladu, ale nemusíte už k tomu mít párovaný doklad o koupi (příklad: v Hornbachu vracím zboží. Na vratku chtějí znát moje jméno - aby věděli, komu vydali peníze. Ale vůbec netuší, jestli jsem to já, kdo zboží kupoval - není to totiž k ničemu).

    Bohužel e-shopy historicky vymýšleli a dodnes vymýšlejí ajťáci, kteří mají rádi vše propojitelné, kategorizovatelné, a vůbec je nenapadne, že to často není potřeba. Viz Vaše příklady, které mají v reálném (ne-digitálním) světě svoje analogie, které fungují zcela jinak.

    30. 1. 2020, 20:00 editováno autorem komentáře

  • 30. 1. 2020 19:37

    Vláďa Smitka

    Posuzuje tam i naprosto nepodstatné věci, které nemají s bezpečností nic moc společného a při jejich implementaci může dojít k omezení funkčnosti u spousty zákazníků

    Něco konkrétního? Jsem si vědom pouze HTTP/2, to jsem testoval, protože se to přímo nabízelo u obecného testu HTTPS a protože mě to osobně zajímalo. Ano je tam i pár dalších věcí, které nemusí znamenat přímé ohrožení - třeba volně přístupné statistiky návštěvnosti z access logů - ty patří do kategorie věcí, které nebyly zamýšlené jako veřejně přístupné, ale chybou se tak staly.

  • 31. 1. 2020 8:34

    Filip Jirsák

    Opravdu? Všechny ostatní údaje mimo hesla v databázi musí být v otevřeném tvaru – přičemž pokud je uživatel rozumný, heslo je jediný z těch údajů, který je úplně nezajímavý, protože je to unikátní klíč pouze pro daný web.