Hlavní navigace

Vlákno názorů k článku Jak na tomhle webu změním heslo? Pomocí známé URL pro změnu hesla od Martin Prokš - A jako vedlejší efekt další super nápad, jak...

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 12. 2018 0:46

    Martin Prokš (neregistrovaný)

    A jako vedlejší efekt další super nápad, jak zase o trošičku usnadnit různým crackerům plošnou automatizaci útoků a odchytávání hesel.

  • 10. 12. 2018 1:00

    Uncaught ReferenceError:

    právě z toho důvodu stránka nesmí vracet přímo formulář, ale přesměrování. Schovávat přihlašovací/re­gistrační/rese­tovací formulář by nemělo být bezpečnostním prvkem. I dnes stačí vytvořit databázi url, kde jsou tyhle formuláře a efekt je podobný. Naopak tohle přináší možnost jak uživatelům umožnit rychlejší změnu hesla.

  • 10. 12. 2018 10:24

    Petr M (neregistrovaný)

    K čemu potřebuje uživatel změnu hesla? Pokud je vyžadována, hodí ho to na příslušný formulář, i když to nechce. Pokud jde o únik, dostane odkaz mailem. Jinak změna dává smysl jenom v případě, že někde provalí svou DB hesel...

  • 10. 12. 2018 11:44

    Ravise (neregistrovaný)

    Třeba proto, že některý služby hashujou hesla jako prasata a změna hesla je jediný způsob, jak si to heslo nechat zahashovat bezpečněji.

  • 10. 12. 2018 13:02

    Petr M (neregistrovaný)

    To jsem nějak nepochopil.
    - Pokud někdo hashuje jako prase, tak hashuje jako prase. Změna hesla nezmění jeho přístup, tam pomáhá jenom unikátní heslo pro jeho prasoweb, který nepoužiju jinde. A jeho právní zodpovědnost s flastrem, kterej bude fakt bolet.
    - Změna hesla nedává z pohledu pravděpodobnosti jeho uhodnutí smysl.
    - 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.
    - 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.
    - 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. Zároveň to čistí DB od osobních údajů těch, kdo už dokonce na tu registraci zapomněli, nebo si dokonce dovolili zemřít.
    - A v případě incidentu je potřeba změnit heslo (riziko prolomení dat), jindy to nemá smysl.

  • 10. 12. 2018 14:06

    Přezdívka: * (neregistrovaný)

    .js z klientova stroje pošle hashe dva

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

    Se zbytkem souhlasim.

  • 10. 12. 2018 15:34

    Přezdívka: * (neregistrovaný)

    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.

  • 10. 12. 2018 16:07

    Přezdívka: * (neregistrovaný)

    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.

  • 10. 12. 2018 17:43

    Uncaught ReferenceError:

    za jeden mínus se přiznám. Také se mi nelíbí JS kód na straně klienta, který pracuje s hesly. Hash, který se pošle po sítí, ale pořád u sebe musím považovat za heslo a tedy bcrypt.

  • 10. 12. 2018 21:36

    Přezdívka: * (neregistrovaný)

    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.

  • 11. 12. 2018 7:22

    Petr M (neregistrovaný)

    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.

  • 10. 12. 2018 19:15

    Filip Jirsák

    Koukám, že už jsou lidé tak zmatení úplnou absencí použitelného bezpečného přihlašování v prohlížečích, že už ani nevědí, jak to má správně fungovat. Jako když jsou tak zmatení dlouhým používáním NATu, že považují NAT za přednost.

    Hashování hesla samozřejmě patří na klienta, na serveru je hashování k ničemu. Hashování hesla slouží k tomu, aby bylo možné ověřit znalost hesla, ale aby se zároveň nikdo to heslo nedozvěděl. Nikdo, provozovatele webu nevyjímaje – protože provozovatel webu je to největší nebezpečí. Pokud spoléháte na čestné pionýrské provozovatele webu, že hesla bezpečně hashuje, proč byste mu nevěřili, že hesla sice ukládá v plaintextu, ale má vše fakt dobře zabezpečené a hesla mu nikde neuniknou? A pokud budete tvrdit, že nic nelze zabezpečit tak dobře, aby neexistovalo riziko úniku hesel v otevřené podobě – to máte pravdu, ale to se úplně stejně vztahuje na všechny případy, kdy provozovateli posíláte heslo v otevřené podobě. Ostatně porovnejte si, jak často došlo k úniku hesel z komunikace, a jak často došlo k únikům hesel od provozovatele. Zkrátka pokud chcete mít bezpečné heslo, nesmí ho znát především provozovatel webu.

    Bohužel podpora v prohlížečích pro přihlašování hashovanými hesly je mizerná. Standardizována je akorát metoda HTTP Digest, která používá MD5 a uživatelské rozhraní v prohlížečích je bídné, navíc neexistuje podpora pro odhlášení ani pro nastavení/změnu hesla. Takže jediná reálná možnost, jak hashovat hesla v prohlížeči, je JavaScript. To samozřejmě neznamená, že web nemůže fungovat bez zapnutého JavaScriptu – samozřejmě že může, holt když vám uživatel to heslo nutí, tak si ho na server necháte poslat a (možná) ho zahashujete tam.

    To, že předáte útočníkovi informace o způsobu hashování hesla ničemu nevadí, přece nemáte bezpečnost založenou na security through obscurity. Útočníkovi usnadňujete práci především tím, že dovolíte, aby uživatelovo heslo opustilo prohlížeč. Pokud by prohlížeče byly bezpečné, nedovolily by to především ony samy, protože to je ta největší bezpečnostní díra týkající se hesel.

  • 10. 12. 2018 22:27

    L. (neregistrovaný)

    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.

  • 11. 12. 2018 7:10

    Filip Jirsák

    L.: Útočník, který poslouchá na síti, hash neodposlechne, protože k autentizaci se používá hash výzvy + zahashovaného hesla. Hash hesla by mohl odposlechnout leda při nastavení/změně hesla. Mimochodem, při normálním přihlášení jménem a heslem se heslo posílá v otevřeném tvaru, takže tam ho útočník poslouchající na síti opravdu získat může (pokud je komunikace nešifrovaná). Že se hash dozví majitel serveru ničemu nevadí, ten stejně zná vše, co se může uživatel na webu dozvědět. Podstatné je to, že nezná to heslo v otevřené podobě, takže se nemůže přihlásit na jiný web, kde uživatel používá stejné heslo. Útočník, který se dostane k databázi, je na tom stejně, jako kdyby byla hesla hashovaná až na serveru.

    Pro vaši „variantu s OTP“ nepotřebujete na serveru heslo v plaintextu, místo něj lze právě použít hash. Podívejte se, jak to dělá právě HTTP Digest autentizace.

  • 11. 12. 2018 8:23

    L. (neregistrovaný)

    ... 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.

  • 11. 12. 2018 12:02

    Petr M (neregistrovaný)

    Š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?

  • 11. 12. 2018 12:11

    Filip Jirsák

    Petr M: Kvůli autentizaci se šifrovat nemusí. Šifruje se stejně z jiných důvodů, ale je potřeba počítat s tím, že šifrovaný je jenom komunikační kanál mezi prohlížečem a serverem. Server data z šifrovaného kanálu vybalí a dál pracuje s dešifrovanými daty, takže z pohledu autentizace nestačí spoléhat na šifrování komunikačního kanálu.

    Není nutné vymýšlet nové koncepce přihlašování, existující koncepce (např. SCRAM) pokrývají všechny požadavky, které tady byly zmíněné. Problém není v tom, že by se nevědělo jako na to, problém je v tom, že to není na webu standardizováno a prohlížeče to nepodporují. Např. nepotřebujete časovou značku, stačí, aby součástí výzvy byl kus náhodných dat (nonce).

  • 10. 12. 2018 22:28

    Přezdívka: * (neregistrovaný)

    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 ...

  • 11. 12. 2018 7:36

    Filip Jirsák

    Primarni hashovaci funkce musi byt na strane serveru.
    Nikoli. Hashování slouží k tomu, aby nikdo kromě uživatele neznal heslo v otevřeném tvaru. Nikdo, tedy ani provozovatel webu. Toho jde docílit jedině hashováním na klientovi. Jestli server hashuje hesla totiž jako klient nemáte jak ověřit. Jediná možnost, jak serveru zabránit v chybném nakládání s heslem je to heslo mu vůbec nedávat.

    Provozovatel je povinen hlavne zabezpecit to co mu prijde a to co uklada.
    A pokud to neudělá, tak co? Jak se to jako uživatel vůbec dozvíte, že to provozovatel špatně zabezpečil? Pořád platí, že nejbezpečnější (a jediný spolehlivý) způsob, jak zařídit, aby nikdo neznal vaše heslo, je ten, že to heslo nikdy neopustí prohlížeč.

    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?
    Hashování hesla na klientovi přece nebrání hashování i na serveru. Třeba HTTP Digest s tím nepočítá a obecně s tím nepočítá žádná metoda založená na challenge-response, ale tady se bavíme o implementaci v JS, kde si to každý může udělat, jak chce.

    Provozovateli webu je uplne jedno co mu poslete on i tak musi brat to co mu dojde jako heslo ne jako hash.
    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.

    Primarni hashovaci funkce tedy musi byt kvuli bezpecnosti na serveru, vse ostatni je benefit pro zakaznika
    Jak už jsem vám jednou vysvětlil, aby mělo pro uživatele hashování nějaký smysl, musí být už na straně klienta. Hashování na straně serveru je takový benefit, o kterém uživatel vůbec neví, zda k němu skutečně dochází, jak je kvalitní a zda heslo neuniká ještě před tím, než dojde k hashování.

    omylem nevypne JS a nezjisti ze se nemuze prihlasit
    Vysvětloval jsem vám, že i když se nepoužívají vestavěné prostředky prohlížeče, ale hashuje se JavaScriptem, pořád může mít aplikace fallback, při kterém odešle heslo na server v otevřeném tvaru (tak, jako to dělají dnes prakticky všechny aplikace), a to hashování se udělá až tam (možná). Co na tom nechápete?

    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 ...
    Ano, a zároveň ten hash jména, názvu serveru a hesla je to jediné, co se ohledně hesla potřebuje server od uživatele dozvědět. A to je to podstatné – že server se to heslo nemusí vůbec nikdy dozvědět, tudíž nemá příležitost zacházet s ním špatně.

    Navíc HTTP autentizace autentizuje každý požadavek, takže odpadají všechny problémy s únosem session. Ale to už by se v JavaScriptu realizovalo mnohem hůř.

    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 ?
    Aha, takže místo argumentů podsouvání něčeho, co nikdo netvrdil, a ještě označování za amatéry jenom proto, že toho o bezpečnosti HTTP někdo ví stokrát víc než vy. Jak vidím, o podstatu věci vám vůbec nejde a diskutovat nechcete, takže už se nebudu namáhat.

  • 11. 12. 2018 8:35

    L. (neregistrovaný)

    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áší.

  • 11. 12. 2018 9:16

    Filip Jirsák

    Přijde vám to špatně. Bezpečnostní poučku, ze které vycházím, jsem napsal v druhé větě komentáře, na který reagujete. První věta bylo jedno slovo.

    Doporučuju vám k nastudování alespoň ten HTTP Digest. Dnes už to není žádný zázrak, ale základní principy bezpečného přihlašování byste na tom mohl pochopit. Hashe ve tvaru hash(uživatelské jméno + realm + heslo) provozovatel opravdu nemůže lámat všechny najednou, protože uživatelská jména jsou unikátní.

    Že vy máte pro každý web jiné heslo je hezké, dneska je to jediná možnost, jak se uživatel může chránit, ale poněkud to popírá princip hesel, tedy něčeho, co si uživatel pamatuje. Jistě, poučení uživatelé dnes používají správce hesel, jenže když už mám to heslo někde uložené, můžu tam mít uložený třeba i privátní klíč a přihlašovat se pomocí asymetrické kryptografie. Technologicky je to tedy úplně špatně, jsou to jen rovnáky na vohejbáky.

    „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.

    Jinak když vám vadí, že údaje uložené na serveru lze použít k přihlášení na ten server, můžete použít třeba SCRAM.

  • 11. 12. 2018 9:43

    L. (neregistrovaný)

    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 :-)

  • 11. 12. 2018 11:01

    Petr Neni (neregistrovaný)

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

  • 11. 12. 2018 11:15

    Filip Jirsák

    L.: Nastudujte si nejdřív aspoň ten HTTP Digest, ať se tady neztrapňujete tvrzením, že jsem něco nepochopil, když to nechápete vy… Aspoň na Wikipedii si to přečtěte: Digest access authentication. Vidíte tam někde, že by klient po síti posílal hash hesla uložený v DB? Nevidíte, že? V databázi je uložený HA1, klient pošle to, co je na Wikipedii označené jako response.

    Jako heslo se označovalo to, co si uživatel pamatuje. Když si to uživatel nepamatuje ale má to někde uložené (a většinou chráněné heslem), je to klíč. Že se na webu na bezpečnost kašle, takže si uživatelé musejí vytvářet klíče a používat je místo hesel, to je právě problém webu.

    Když klient posílá při přihlášení heslo v otevřeném tvaru, je to dost nebezpečné. Při každém přihlášení existuje významné riziko, že to heslo unikne. Např. tak, že uživatel je ve skutečnosti na podvodném webu a heslo bude odesláno úplně jinam. Nebo se to heslo u provozovatele webu někde zapíše do logu, nebo do databáze. Těch možností je spousta. Kdyby to alespoň přinášelo nějakou výhodu – ale výhoda tam není vůbec žádná. I když použijete to nejprimitivnější možné zabezpečení a budete při přihlášení přenášet jenom jednoduchý hash hesla, můžete s tím pořád dělat to samé, jako když posíláte heslo v otevřeném tvaru, ale aspoň se nedozvíte to heslo v otevřeném tvaru a nemůžete útočit na jiné účty uživatele, kde možná používá stejné heslo.

    SCRAM weby obvykle nepoužívají, protože není pro web standardizován a prohlížeče ho nepodporují. Když to chcete použít, jediná možnost je JavaScript – což je to, co jste na začátku kritizoval.

    Zabezpečení webu bohužel je řešené velmi hloupě. Na jakékoli bezpečné přihlašování se rezignovalo a používají se webové formuláře, kde se musí řešit únosy session, XSS atd. Aby to fungovalo, uživatelé musí používat na každém webu jiné heslo, takže se do prohlížečů implementují správce hesel, pak je potřeba hesla synchronizovat mezi zařízeními. Protože hesla musí být silná, aby měla smysl, a uživatel jich potřebuje kvůli těm předchozím chybám spoustu – a i taková prkotina, jako aby prohlížeč uměl do registračního formuláře vygenerovat náhodné heslo, je (pokud vím) poprvé implementovaná až ve Vivaldi v druhé polovině roku 2018. Ne, označit současný stav webu v oblasti přihlašování za rozumný fakt nemůžu ani s oběma očima zavřenýma.

  • 11. 12. 2018 11:37

    Přezdívka: * (neregistrovaný)

    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.

  • 11. 12. 2018 11:56

    Filip Jirsák

    Přezdívka: *: Hash z JS v prohlížeči rozhodně není méně bezpečný, než poslat heslo v otevřeném tvaru. O nabourání SSL komunikace jsem nepsal, o XSS zranitelnosti také ne. Jaksi ale zapomínáte na to, že když heslo v otevřeném tvaru pošlete na server, ten server ho také přijme. A je jenom na serveru a jeho správci, co s tím heslem udělá. Vy se stále tváříte, že heslo může zneužít jen útočník. Ale vždyť problém může být i na straně provozovatele webu. Ani nemusí chtít záměrně škodit, prostě jenom udělá chybu – třeba uloží heslo do logu. Nedávno měl takovýto problém Twitter – a obávám se, že na internetu bude existovat pár webů, které jsou na tom z bezpečností hůře, než Twitter. Všechny úniky hesel od provozovatelů byly způsobené tím, že provozovatel hesla nezabezpečil dodatečně – tak mne tu nepřesvědčujte o tom, že zabezpečení na straně provozovatelů je vždy dostatečné. Nikoli, tak to v žádném případě není, a pokud si chce být uživatel jistý, že jeho heslo je v bezpečí, musí se o to postarat sám, a provozovateli tedy heslo vůbec neposílat. Postarat by se o to měl webový prohlížeč.

    Ano, řešení s JavaScriptem poslaným provozovatelem webového serveru není ideální. Ale pořád si ten JavaScript můžu zkontrolovat a ověřit, že opravdu hashuje správně a odesílá jenom ten hash. Když prohlížeč odesílá heslo v otevřeném tvaru, nezkontrolujete na implementaci u provozovatel vůbec nic. Že to dělal špatně se dozvíte až v okamžiku zveřejněného úniku. Takže to řešení s hashováním v JavaScriptu je v nejhorším případě stejně špatné, jako hashování na serveru, ale když uživatel má zájem to zkoumat, může být lepší. Správné by samozřejmě bylo, aby přihlašování, odhlašování a změnu hesla řešil přímo prohlížeč, ale není v silách provozovatele jednoho webu tohle v prohlížečích prosadit. Prosadit by to dokázal třeba Google, ale ten o to z nějakého důvodu nemá zájem.

  • 11. 12. 2018 12:15

    null null (neregistrovaný)

    @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?

  • 11. 12. 2018 13:08

    Přezdívka: * (neregistrovaný)

    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.

  • 11. 12. 2018 14:10

    Filip Jirsák

    Puvodne tu byl kec o tom ze se v JS zahashuje heslo a to si server ulozi tak jak mu prijde.
    Nikoli, to „uloží tak, jak mu přijde“, jste teď doplnil vy, v původním příspěvku to takto explicitně zmíněno nebylo. Ale i když uloží hash tak jak přijde z klienta, pořád to není horší řešení, než kdyby heslo z klienta posílali v otevřeném tvaru a hashovali je až na serveru. Naopak je to lepší řešení, protože když má klient zapnutý JavaScript a z klienta se opravdu pošle jen hash (což není tak těžké zkontrolovat), eliminujete tím všechny možné chyby serveru, kdy se omylem heslo zapíše nebo pošle někam, kam nemá.

    Vy řešíte jen změnu hash algoritmu v databázi. OK. I v tomto případě platí, že zahashovat to už na klientovi není v ničem horší, než hashovat to až na serveru. A také stále platí, že pokud má uživatel zapnutý JavaScript, přináší to výhody – stále ty stejné. Na server heslo v otevřeném tvaru vůbec nedoputuje, takže se nemůže omylem zapsat do logu, někam odeslat ani nic jiného.

    Vaše tvrzení, že je to stejně bezpečné, jako plaintext, není pravdivé, důvody máte napsané dvakrát, jednou v každém předchozím odstavci. Ovlivnění skriptu třetí stranou opět nepřináší žádný nový problém – pokud může útočník ovlivnit skript pro hashování hesla, může ovlivnit i odeslání hesla v otevřeném tvaru.

    Bezpečnost nemůže stát na tom, že je program kompilovaný/u­zavřený –security through obscurity opravdu. nefunguje.

    Pokud máte pocit, že hashování v JS bezpečnost snižuje oproti odeslání hesla v otevřeném tvaru, napište konkrétně, čím tu bezpečnost snižuje.

  • 11. 12. 2018 14:45

    Přezdívka: * (neregistrovaný)

    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.

  • 11. 12. 2018 14:56

    Filip Jirsák

    Přezdívka: *: Ach jo, zase jen další troll. Vytučnil jste hezky celý odstavec, ale to „tak, jak mu přijde“, v té vytučněné části nějak není. Možná je to na vás moc dlouhé, tak si zkuste porovnat tu část týkající se ukládání z původního textu a váš text:

    * původní text: „uloží se“
    * váš text: „uloží tak jak mu přijde“

    Už ten rozdíl vidíte?

    Ale hlavně se zabýváte nepodstatnými detaily. Psal jsem, že na tom nezáleží, zda se ten hash uloží rovnou do databáze, nebo zda se ještě jednou hashuje. Podstatné je to, že odeslání hashe (vytvořeného v JS) z klienta není méně bezpečné, než odeslání hesla v otevřeném tvaru. Tomu jste se ovšem opět vyhnul. Chcete tedy diskutovat o tomto, což je podstata této diskuse, nebo chcete jenom trollit?

  • 11. 12. 2018 15:36

    Lol Phirae (neregistrovaný)

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

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

  • 11. 12. 2018 20:27

    null null (neregistrovaný)

    @Přezdívka: *

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

  • 11. 12. 2018 21:49

    Filip Jirsák

    Nick Sekáč Magor: Podle mne se vede spor o to, jestli je pravdivé tvrzení, že „odesílání hashe odvozeného od hesla v prohlížeči JavaScriptem je nebezpečnější, než (při jinak stejné situaci) odeslání téhož hesla v otevřeném tvaru na server“. Kdo co tvrdí je pouze odvádění pozornosti od tohoto tvrzení.

  • 12. 12. 2018 0:25

    pravdokop

    Nejsem odborník na šifrování ani autentizaci. Kdysi dávno, když jsem jako vývojář začínal, jsem byl nucen napsat basic/digest-přihlašování v Céčku do malého "embeded" zařízení a dodnes na to rád vzpomínám, ikdyž to byla fuška :-).

    Musím říci, že posílat vlastní heslo v plain-tvaru kamkoliv (jakkoliv zabezpečenou linkou) se mi opravdu z principu protiví. Nevidím jediný důvod, proč by moje heslo mělo opouštět moje PC.

    Šikovné zahešování, tak jak je definuje stařičký digest, ničemu neublíží. A já mám JISTOTU, že i kdyby někdo rozšifroval zprávu nebo ovládl server, tak moje heslo prostě NEUVIDÍ! Připadá to opravdu někomu jako zbytečnost?

  • 12. 12. 2018 7:54

    Přezdívka: * (neregistrovaný)

    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.

  • 12. 12. 2018 8:44

    Filip Jirsák

    Vyse jsem nekolikrat uvedl ze s hashovanim na strane JS nemam problem
    To je fajn změna. Celá diskuse začala vaším komentářem, ve kterém nebylo nic jiného, než že s hashováním na straně JS máte nepřekonatelný problém.

    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
    Z klienta vám samozřejmě přijde informace „heslo v otevřeném tvaru je: xyz“ nebo „heslo zahashované algoritmem 1 je: abcd“. Pokud je to varianta 1, zahashujete to heslo a uložíte do databáze. Pokud varianta 2, uložíte do databáze rovnou hash. V čem je problém?

    Pořád píšete o nějakém ovlivnění na straně klienta, ale nikdy jste pořádně nenapsal, co tím vlastně myslíte. Že bude mít uživatel v prohlížeči zlomyslný doplněk, který ten hash před odesláním změní? To je ovšem stejný problém, jako když zlomyslný doplněk před odesláním změní heslo v otevřeném tvaru.

    Že to ocení malé množství uživatelů, to je pravda – zvlášť když i mezi lidmi, kteří se považují za odborníky, se najdou tací, kteří považují za lepší posílat heslo v otevřeném tvaru než posílat hash. Jenže to samé malé množství uživatelů ocení i to, že server hesla vůbec nějak hashuje. Protože většina uživatelů o tom nic neví, používají všude stejná hesla a úniky neřeší. Je na autorech aplikací, aby to udělali správně – proto se po nich chce, aby hashovali alespoň na serveru, když už to prohlížeče pořádně neumí. Ale celý ten princip práce s hesly je o tom, že heslo nemá znát nikdo jiný, než uživatel. Heslo v otevřeném tvaru tedy správně nikdy nemá opustit prohlížeč. Hashování na straně serveru je jen taková obezlička –když už to heslo víme, pokusíme se ho co nejrychleji zpracovat a pak zapomenout. Ale pořád je tam prostor pro chyby. Když heslo zahashujete už v prohlížeči, všechny chyby v práci s heslem v otevřeném tvaru na serveru tím eliminujete. Že to není 100%, protože 0,001 % uživatelů má vypnutá JavaScript? Fajn, tak případná chyba na serveru ovlivní jenom 0,001 % uživatelů. To je perfektní výsledek.

    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.
    Prohlížeče mají aktuálně (mnoho let) implementovanou i autentizaci HTTP Digest, implementace je stejně hloupá, jako implementace HTTP Basic. O HTTP Basic vůbec nemá smysl ve vztahu k webovému prohlížeči uvažovat. Přičemž HTTP Digest umožňuje mít v databázi uložený jen hash. Akorát je to MD5, takže pokud má uživatel slabé heslo, půjde rozlousknout.

    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.
    Přičemž hashování hesel v JS už jste odvolal, takže zbývá to uložení hashů vzniklých v JS přímo do DB – a k tomu jste ještě žádný důvod, proč by to bylo špatně, nenapsal.

  • 11. 12. 2018 23:52

    pravdokop

    Protože jsem na to právě nedávno v praxi narazil, tak se přidám jednoduchou otázkou: Proč za ty spousty let někdo nepřidal do HTTP standard pro odhlášení metodami basic/digest?

  • 12. 12. 2018 7:10

    Filip Jirsák

    To je takový začarovaný kruh. Přihlášení pomocí HTTP autentizace se v prohlížečích prakticky nepoužívá, mimo jiné i proto, že neexistuje rozumný způsob, jak se odhlásit. A prohlížeče tím pádem ty funkce zase nevylepšují, protože to přece nikdo nepoužívá. Přitom pro odhlášení by teoreticky ani nebylo nutné rozšiřovat standard – pokud server nepotřebuje o odhlášení vědět, stačilo by, aby prohlížeč zneplatnil přihlašovací údaje.

  • 12. 12. 2018 7:48

    null null (neregistrovaný)

    @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.

  • 10. 12. 2018 16:50

    Ravise (neregistrovaný)

    > 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?

  • 10. 12. 2018 21:35

    Petr M (neregistrovaný)

    "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.

  • 10. 12. 2018 23:25

    Ravise (neregistrovaný)

    > 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?"

  • 11. 12. 2018 7:26

    Petr M (neregistrovaný)

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

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

  • 10. 12. 2018 12:02

    Přezdívka: * (neregistrovaný)

    To jste opravdu tak kratkozraky?

    Jsou uzivatele, kteri
    • meni sve hesla v urcitych intervalech
    • pouzivaji stejna hesla u vice sluzeb, meni tedy hesla pokud dojde u jedne z nich k uniku
    • aktualizuji sve hesla, protoze jej vymysleli pred 20ti roky a jiz nejsou dostatecne silna
    • jsou pod utokem a nevim jestli nekdo jejich hesla neuhadl.
    • meli ulozena hesla v prohlizeci na pracovnim pocitaci(a ve firme uz skoncili)
    • nekomu byli nuceni rict sve heslo a nemel moznost jej docasne zmenit
    • omylem vypustili sve heslo verejne(viz. hesla k DB na githubu apod.)
    • maji jakykoliv jiny duvod zmenit heslo
  • 10. 12. 2018 13:13

    Petr M (neregistrovaný)

    Jenom říkám, že heslo nemá smysl měnit, když nedojde k jeho kompromitaci (a tem počítám i konec ve firmě). Heslo je navíc tak silný, jak se k tomu postaví služba, která s ním pracuje.

    Spíš než usnadňovat změnu hesla by se měli starat o osvětu lidí, jak se správně registrovat a přihlašovat.

  • 10. 12. 2018 14:03

    Přezdívka: * (neregistrovaný)

    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.

  • 13. 12. 2018 20:55

    jinej muf (neregistrovaný)

    "dostane odkaz mailem"
    a to je myšleno vážně nebo sarkasticky?

    Oni se najdou uživatelé, kteří nejsou blbí a vědí, že klikat na jakékoliv odkazy v mailu je potenciální riziko a že odkaz na nastavení hesla v mailu je zjevný pokus o phishing, protože žádný soudný provozovatel webu nebude posílat odkaz na změnu hesla tím nejzastaralejším a nejnezabezpeče­nějším protokolem, jakým SMTP bezesporu je...

  • 13. 12. 2018 21:41

    Filip Jirsák

    Oni se najdou uživatelé, kteří nejsou blbí a vědí, že klikat na jakékoliv odkazy v mailu je potenciální riziko a že odkaz na nastavení hesla v mailu je zjevný pokus o phishing, protože žádný soudný provozovatel webu nebude posílat odkaz na změnu hesla tím nejzastaralejším a nejnezabezpeče­nějším protokolem, jakým SMTP bezesporu je...
    Jakým způsobem tedy měníte heslo v případě jeho zapomenutí – třeba u e-shopů, diskusních fór, poskytovatelů služeb atd.?

  • 14. 12. 2018 8:42

    null null (neregistrovaný)

    @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 ...

  • 14. 12. 2018 9:23

    Filip Jirsák

    Nick Sekáč Magor: Proč se na to ptáte mne? Já jsem se pouze ptal uživatele jinej muf, jaké způsoby pro změnu hesla používá, když jakýkoli odkaz na změnu hesla v e-mailu je zjevný pokus o phishing a žádný soudný provozovatel webu podle něj neposílá odkaz na změnu hesla protokolem SMTP. Takže se ptejte jiného mufa, ne mně…

  • 14. 12. 2018 11:33

    null null (neregistrovaný)

    @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.

  • 10. 12. 2018 11:24

    Martin Prokš (neregistrovaný)

    Prosím neplést bezpečnost konkrétní služby/aplikace (tam souhlasím že security by obscurity je blbost) se snadností automatizace masivních útoků, kde security by obscurdity navíc doplněné občasnou změnou je naopak dobrou překážkou.

    Je uživatelsky strašně jednoduché předhodit červu seznam domén a on si již sám najde ty krásně předpřipravené přesměrovací linky přímo na platné konkrétní formuláře.

    Proti významně složitější situaci, kdy se na dané doméně ještě musí najít ten konkrétní link který je pokaždý jiný a občas třeba i mění svou adresu v čase, takže se rozbíjí automatizace útoku. Zatímco člověk to najde snadno. Ano je to uživatelsky méně pohodlné, uživatel na tu doménu musí jít a koukat kde je záložka "login change / password change / account settings / user setting" nebo ještě v národních jazycích. Přirovnal bych to k myšlence udělat emailovou adresu pro důležitá sdělení globálního významu: everyone@whole-internet.org. Stejná pitomost.

  • 10. 12. 2018 12:12

    MarSik (neregistrovaný)

    Myslíte si, že najít strojově odkaz na login a forgot your password v HTML je nějak složité? I ten formulář se potom různě liší, takže útočník se automatizaci stejně nevyhne a jeden krok navíc ho rozhodně nezastaví.

    Navíc, dnes se tohle ručně stejně nedělá. Útočník si tu databázi formulářů prostě koupí.