Názory k článku Jak na tomhle webu změním heslo? Pomocí známé URL pro změnu hesla

.js z klientova stroje pošle hashe dva

No tohle snad nemyslite vazne?! Doufam ze tohle na produkci nikdo nema ...

Se zbytkem souhlasim.

My to tak normálně děláme je v tom snad nějaký problém?

Mohl bys rozvést proč je to tak špatně?

No muzeme zacit treba tim, ze vubec nutim uzivatele mit zapnuty JS k tomu aby se vubec prihlasil. Copak vy ani trosku nemyslite na tty view? Ano vim ze pres CLI pristupuje na web jeden z 10ti milionu, ale clovek to nekdy proste potrebuje nebo ma proste JS vypnuty.

Dale pak predavam pripadnemu utocnikovi, informace o tom, jakym zpusobem hesla hashuji, jakou mam sul, kolik mam iteraci apod., cimz mu de-facto ulehcuji praci.

Jak resite aktualizace? Resp. jak si muzete byt 100% jisti ze se uzivateli stahne posledni verze Vasi JS knihovny a nevystavite ho tak omylem situaci, kdy mu to pise spatne heslo?

A hlavne uz jen ta myslenka. Proc mam proboha na klienta prehazovat zodpovednost za hashovani? Copak v JS provadite rovnou SQL dotazy? Co kdyz dane appce pribude uplne jine view, at uz API, nebo proste jen mobilni aplikace. To hodlate psat hashovaci funkce pro kazde view, ktere se vyskytne a budete se modlit aby ste to vsude spravne a hlavne stejne implementovali?

Samozrejme jinou kapitolou jsou offline aplikace, kde je treba authorizovat uzivatele i offline, ale zde se prave predava zodpovednost na uzivatele, ktery se vetsinou necha prihlaseny a zabezpeceni resi OS, resp. uzivatel co si zamkne pri odchodu system, ale chapu ze muze byt i situace kde je to proste potreba.

Hlavni bodem je ale bezpecnost aplikace. Tim ze hashuji na strane klienta se hash stava heslem. Pokud mi tedy utocnik stahne DB s hashi, muze se prihlasit jako jakykoliv uzivatel.

Nez si tady nekdo zacne zas naklikavat minuska, uvedomte si ze drtiva vetsina uniku DB neni zpusobena kompromitaci produkce, ale nalezem zapomenutych zaloh DB nebo primo kompromitaci zalozniho serveru.

bez přezdívky

Ale to je ovsem naprosto spravny pristup, ja zde resim tu magorinu ala, primarni hashovaci system na strane klienta. Konec koncu klient muzeme mit plugin, ktery mu vzdy automaticky zahashuje pred odeslanim formulare heslo. Takze ano s timto souhlasim a je to presne to co jsem mel na mysli.

Platí čtyři premisy:
1) Musím mít šifrovaný kanál, jinak je jakákoliv ochrana hesla na pytel.
2) Klient musí vždycky z principu poslat něco, čím se autentizuje a identifikuje.
3) V zájmu klienta je, aby heslo neopustilo jeho počítač.
4) Neexistuje standardní funkcionalita prohlížeče, která by čla použít pro login, logout, timeout,...

(3) se dá se toho docílit tím, že server pošle unikátní sůl, klient připojí heslo a odešle hash. Když se někdo pokusí vydávat za klienta, hash ze soli bez znalosti hesla nevypočítá. (1) zajišťuje, že neodposlechne hotový hash při přihlášení.

Pokud si udělá útočník dump tabulky uživatelů, vidí sůl a vidí hash. Pokud je sůl unikátní pro každýho klienta (např. nonce), tak musí pro každýho klienta extra vyblít jeho verzi rainbow tables. Nebo brute force pro každýho klienta extra...

Problém by byl, kdyby hash přímo odeslal při přihlášení, ale hashovat se dá víckrát v sérii, takže nic nebrání mít v tabulce uloženo třeba hash(salt | username | hash(salt | password)) - vnitřní hash dělá klient, vnější server. Pak se daty z tabulky nepřihlásíš ani náhodou. A to se ještě můžou lišit soli, na serveru můžeš přisypat username,... Furt nevidím problém.

Mě přijde teda zmatený ten tvůj popis. V tvém přístupu sice útočník odposlechnuvší komunikací ani majitel serveru (nebo útočník databázi serveru ukradnuvší) neznají heslo v té formě, jak ho zadává uživatel, to je pravda. Ale znají hash a ten jim pro přihlášení stačí - stačí modifikovat ten klientský JS aby posílal přímo, to co se zadá do pole "heslo" (vypnou hashování) a pak zadají do pole hesla odchycený/získaný hash a voilá, jsou tam i bez znalosti hesla,.

Případně je možno udělat variantu na OTP, kdy server má heslo v plaintextu, při pokusu o přihlášení pošle klientovi salt (pokaždé jiný) a požaduje po něm, aby zahashoval heslo s tímhle saltem. Pak odchycení komunikace je útočníkovi k ničemu, ale je nutné mít to heslo na serveru uložené => taky nic moc.

... nebo se můžete na hashování hesla přenášeného nešifrovaným kanálem vykašlat a kanál zašifrovat, čímž ho nejen ochráníte oproti odposlechu, ale jako bonus tím ochráníte i další komunikaci.

Navrhovaný systém má zásadní slabinu: Když získáte databázi uživatelů serveru se zahašhovanými hesly, tak se dokážete přihlásit jako jakýkoli uživatel, protože u vás je (jednou) zahašhované heslo shared secret daného uživatele. Vy sice říkáte "majitel serveru o vás může vědět všechno", jenže to platí tak možná u jednomužných webů. V reálu mají k serveru přístup administrátoři různých úrovní (a zprostředkovaně programátoři), kteří o vás rozhodně neví všechno.

Co se týče údajné ochrany před získáním hesla jak ho zadává uživatel, tak ta není až o tolik lepší, protože na zahashovaná hesla je možno použít slovníkový útok, úplně stejně, jako v případě klasického (*) přihlašování. Prakticky jedinou výhodu máte u scénáře, kdy útočník odchytí na serveru komunikaci obsahující přihlášení. Ale to není až tak častý útok - dump databáze je mnohem častější.

*) Kdy mám uložena zahashovaná hesla a klient posílá plaintext heslo, které proti těm zahashovaným heslům ověřuji.

Šifrovat se musí tak jako tak, ať se přenáší heslo, nebo hash. Alternativou by bylo do hashe krom hesla a soli hodit i časovou značku a tím se to dost komplikuje (v DB je hash vypočítaný bez časové značky,...) a útočník má možnost únosu session.

Jinak co je potřeba k přihlášení je dvojice tokenů, jeden od klienta, druhý k DB. Když se shodují, může se klient připojit.

- Klient má data - URL, user name, heslo. Všechno dohromady zahashuje a pošle na server.
- Při registraci to server osolí a podruhý hashuje. Sůl a druhý hash si uloží, klidně na jeden řádek tabulky.
- Při přihlášení to server osolí solí z DB a porovná s uloženou hodnotou.

Pokud někdo nezná heslo + username + url + něco dalšího, co se přimíchává, tak nedostane správný přihlašovací token, auth failed, čus.

Pokud někdo čobne DB a zkusí hash z ní poslat jako heslo, tak má smůlu, server chce nesolený hash a ten v DB není. Auth failed, nazdar.

Vypočítat přihlašovací token z hashe a soli v DB nejde, neprolomený hash je jednosměrná funkce. To samý se získáním hesla.

Nezbývá, než brute force hledat data velikosti hashe, který dají při přidání soli to, co je v DB. Pak se to dá použít k přihlášení, ale jenom na ten jeden konkrétní účet uživatele na jednom konkrétním webu. Stojí to za to?

Cely komentar je jednou velkou fabulaci nad off-topicem, ktery resi vyresene, reaguje na neco uplne jineho a v posledni vete uvadi jedinou rozumnou vec, ktera tomu ma dodat pocit verohodnosti.
Primarni hashovaci funkce musi byt na strane serveru. To co si napise front-endak nebo uzivatel nainstaluje za plugin pro hashovani hesla pred odeslanim je v dobe SSL predevsim jejich vec. Provozovatel je povinen hlavne zabezpecit to co mu prijde a to co uklada. Pokud utocnik ziska nejakym postranim kanalem, byt treba unikem DB vasim ultra brutal cool hashem vygenerovanym z javascriptu, jak tezke pro nej bude vypnout JS a vlozit do loginu hash, prihlasit se jako admin e-shop a zmenit ceny vsech produktu? Co ma vetsi pravdepodobnost? Ze najde nejakou XSS zranitelnost, ktera opet obejde Vas ultra brutal cool hash v JS a jeste pred jeho ziskanim si vezme plaintext nebo ziska DB ci prolomi sifrovanou komunikaci?

To by sme za chvilku snad vsichni meli podle Vas a ostatnich amateru pouzivat Client-IP nebo X-Forwarded-For hlavicky jako primarni zdroj IP adresy navstevnika pro bezpecnostni restrikce a nebo vubec co si je takhle posilat treba v JSON pres javascript ?

Pro dalsi pomalejsi jedince kteri tomu tady stale nerozumi. Provozovateli webu je uplne jedno co mu poslete on i tak musi brat to co mu dojde jako heslo ne jako hash. Primarni hashovaci funkce tedy musi byt kvuli bezpecnosti na serveru, vse ostatni je benefit pro zakaznika, ktery si toho ani nevsimne, tedy do doby nez si omylem nevypne JS a nezjisti ze se nemuze prihlasit.

Mimochodem u HTTP digest se prvni cast hashe ktera obsahuje uzivatelske jmeno a heslo take uklada zahashovana aby opet nebylo potreba mit heslo ulozene v plaintextu ...

Promiňte, ale přijde mi, že jste si přečetl bezpečnostní poučku "heslo nemá být uloženo v otevřeném tvaru" a katastrofálně ji nepochopil. To, co prosazujete je de-fakto ukládání hesla v otevřeném tvaru, pouze místo něj máte hash. Tedy přesně to, co ta poučka nedoporučuje.

> To se setsakramentsky mýlíte. Provozovatel (nebo třeba útočník na jeho straně) bude velice rád, když mu pošlete heslo v
> otevřeném tvaru, protože ho může zkoušet na dalších systémech. Hash hesla spolu s unikátním názvem serveru mu
> práci podstatně ztíží, protože může maximálně zkoušet hrubou silou lámat jedno heslo po druhém.

To se setsakramentsky mýlíte. Protože provozovatel má pod kontrolou posílanou výzvu, může posílat všem přihlašujícím se stejnou (výzvu) a následně lámat všechny nasbírané hasne najednou, protože budou mít stejný salt.

A že bude zkoušet na dalších systémech moje heslo? Ať si poslouží, mám pro každý web jiné. :-D

Nejbezpečnější systém přihlašování heslem je tedy:

1) Uživatel má pro každý web jiné heslo

2) Klient posílá při přihlášení heslo plaintext, ale zašifrovaným kanálem

3) Server má heslo uložené zahashované s různou solí pro každého uživatele. při přihlášení zahashuje zaslané heslo stejnou solí a porovná.

Jak vidíte, nějaké hashování v prohlížeči v tom vůbec nefiguruje. Proto se také podobné metody moc neujaly - protože nic moc pozitivního nepřináší.

Jen dále dokazujete, že jste to špatně pochopil. Pokud používáte hash hesla jako plaintext heslo (uložený v DB, klient ho pošle a porovná se s DB), je prakticky jedno, že je to hash.

Konkrétně HTTP digest zajišťuje, že výzva bude jednoznačná, doposud jsme ale mluvili obecně.

Heslo si mohu pamatovat, ale nemusím. Kryptografický klíč si zapamatuji těžko. Já si hesla na pár důležitých webů pamatuji a nemám je ani uložené ve správci hesel. Na tu spoustu méně důležitých webů mám náhodně generovaná hesla uložená ve správci. Podstatné je, že je to něco, co mohu udělat sám jako uživatel bez závislosti na majitelích webů.

> „Klient posílá při přihlášení heslo plaintext“ je ten nejnebezpečnější systém přihlašování a neexistuje k němu vůbec žádný důvod.

Děkuji za krásnou ukázku tzv. "důkazu úporným tvrzením" :-) Za předpokladů, které jsem vyjmenoval je to bezpečné slušně.

Ano SCRAM tyhle věci řeší, ale kolik webů to používá? Moc ne Asi jsou všichni hloupí a nerozumí tomu, tak dobře, jako vy :-)

Hadat se s Jirsakemnema cenu. Je to marny, je to marny, je to marny...

L.

Respekt Vam ze to jeste vydrzite. Resit s clovekem, ktery si mysli ze resit hash v JS V PROHLIZECI (aby me nenarkli vyvojari node.js) je bezpecnejsi nez poslat plaintext, navic v JS, ktery napsal sam provozovatel webu je zcela zbytecne.
Podle nej je ocividne jednodussi nabourat SSL komunikaci, nebo cilovy server nez najit XSS zranitelnost nebo vypnout v prohlizeci JS.

Filip Jirska
Mate pravdu, byl jsem uz unaveny a komunikaci s Vami nezvladal, takze se omlouvam. Tim s Vami debatu o Vasem presvedceni pseudo bezpecnosti JS ukoncuji, delejte jak uznate za vhodne a ja doufam ze Vami napsanou WEBOVOU aplikaci nikdy nepotkam.

@Filip Jirsák

Tak to je zjevné: Google, resp. výrobce browseru by si na sebe ušil další pořádný bezpečnostní bič a musel by k tomu provozovat další api se v ším všudy co to obnáší ...
Nicméně původně jsem to pochopil tak že se v js heslo zahashuje se solí, pošle na server a tam ho server zahašuje znova se svou solí a uloží do databáze (analogicky ověřuje uživatele), tedy heslo tak nebo tak neputuje v plaintextu, provozovatel serveru přímo heslo nevidí a v plaintextu ho tedy nikdy neuloží, nebo ne jenom tak, do logu se taky plaintext na serveru nedostane ani tak ... ale to se asi pletu, ne?

A to je prave ono. Puvodne tu byl kec o tom ze se v JS zahashuje heslo a to si server ulozi tak jak mu prijde. Bylo to v navaznosti na to jak resit prechod na jiny hash algoritmus v Databazi webu dale pak klasicke prihlaseni uzivatele. Coz od pocatku resim. Jirsak sem taha vymysli jak by si predstavoval sve vyplody fantazie, ktere nemaji absolutne zadny vyznam kdyz jsou stejne bezpecne jako plaintext, pokud na je na obou stranach stejny autor kodu a hlavne je kod na strane klienta relativne jednoduse ovlivnitelny treti stranou oproti zkompilovanym/u­zavrenym programum kde se postupy jim popsane pouzivaji a kde mimochodem tuto funkcnost uz absolutne vubec nema v moci zkontrolovat.

Nikoli, to „uloží tak, jak mu přijde“, jste teď doplnil vy

Petr M (neregistrovaný) ---.145.broadban­d16.iol.cz

Změna algoritmu přihlášení (= silnější hash) jde udělat i se stávajícím heslem, jenom prostě .js z klientova stroje pošle hashe dva, starým se přihlásí a nový se uloží společně s informací o migraci. Pokud ta DB ještě neutekla a stará podoba bude bezpečně přepsána z /dev/random, není problém.

Boze a ja si myslel ze je ten clovek jenom tvrdohlavej.

Chcete tedy diskutovat o tomto, což je podstata této diskuse

Běž si tu grafománii léčit... už je to zas kritický.

Lol Phirae, kdybych byl zena tak te miluji. :D

@Přezdívka: *

No nevím, tak končí veškreré diskuze (minimálně) s JIrsákem: Co že to kdo tvrdí?

K teto priblble myslence se to snazi stocit neustale Jirsak. Vyse jsem nekolikrat uvedl ze s hashovanim na strane JS nemam problem, pokud se hashuje a to hlavne na strane serveru. Jako autorovi serverove aplikace je mi totiz naprosto jedno co mi prijde, nemuzu to jen tak prdnout do DB. Coz mel prave na mysli autor prvniho komentare protoze se mluvilo o hashovani resp. ulozeni hashe v DB a to jsem mu vycetl, jenom Jirsak si tu vymysli ze to tak auto nemyslel a ze dokonce nic takoveho nerekl i kdyz je snad jediny kdo to pochopil jinak.

Ve zkratce: Je super mit u klienta hash, to co pak dal tvrdim je to ze v pripade JS v prohlizeci je to celkem zbytecna prace, jelikoz jde kod relativne jednoduse resp. jednoduseji nez cokoliv jineho ovlivnit a v ten moment je to stejne bezpecne jako plaintext + z uzivatelu vam to oceni asi tak 1/1000000. Toto ovsem neplati u zkompilovaneho ci jinak uzavreneho klientu kde se kod vpodstate neda ovlivnit(nikoliv tedy skryt) a jediny zpusob jak ziskat plaintext je de facto key-logger. Zde to samozrejme ma velice velky vyznam a vyvojarum se cas vrati bezpecnosti.

Prohlizece maji aktualne implementovane(zkom­pilovane/uzavre­ne) HTTP Basic authentication a ta se da vyvolat i z PHP. Bohuzel zde zase nejde nijak zahashovat heslo a tak vam putuje v plaintextu spolu s loginem zakodovane v Base64. Tudiz je vyhodnejsi udelat si vlastni peknou logon obrazovku, protoze to opet vyjde na stejno.

Prapuvod tedy vseho bylo to ze jsem vytkl hashovani hesel v JS a nasledne prime ulozeni do DB vzhledem k tomu ze o tom byla cela predchozi resp. u ukladani hashe v DB a JS se zminil jen okrajove.

@Filip Jirsák

Tak to se můžete hádat do nekonečna, protože obě varianty mají několik nedostatků a několik výhod. Tam bude záležet co je kdo schopný strávit lépe. Pro obé je podmínka https. Pokud daný request někdo odchytí, tak se stejně přihlásí, jenom se nedozví to heslo. To mu ale asi bude stejně jedno. V podstatě jediný praktický rozdíl je v tom, že sice server neuvidí původní heslo, ale zase je nutno to heslo v klientu vrazit do js, což chápu ledaskdo nestráví a může to být potenciálně dost nebezpečné.
Ale aby prohlížeč zneplatnil údaje by IMO nestačilo, protože by ses neodhlásil vůči dalším možným zařízením.

@Filip Jirsák

Ty nechápeš o čem se diskutuje

> Změna hesla nezmění jeho přístup,

Nezmění. Ale dostaneš heslo zahashované novým (=bezpečnějším) způsobem.

> Změna hesla nedává z pohledu pravděpodobnosti jeho uhodnutí smysl.

Může a nemusí. Na spoustu testovacích registrací mám jedno heslo, co vládne všem. Je to víceméně taky bordel, ale není jedinečný. No a když se rozhodnu, že tuhle registraci budu dál využívat, změním heslo na jedinečné smetí a uložím do správce.

> Změna algoritmu přihlášení (= silnější hash) jde udělat i se stávajícím heslem, jenom prostě .js z klientova stroje pošle hashe dva, starým se přihlásí a nový se uloží společně s informací o migraci.

Jenže tohle ten prasoweb neudělá. Ten tam bude mít nějakej switch dle typu hashe s tím, že přepíšou akorát uložení hesla.

> Obranou je i to, že se klient registruje na dobu určitou (třeba tři roky) a pokud se po tu dobu nepřihlásí, účet je smazán.
> - Stejně tak "preventivní změna hesla", pokud na ni někdo věří, je možná tak, že se nemění heslo, ale sůl ze strany služby.

Opět předpokládá neprasící server. Navíc bez hesla v otevřené podobě není jak to heslo přesolit.

> A v případě incidentu je potřeba změnit heslo (riziko prolomení dat), jindy to nemá smysl.

Nejen v případě incidentu, ale i v případě, že je takový únik pravděpodobný. Předání firemního účtu novému správci, potom, co ten starý odešel. Přihlášení se na veřejném stroji nebo přes veřejnou wifinu. Vrácení firemního stroje do firmy. Změna správce hesel. Nebo třeba i dobrovolná půlroční výměna hesel ze strany uživatele. Sice ano, bezpečnosti to významně neposílí, ale ani to bezpečnosti neublíží, tak proč mu to nedovolit?

"Nezmění. Ale dostaneš heslo zahashované novým (=bezpečnějším) způsobem."

Ne. Pokud původní heslo bylo nesolen MD5 a provozovatel nepřekope web, světe div se, nový heslo bude zase nesolená MD5. A klidně můžeš měnit hesla po pěti minutách tři dny a tři noci.

"Může a nemusí..."

Jde o pravděpodobnost uhodnutí. Tvůj osobní přístup s tím nesouvisí.
Mějme N kombinací, jedna z nich je heslo. Jako uživatel si vyberu jedno z nich, útočník má šanci 1:N, že se trefí.
- Pokud jede útočník sekvenčně, jako obrana stačí počkat, až proskenuje část prostoru a pak vybrat heslo z "hotovýho". Ale předpokládá to, že sleduješ útočníka a že nepoužije část proskenovanýho prostoru znovu.
- Pokud trefuje náhodně, pořád je šance 1:N, že se trefí. Můžu těsně před pokusem o správný heslo ucuknout, ale stejně pravděpodobný je, že nastavíš zrovna heslo, který prubne jako další
- Pokud používá rainbow tables a heslo je v té tabulce, tak neznáš jeho tabulku a neznáš pořadí, v jakým to bude zkoušet. Takže je možnost, že by na tvoje heslo došlo po 3568 pokusech, ale ty mu změnou přihraješ na smeč a snížíš to na 25 pokusů. Nebo naopak, z 20 pokusů to zvedneš na 3577.

Prostě z pohledu pravděpodobnosti je stejná šance, že to změnou zlepším, jako šance, že to zhorším. Takže proč si komplikovat život...

"Navíc bez hesla v otevřené podobě není jak to heslo přesolit."

Technicky tam ta možnost je. Při normálním loginu pošleš sůl, uživatel přidá heslo, .js zahashuje a pošle hash, ten porovnáš s DB.Při přesolení pošleš sůl 2x a klient vrací hash 2x - jednou s původní solí pro přihlášení, druhý jako aktualizaci, kterou si uložíš na příště. Ale nedává to smysl - viz výše. To je spíš řešení pro pověrčivý webaře.

"Sice ano, bezpečnosti to významně neposílí, ale ani to bezpečnosti neublíží, tak proč mu to nedovolit?"
Však ti nikdo ve změně hesla nebrání, nebo snad jo? Jenom říkám, že je hodně zažitá pověra "heslo už není bezpečný, protože je starší než x týdnů". A fakt je to jenom pověra.

> Ne. Pokud původní heslo bylo nesolen MD5 a provozovatel nepřekope web, světe div se, nový heslo bude zase nesolená MD5. A klidně můžeš měnit hesla po pěti minutách tři dny a tři noci.

Tvl, nauč se číst.

> Změna algoritmu přihlášení (= silnější hash) jde udělat i se stávajícím heslem, jenom prostě .js z klientova stroje pošle hashe dva, starým se přihlásí a nový se uloží společně s informací o migraci.

Jenže tohle ten prasoweb neudělá. Ten tam bude mít nějakej switch dle typu hashe s tím, že přepíšou akorát uložení hesla.

Ukládání a hashování nových hesel je přepsané, login není opravený, stará hesla se opět ověřují ve starém formátu. Proti tomuhle tě změna hesla ochrání, neboť nově uložené heslo projde už novou metodou hashování a tedy bude v databázi uložené v novém formátu.

> Jde o pravděpodobnost uhodnutí.

Ano. A útočník pravděpodobně na stejný login/email zkusí heslo, které už mu někde vyšlo. Protože má větší šanci se trefit než se netrefit.

> Však ti nikdo ve změně hesla nebrání, nebo snad jo?

Dnes z 10:24 jsi napsal, cituji doslova: "K čemu potřebuje uživatel změnu hesla?"

"Dnes z 10:24 jsi napsal, cituji doslova: "K čemu potřebuje uživatel změnu hesla?"

UTFG na "řečnická otázka"...

Ta osveta se dela snad uz 15 let. A nic krome server-side se nevyresilo. Mame tu kontroly sily hesla apod. Jedine co je fakt efektivni, jsou PWD manageri, ktere upozorni ze clovek pouziva dve stejne hesla(ulozene) na dvou stejnych sluzbach.

Vyžádaným mailem?

@Filip Jirsák

Aha, takže není rozdíl mezi náhodně z čista jasna příchozím emailem s požadavkem na zadání a změnu hesla a emailem který přijde na základě uživatelovy žádosti o změnu hesla u provozovatele (na webu či jinak)? Jistě že ne ...

@Filip Jirsák

No, já se neptal přímo tebe ale spíš to byla odpověď otázkou - do vlákna. Možná jsem si neuvědomil jak se to zařadí nebo jsem to možná ani moc neřešil protože to je prostě obecně do vlákna. Když chci někomu něco přímo adresovat, tak to tam přímo uvedu. Tedy pardon.

Tak sorry, u pristupu do banky z mobilu se fakt nedivim, tam bych nejradsi zakazal uplne vsechno :-D

A nemoznost zmeny hesla pri prihlasovani certifikatem je od pristupu beznych zakazniku dooost daleko....to ma tak 1% lidi?

Trošku víc. Certifikáty používá třeba Komerční banka.

Akorát KB je chce zabalit. Prý se lidem nelíbí, že musí mít krom hesla a mobilu ještě nějaký soubor... No a pak vyhodí ještě 2FA, protože si někdo furt zapomíná mobil a kvůli důchodcům s Alzahimerem vykopnou ještě heslo... A bude vymalováno.

A navíc jsou v těch otázkách často i osobní údaje - místo narození, jména příbuzných nebo kamarádů,... A další "drobnosti" jako značka auta atd.
Šifruje je někdo? Pokud existuje jiná metoda obnovy hesla, proč tam mají tohle? Pokud jenom tak, že je nic debilnějšího nenapadlo, mají na to souhlas? Jaká je možnost, že toho provozovatel služby využije např. na marketing (má Sopla = vnutíme mu servisní prohlídku u kamaráda)? Atd.

/.well-known/request-user-data
bude taky dělat ten správce hesel?

Za prve co tento link ma spolecneho se zmenou hesla?
Za druhe, vy znate specifikaci, co by se melo pod odkazem nachazet? Pokud vim je to jen navrh a ja bych tipoval, ze to bude odkaz na stranku, kde se uzivatel prihlasi a stahne si svoje data resp. posle o ne zadost, tak jak GDPR narizuje.

Jaka je Vase predstava o cinnost tohoto odkazu?

Má s ní společné to, že BFU si tuto adresu nikdy nedokáže zapamatovat, a má to společné to, že po mně někdo chce abych to implementoval.

Vycházím z informací v článku. Víc si jich dohledávat nebudu, protože nevidím přínos v implementaci takovýchto věcí do webů, které vyvíjím.

A tohle je prave proto ze treba spravci hesel mohou svym uzivatelum nabidnout velice jednoduchy rozcestnik. Nebo tento rozcestnik muze generovat primo prohlizec na zaklade navstivenych webu, nebo to muze byt primo ve vysledcich vyhledavacu (hlavne registrace nebo login). To ze Vy nemate zadne kreativni mysleni neznamena ze to nekdo pouzit nedokaze. BTW je to uplne to same jako security.txt "K cemu bych to delal, kdyz mail muzu mit na webu".

Security.txt?
Čekám, kdy se objeví automatický spear phishing na správce webů.

Asi tak stejne jako se objevuje spam na webmaster@<domena>? Ktery je platny uz par let?
Navic security.txt. nikde nerika ze je zde mail povinnosti. Je zde moznost sem dat URL, kde se chyba da nahlasit.

Neobhajuji to ze je to pod .well-known, obhajuji myslenku toho ze by to nekde melo byt, treba ve vyse zminene site mape.

Ze zkušenosti žádné emaily poslané např. na webmaster@<domena> nikdo nečte.
Takže jo, asi stejně.

Aha. Takže celý tenhle standard je o tom, aby uživatel nemusel chodit do nastavení.
Není to až moc velké mrhání časem vývojářů?