Vlákno názorů k článku Ještě k úniku @gmail.com adres s hesly: používání e-mailu jako login je potíž od MMN - Za ty inkrementace čísel na konci hesla ale...
-
MMN (neregistrovaný)
Za ty inkrementace čísel na konci hesla ale často mohou dementní omezení na hesla. Teď jsem si zakládal účet u nejmenovaného zlého platebního systému:
Délka hesla max. 20 znaků (WTF?).
Žádné mezery (navíc to sdělí až ex post, nikoliv při prvním zadávání hesla).
Požadavek na čísla a jiné symboly (které samozřejmě většina lidí prostě nafláká nakonec).Takže je v podstatě nereálné mít unikátní, silné a zapamatovatelné heslo. Krásně to popisuje Randall Munroe:
-
Ano, je to tak. Napsal jsem HTTP Digest, protože je to protokol, který už je ve standardu dlouho (i když není povinný), a je implementován ve spoustě klientů i serverů. A proti dnešku by to bylo podstatné zlepšení.
Odolný proti krádeži údajů ze serveru by měl být třeba SCRAM, ale přesný princip fungování jsem zatím nezkoumal. -
Uživatel zadá své heslo, k tomu se připojí pojmenování serveru a z toho vytvoří prohlížeč hash. Ten pošle serveru a server si tenhle hash uloží. Tedy mělo by to tak být, pokud by se registrace standardizovala. Dál už by to bylo současné HTTP Digest. Server pošle výzvu (náhodný text). Prohlížeč se uživatele zeptá na heslo, připojí pojmenování serveru, vytvoří hash (pokud uživatel zadal správné heslo, je to ten samý hash, který má uložen server). K tomuto hashi prohlížeč přidá výzvu serveru a vytvoří druhý hash, který odešle serveru. Server zná první hash i výzvu, spočítá druhý hash a porovná jej s tím, který dostal od uživatele. Tj. uživatel zadává jen heslo, díky prvnímu hashi, který obsahuje i pojmenování serveru, se nedá znalost jednoho hashe použít pro přihlášení na jiný server, i když má uživatel stejné heslo. Díky té výzvě a druhému hashi není možné použít replay attack – i když někdo odposlechne druhý hash poslaný po síti, nemůže jej použít, protože příště pošle server jinou výzvu.
Když uživatel používá více prohlížečů, prostě jen do prohlížeče zadá svoje heslo. Prohlížeč si nemusí nic pamatovat, pojmenování serveru a výzvu dostane od serveru, heslo zadá uživatel. Proto je to právě jednodušší na použití, než správce hesel, protože nepotřebujete nic nikam ukládat, stačí jenom prohlížeč. -
Jenda (neregistrovaný)
> A jak chcete zajistit, že nějaký hash patří zrovna tomuto uživateli?
Byl to překlep a mělo tam být „zjistit“? (jinak tomu nerozumím) Z toho protokolu prostě vypadne „ano“/„ne“.
> Jak chcete zajistit, že tento hash nepoužije někdo jiný?
Tím, že pokaždé generuju jinou challenge. Takže ten hash použít může, ale bude mu úplně k ničemu.
> A jak se řeší situace, kdy jeden uživatel používá službu na více prohlížečích (doma u PC, na cestách v notebooku apod)?
V čem by měl být problém? Uživatel prostě zadá svoje jméno a heslo a o nic se nestará.
-
Heslo napsané na monitoru nebo v peněžence prakticky nevadí. Spousta uživatelů pochopí, že heslo se v prohlížeči píše jen do toho jediného dialogového okna, stejně jako spousta uživatelů už dnes chápe, že heslo má být složité. Dost uživatelů chápe i to, že nemají při registraci zadávat e-mail a heslo, které je stejné, jako heslo k tomu e-mailu. Akorát to těm uživatelům nikdo neřekl.
Systém, kdy vyzrazení jednoho hesla znamená kompromitaci všech služeb, je i password manager. Pochybuju o tom, že si pamatujete stovky hesel, takže nějaké sdružování pod jedno nebo několik hesel taky používáte. V tom vám nic nebrání. Jde jenom o to, aby provozovatel služby vaše heslo (ani jeho ekvivalent použitelný jinde) vůbec neznal.
HTTP Digest se občas používá, ale bohužel málo. Pokud máte něco lepšího, co by se hodilo pro použití na veřejném webu, sem s tím. -
Petr (neregistrovaný)
1) BFU nebude mít nikdy složité heslo
2) pokud bude, bude ho mít někde napsané, ideálně na monitoru, v peněžence a v poznámkách na home v mobilu
3) uživatel heslo zadá kamkoliv bez ohledu na varovné hlášky, protože on ten obrázek prostě chce vidět
4) vůbec se mi nelíbí systém, kde vyzrazení jednoho hesla znamená kompromitaci naprosto všech mých služeb
5) co jsem rychle koukl na HTTP Diggest na wiki tak doufám, že to nikde nasazovat nebudou a vyhnije to -
Petr (neregistrovaný)
Zatím se mi nepodařilo žádného člověka přesvědčit na správce hesel - tedy ano, ale dlouhodobě nevydržel nikdo (já mám keepass přes 8 let s 1000 hesly). Nikdo z běžných lidí nemá složitá hesla, nepamatoval by si je, z toho stejného důvodu nemají ani hesel více (nebo více jak 3). Pokud nějaká služba vyžaduje pravidelnou změnu hesla, je to konečná a řeší to zvyšujícím se číslem na konci nebo papírkem na monitoru. Ze stejného důvodu je silně problematické požadovat login jiný než email, lidi to nejsou schopni vymýšlet a spravovat.
Potkal jsem dokonce i dost těch, kteří vůbec nevědí, že když po nich služba chce email a heslo, že mohou (měli by) zadat jiné heslo než do toho mailu, že to spolu nesouvisí.
Prostě BFU je z pohledu IT lidí "zařízení" poměrně jednoduché a předpokládat nějaké rozumné nakládání s přihlašovacími údaji je dost naivní. Proto těch problémů a úniků rozhodně ubývat nebude.
ČLÁNKY DO MAILU