Ne - příčina je trvalé nepochopení a koncepčně špatná implementace autentizace napříč téměř všemi weby.
K přihlašování jsou určené klientské certifikáty. Všechny prohlížeče je umí už léta. Existují i hardwarové tokeny. Server pak zná pouze váš veřejný klíč a není co ukrást. Řešilo by to jak problémy s únikem hesel, tak problémy, kdy máte na různých stránkách stejné heslo.
Napadají mě jen dva weby, které používám a které mají přihlašování přes certifikát. Portál VZP a certifikační autorita StartSSL.
Uživatelům této služby v ČR při úniku hesla (pokud nepoužívají stejné jako jinde) hrozí jediné: hacker může dát na váš profil, že posloucháte Ortele, Kabát, Biebra a nebo nějakou jinou podobnou sračku, která vás diskredituje v očích vašich internetových přátel. Možná proto uživatelé volí naprosto lichá hesla.
"Navíc při přihlašování certifikátem musíte mít certifikát vydaný některou z autorit, které server důvěřuje"
To ale není nutnost. Jen takový zvyk. Klidně si můžete při registraci zaregistrovat nějaký self-signed certifikát.
Server přece nepotřebuje přece identitu ověřenou někým třetím, stačí, že ví, že jste to pořád vy. Dneska (s heslama) to taky nemá ověřeno od někoho třetího.
Máme rok 2016 a systémy stále nenabízejí formáty pro tvorbu hesel a pokud ano tak pro hesla uživatelem mnohdy nezapamatovatelná,které i když se tváří jako bezpečné tak většinou mají za následek to že uživatel heslo zapomene a je nucen si ho prostřednictvím emailu nebo SMS poslat což je samo o sobě nesmysl.
Hardwarový token na web, který jen zaznamenává hudbu kterou posloucháte? Není to silně paranoidní? Máte zámek s číselnou kombinací pouze na ledničce nebo i na konzervách s jídlem?
https://youtu.be/dbRoVcULGBI
Tady opět někdo míchá hrušky a jablka.
Použitý programovací jazyk neříká vůbec nic o bezpečnosti aplikace.
V každém jazyce se dá vytvořit zrůdná a totálně děravá aplikace včetně tolik opěvované a vychvalované Javy.
O bezpečnosti rozhoduje zkušenost vývojového týmu ne použitý jazyk. To samé se týká knihoven a frameworků. I ty se dají použít dobře a špatně.
Používat jediný certifikát na všechno je úplně stejná blbost jako používat všude stejné heslo. Jakmile unikne privátní klíč, může se dotyčný přihlásit tímto klíčem všude.
Certifikát nemusí být na úrovni navazování spojení ale až v datové komunikaci. Dá se použít např. i tak že jsou dána data požadavku. Klient tato data digitálně podepíše a odešle na server. Ten si ověří digitální podpis a tím má ověřenu totožnost protistrany.
Vše samozřejmě běží přes https.
Součástí podepsaných dat je i časová značka, tj. podpis není nikdy stejný. Pokud by jej po cestě někdo zachytil tak mu k ničemu není.
Není to jen zvyk, protokol TLS je tak navržen. Server sice může poslat prázdný seznam důvěryhodných autorit, ale je na klientovi, co s tím pak udělá. Předchozí registrace je obcházení protokolu TLS, protože když už se uživatel registruje, nepotřebuje žádný certifikát, stačí mu veřejný klíč. Ale s takovou variantou TLS nepočítá.
Server přece nepotřebuje přece identitu ověřenou někým třetím, stačí, že ví, že jste to pořád vy. Dneska (s heslama) to taky nemá ověřeno od někoho třetího.
Problém je právě v tom, že pro takovéhle použití nebylo TLS navrženo. Ano, dá se ohnout a používat i takhle, ale ještě to komplikuje už tak dost odpudivou HTTPS autentizaci klientským certifikátem. Nemluvě o tom, že podpora v prohlížečích je stejně příšerná, jako podpora bezpečné autentizace HTTP digest – nesrozumitelné ošklivé GUI, nemožnost se odhlásit…
Tohle má jednu takovou drobnou vadu – nejde to udělat v současných webových prohlížečích bez nějakého doplňku (třeba Javy). A tedy že by se mi chtělo někam pokaždé přihlašovat tím, že podepíšu větu „Souhlasím s tím, že se dne 9. září 2016 v 7:02:11 SEČ přihlásím na web xyz“…
Pokud by jej po cestě někdo zachytil tak mu k ničemu není.
Akorát by se s ním v ten okamžik přihlásil.
Používat jediný certifikát na všechno je úplně stejná blbost jako používat všude stejné heslo.
Používat všude stejný certifikát znamená, že při spolupráci provozovatelů webu půjde zjistit, že jde pořád o stejného uživatele. Kdyby bylo přihlašování heslem udělané na webu bezpečně, používání stejného hesla by ničemu nevadilo, protože by se nikdo nedozvěděl, že je to heslo stejné.
S klientskými certifikáty je bohužel ten problém, že inženýrská „bezpečnost“ zcela zastínila jejich použitelnost (a tím pádem bezpečnost). Když se při přihlášení klientským certifikátem cokoli nepovede, je to chyba navázání TLS spojení, a při chybě v TLS se spojení okamžitě ukončuje, aby náhodou neunikaly nějaké bezpečnostně zajímavé informace. Takže uživatel skončí s prázdnou stránkou a může hádat, v čem je problém. Já v takovém případě sahnu po Wiresharku a oddebuguju si to, ale jistě uznáte, že to je postup na zcela opačné straně od „komfortní“.
Navíc při přihlašování certifikátem musíte mít certifikát vydaný některou z autorit, které server důvěřuje, a v tom by byl ještě mnohem větší nepořádek, než v autoritách vydávajících DV certifikáty.
Pro bezpečné přihlašování stačí třeba SCRAM nebo i HTTP Digest. Jenže podpora v prohlížečích i serverech je mizerná, ve standardu úplně chybí vytvoření hesla a v prohlížečích chybí odhlášení. Vyřešilo by to problémy s úniky hesel, s únosy HTTP session, a praktické použití je mnohem jednodušší, než přihlašování klientským certifikátem (a začít se s tím klidně mohlo už dávno, kdy se o masovém nasazení HTTPS ještě nikomu ani nesnilo).