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/neexistují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.