Komentáře k článku

Několik poznámek k heslům

Přihlášení uživatele k webové aplikaci je přece tak snadné: zadá jméno a heslo, odešle a – voila! – je přihlášen. Ale co je za tím? A co by za tím mělo být? Přinesou nové technologie nějaké změny v téhle oblasti? Oprášíme staré známé technologie, nebo vzniknou nové?

Zpět na článek

44 komentářů k článku Několik poznámek k heslům:

  1. František Kučera

    Basic autentizace vs. CRAM

    Ad „Poznámka – neuvažujeme ‚basic‘ autentizaci, která posílá jméno a heslo v otevřeném textu; o takové autentizaci ani neuvažujme jako o bezpečnostním mechanismu!“

    Proč ne? Pokud použijeme HTTPS*, tak je „heslo v čistém tvaru“ zabalené do šifrovaného kanálu a je v bezpečí**. A nešifrovat je hazard tak jako tak a ten CRAM nám už moc nepomůže – klientský JavaScript se stahuje ze serveru, a tudíž místo něj může útočník po HTTP poslat svůj, který heslo zadané uživatelem pošle jen tak (uživatel nic nepozná, protože JS není elektronicky podepsaný, přenosový protokol nešifrujeme a všechno vypadá OK). CRAMem se sice nic nezkazí***, ale spoléhat na něj nelze.

    Ad „‚jméno‘ zapotřebí není, ba naopak – čím míň toho bude server o uživatelích ‚vědět‘, tím nižší pravděpodobnost“

    Souhlas – a kéž by se to tak dělalo… bohužel praxe je taková, že provozovatelé služeb se snaží z uživatelů vytáhnout co možná nejvíc údajů (ať už jde o e-maily a čísla kreditek, spotřebitelské preference, polohu…).

    Ad „HTTPS pomůže“

    Spíš bych řekl: HTTPS je základ. Ono v tom klientském JavaScriptu jde naprogramovat ledasco, výkon a funkcionalita jsou dnes na slušné úrovni. Ale o tom to není – pořád se točíme kolem toho, že je potřeba přenést jakési primární tajemství (otisk veřejného klíče serveru nebo alespoň certifikační autority****, která ho podepsala) nějakým bezpečným kanálem ke klientovi. Pokud tohle nezvládneme, všechno ostatní jsou vlastně jen obskurnosti…

    *) což je podle mého základ, když se mají uživatelé přihlašovat, nebo se přenášejí jakékoli citlivé údaje – nešifrované HTTP by se mělo používat jen pro přenos veřejných údajů, které jsou pro všechny uživatele stejné, a kde taky moc nezáleží na integritě zpráv (tu případně můžeme zajistit pomocí kontrolních součtů, hashů, elektronických podpisů – ale zase potřebujeme nějak bezpečně přenést ty hashe nebo otisky klíčů…)

    **) pokud nevěříme tomuhle, tak už rovnou můžeme zabalit veškeré placení přes PayPal, nakupování v elektronických obchodech, posílání důvěrných mailů atd. Leda pak použít vícefaktorovou­/vícekanálovou autentizaci…

    ***) i když někdy taky může – k přihlášení není potřeba znát původní heslo, ale stačí jeho hash (v tom tvaru, v jakém je uložen v naší DB).

    ****) a nemusí jít jen o HTTPS a SSL CA – platí to pro asymetrickou kryptografii obecně

    1. Martin MalýAutor příspěvku

      Re: Basic autentizace vs. CRAM

      Odpovím na to hlavní téma – HTTPS. Můj pohled je takový, že HTTPS BY MĚL BÝT základ, ale v praxi stále není. Z jakéhokoli důvodu, od sdílených hostingů, které jej nedovolují, po pocit, že „certifikát je drahý“, takže nasadíme buď certifikát, co jsme si sami podepsali, nebo koupíme jeden a nasadíme ho na všechny naše weby. Takže ryzí pragmatismus: když už používáte prosté HTTP, tak ASPOŇ nepoužívejte Basic Auth (nemluvě o URL jmeno:heslo@ser­ver.tld).

      1. Lokutus

        Re: Basic autentizace vs. CRAM

        To je základní rozdíl mezi korporátní nekorporátní sférou. V korporátní sféře je https základ, ve sféře volných služeb ne. :-)

  2. kutilm

    Moderní techniky

    Pěkný článek děkuji.
    Už se těším na pokračování na téma: „Model „přihlášení + session v cookie“ není jediným možným modelem; zkuste využít moderní techniky“ :)

    BTW: Jinak jednoduché hashovací funkce se dají použít, ale je s tím trochu práce: http://php.vrana.cz/opakovane-hasovani.php

  3. pepazdepa

    jak jsou na tom zname hvezdy?

    jak jsou na tom s ukladanim hesel zname hvezdy jako ruzne cms (drupal, joomla…), ruzne frameworky atp? je nejaky, ktery k tomu pristupuje seriozne a naopak nejaky ktery si s tim nelame hlavu? :)

    1. janpoboril

      Re: jak jsou na tom zname hvezdy?

      Drupal solí společným klíčem a pak ješťe něčím dalším unikátním pro každý účet. Jméno a heslo se ale stejně všude posílá POSTem a pokud není zapnuté HTTPS, tak to je stejně odposlechnutelné. Pro Drupal by ale neměl být problém napsat modul, který autentizaci obohatí o v článku zmíněné mechanizmy. Některé standardnější jsou hotové a dostupné ke stažení.

      1. František Kučera

        Re: jak jsou na tom zname hvezdy?

        Ten CRAM modul jsem jednu dobu i používal, ale nemá to valný smysl (už jsem tu psal proč). I na stránkách toho modulu teď radí, ať lidi raději používají SSL.

    1. Martin MalýAutor příspěvku

      Re: bcrypt v php?

      Viz ta poznámka v textu článku: „Více k tématu viz: py-bcrypt, Modern password hashing, How to use bcrypt in PHP, Please use bcrypt to hash your passwords, Bcrypt implementation in JavaScript“ – tam jsou odkazy na bcrypt v PHP, Pythonu, Javascriptu, …

  4. turista

    Re: Několik poznámek k heslům

    Ten zesložitěný=zpo­malený hash je dobrý nápad. Ale pozor. I když ověření bude trvat jen jednu vteřinu a návštěvnost se vám zvýší, může to být např. při 4000 přihlášeních za hodinu docela problém :-)

      1. kutilm

        Re: Několik poznámek k heslům

        To moc nejde, pokud mám v db uložený hash, který se musí počítat dlouho, tak ho dlouho musím ověřovat vždy. Jinak by to nebyla žádná ochrana (ochrana v kontextu článku).

    1. kutilm

      Re: Několik poznámek k heslům

      Tohle by mohli řešit ty „moderní techniky“.

      Ať si ten jednovteřinový hash třeba spočítá každý sám na klientovy a tobě ho pak jen pošle. Zátěž serveru minimální a bezpečnost zůstane zachována.

      1. František Kučera

        Re: Několik poznámek k heslům

        Pak ale pozor na to, že pro přihlášení stačí uživateli/útoč­níkovi znát hash místo hesla v čistém tvaru (takže je to v určitém směru stejné jako mít v databázi nezahashovaná hesla).

      2. Karel

        Re: Několik poznámek k heslům

        A čím se to pak liší of plaintextu? Mám v databázi ten údaj, který čekám po lince. Hashování je o tom, že dostanu po lince jiný údaj než je v databázi a já pak ověřuji, zda použití hashe na to co přišlo vede na to, co je v DB. Pokud víte co je v DB, tak vám to moc nepomůže, protože musíte odhalit co na to vede. Svého času jsme dělali i takovou prasárnu, že byla naše „živá“ databáze součástí balíku zdrojových kódů, a to včetně hashovaných hesel. Nikdo to roky neprolomil. A o tom hashování právě je – i když se dostanete k databázi, stejně se nepřihlásíte, protože nevíte, co od vás server čeká.

        1. kutilm

          Re: Několik poznámek k heslům

          Ale bavíme se tu pořád o významu „zpomaleného hashe“ (viz. komentář od turista). To znamená ochrana proti případu, kdy mi někdo odcizí celou databázi uživatelů a hesel a pomocí Rainbow table se dostane k „originálnímu“ heslu. A na to je jedno zda si ten zpomalený hash počítám na serveru nebo na klientu.

          Tím nepopírám význam dalších technik s kterými se to musí kombinovat (salt, https).

          1. Jakub Vrána

            Re: Několik poznámek k heslům

            Při odcizení databáze se útočník sice nedostane k původnímu heslu (takže ho třeba nemůže použít na jiných serverech), ale získá všechny informace nutné pro přihlášení do naší aplikace.

            1. kutilm

              Re: Několik poznámek k heslům

              Na to pak, ale musím přece použít další techniky. Jako že tento „zpomalený hash“ vypočtený a poslaný z klienta, na serveru proženu jednou dalším saltem a rychlím hashem (který nezatíží server) a to mám pak v db.

              Ano do mého postu jsem to přímo hned nenapsal, ale celé toto vlákno řeší problém výpočtu 4000 tisíc „zpomalených hash“ za hodinu a tohle je dle mého řešení, tohoto dílčího problému. Jak jsem psal: Tím nepopírám význam dalších technik s kterými se to musí kombinovat.

              1. Jakub Vrána

                Re: Několik poznámek k heslům

                Rychlý hash na serveru navíc by tento problém řešil, to je pravda. Počítal by se totiž z dlouhého vstupu (výstupu pomalého hashe), takže by útočník nestihl vyzkoušet všechny možnosti.

            2. FHonza

              Re: Několik poznámek k heslům

              myslím že spíše nezíská. zná sice výsledek mujhash(heslo + salt), ale z toho odvodit heslo prakticky nelze (jasně že „šifrování“ algoritmem je cesta do pekel).

              1. kutilm

                Re: Několik poznámek k heslům

                Za předpokladu, že by se s tím zpomaleným hashem (počítanem na klientovy) nic jiného na serveru nedělalo, tak by ani odvozovat heslo nemusel, poslal by prostě ten hash a to by stačilo.

  5. nikdo

    Timing attack

    Nerozumím té části o „timing attacku“:

    Jednou z vlastností hashování přeci je, že malá změna na vstupu znamená velkou změnu ve výsledném zahashovaném řetězci. Takže sledovat čas potřebný k porovnání dvou hashí je, podle mě, sice zajímavá, ale veskrze neužitečná činnost. Možná snad pro útok typu „uhádnutí hesla“ by to mohlo fungovat, ale určitě ne pro iterativní získávání hodnoty hesla. Nebo mi něco uniká?

    1. Martin MalýAutor příspěvku

      Re: Timing attack

      Tam to není zrovna šťastně formulované, omlouvám se. Ono to s hashem moc nesouvisí, jde spíš o to, že u porovnání řetězců, kdy jeden zadává uživatel a druhý se kontroluje na serveru, lze z časování poznat, jestli se „trefil“ nebo ne, a iterativně „uhodnout“ celý řetězec. Viz ten odkaz v uvedeném odstavci. Nebylo to tedy přímo k hashům, ale připadlo mi to jako zajímavá poznámka k „porovnávání řetězců“ obecně.

    2. kutilm

      Re: Timing attack

      V tom odkazovaném článku je to popsané celkem pěkně. Krátce shrnuto:

      Za předpokladu, že máš v db uložený hash hesla a znáš algoritmus kterým se počítá, můžeš pak na server posílat vlastní hesla a postupně sledovat jak konvertuješ ke správnému heslu.

      např.:
      v db je hash: CW7h

      ty pošleš heslo: kdjflsk jehož hash víš, že je A000 doba porovná cca 0sec.
      ty pošleš heslo: wepurow jehož hash víš, že je B000 doba porovná cca 0sec.
      ty pošleš heslo: sdůkldd jehož hash víš, že je C000 doba porovná cca 1sec. OK
      ty pošleš heslo: dkjsůle jehož hash víš, že je CA00 doba porovná cca 1sec.

      ty pošleš heslo: důjslkj jehož hash víš, že je CW00 doba porovná cca 2sec. OK

      ty pošleš heslo: opioree jehož hash víš, že je CW70 doba porovná cca 3sec. OK

      No a zachvilku jsi tam:) Rozhodně lepší než zkoušet všechny kombinace.

      PS: Znalost nalezení hesla k příslušnému hashy dělá třeba už zmíněná rainbow table, nebo google:)

      1. František Kučera

        Re: Timing attack

        Obávám se, že takhle přesně ten čas nejsi schopný měřit, když komunikuješ se vzdáleným serverem* – tohle se dá využít tak leda když trápíš nějaký HW token a můžeš ho napojit na přesné přístroje a máš ho fyzicky u sebe.

        Navíc ten server může být chráněný nějakým IDS/IPS a po chvilce tě vyhodnotí jako útočníka a odřízne. Také ta aplikace bude dost možná mít nějakou ochranu – např. při každém nezdařeném pokusu o přihlášení, tam přidá nějaký ten sleep(), aby ti to nešlo tak rychle (když bude zdržení pár vteřin, tak je to pro uživatele, který nemůže trefit heslo, ještě přijatelné, ale pro útočníka už nepoužitelné).

        *) mění se zatížení jeho CPU, mění se vytížení sítě, odpovědi jsou náhodně zdržované a to o mnohonásobně více, než je rozdíl při porovnání dvou (různě podobných) řetězců.

        1. kutilm

          Re: Timing attack

          Cituji citaci z citovaného článku:
          „It’s an attack which takes some planning and analysis, but it’s viable.“
          je to delší, ale tohle je důležitý závěr.

          Každopádně souhlasím, že se tomuto útoku dá bránit (jako každému), jen ho musím znát a předpokládat. Zajímavé je, že přidávání konstantního sleep je v tom článku také popsáno a to pouze prodlouží čas útoku, ale nezmaří to podstatu, na kterou se útočí.

          1. Karel

            Re: Timing attack

            Tenhle útok se opravdu používal, ale ne při útoku na vzdálený systém. Při útoku po síti to nefunguje ze tří důvodů:
            1. Latence sítě je vždy o mnoho řádů jinde než doba na kontrolu řetězce.
            2. Program musí nejprve z textu spočítat hash a teprve ten kontroluje – u všech běžně používaných hashových funkcí je čas výpočtu hashe opět řádově někde úplně jinde než porovnání dvou krátkých textů.
            3. Nepracujete v laboratorním prostředí – rozdíl v době doručení paketů je opět řádově jinde a na serveru poběží řada procesů, které se budou prát o zdroje a navzájem se ovlivňovat.
            Uvědomte si, že u dnes běžného HW se pro případy „nesouhlasí první znak“ a „nesouhlasí dvacátý znak“ bavíme o rozdílu nejvýše v desítkách nanosekund. I s naprosto luxusním pingem 1 milisekunda a kontrolou na plain text je zřejmé, že nezměříte nic.

            Jestli ten útok chcete použít, tak ten cíl dopravte co nejblíže, zajistěte laboratorní podmínky a pokuste se ho zpomalit. V HW tokenu se například vyměňovaly krystaly a kondenzátory, protože u taktu 5Hz už opravdu i něco změříte.

            1. biggringo

              Re: Timing attack

              No nevím:

              1. Latence bude plus/minus konstantní, takže ji můžu změřit a odečíst.

              2. Taktéž můžu odečíst.

              3. V tom článku se píše, že i po síti je měřitelné zpoždění s přesností na mikrosekundy.

            2. petík

              Re: Timing attack

              v tom článku se také píše, že je potřeba provést několik tisíc měření na jedno „heslo“ pro zjištění času s dostatečnou přesností – a bylo by nutné měřit v období, kdy je nízká až nulová zátěž serveru. Obecně by pro odvrácení stačil malý náhodný sleep, možná i sleep(0).

  6. kutilm

    Důležitost chráněných dat

    Rád bych sem do diskuze přidal jednu malou úvahu.
    Článek krásně popisuje, jak se dají ukládat uživatelská jména a k nim příslušná hesla. Jak se to dá zabezpečit a jak se na to dá různě útočit. Napadlo mě, ale že tu nikde není zmínka o tom, že je potřeba brát také ohled na to jak důležitá data (včetně hesla samotného) chráníme. Má někdo z vás obrněné vozidlo, které mu převáží jeho peněženku? Nebo kdo má doma bankovní trezor podobný tomu co v ČNB?

    Takže pokud budu navrhovat architekturu zabezpečení internetové bankovnictví, použiju jiné zabezpečení. Pokud administraci e-shopu, tak zase jiné a na moje osobní stránky, klidně nahrávám data přes ftp, kde jde heslo v plaintextu a nijak mě to nebolí.

    Jeden příklad na závěr: Mám webovou admistraci fotek pro malou (tří členou) skupinu lidí. Jednou za rok tam nahraji tak 500-800 fotek a oni je třídí do adresáře A, B a C a já si to pak zas stáhnu. To je vše.
    Jaké tam mám zabezpečení: http + heslo v plaintextu jako basic autentizace + tři hesla natvrdo v kódu.
    A přitom si myslím, že je to dostatečné zabezpečení a nijak víc to ani zabezpečovat nepotřebuji, není totiž důvod.
    Děkuji.

    1. nikdo

      Re: Důležitost chráněných dat

      Máte pravdu, ale článek je, IMHO, psán hlavně pro ty, kdo si myslí (vaším příměrem), že nosí svou peněženku v zamčeném kufříku připoutaném pouty k zápěstí, ale když se na ten kufřík podívají po přečtení blíže, zjistí, že je to jen obyčejná igelitka, navíc ještě dole děravá.

    2. Martin MalýAutor příspěvku

      Re: Důležitost chráněných dat

      Analogie s rozdílem mezi sejfem v bance a domácím zámkem FAB pokulhává. Rozdíl mezi FABkou a sejfem je v ceně, takže tam stojí za to zohlednit majetek, který je tím chráněn. Na webu není rozdíl v nákladech na „plaintext“ heslo a na heslo hashované, takže analogie „je to jen obyčejná oobní stránka, tam není potřeba nic chránit, tak tam dám jen plaintext“ není zcela přesná.

      Nikdo z nás nemá na převoz peněženky obrněný vůz, to by byl overkill. Nikdo z nás taky nemá v administraci osobního webu šest certifikátů a tři autentizační metody včetně zasílání ověřovací SMS. Rozdíl mezi plaintext hesly a hashovanými je podobný rozdílu mezi „mít peněženku v odemčeném autě položenou na sedadle“ a „mít peněženku v autě se zapnutým alarmem, schovanou pod sedačkou“. Tam taky není rozdíl v nákladech na zabezpečení, stačí se jen rozhodnout, že ji schováte a auto zamknete. Totéž u hesel.

      Ale možná jsem jen osobně zaujatý, protože mně připadá přístup „šak co, mám tam jen dvacku, tak co bych to nenechal na sedačce a nezamčené“ trestuhodný; stejně jako přístup „šak co, vždyť je to jen moje stránka“.

      1. kutilm

        Re: Důležitost chráněných dat

        Když jsme u těch analogií, tak já spíše tvrdím, že pokud nechám v autě na sedačce 500kč, tak ano je potřeba zamknout a zapnout alarm. Pokud v autě na sedačce nechám vlastnoručně vyrobenou 500,- (takovou jako jsou ve hrách na sazky a dostihy třeba) tak ty opravdu zamykat nebudu. Chci tím říct, že budu dělat jen takové zabezpečení u něhož náklady na jeho překonání jsou jen malinko větší, než hodnota, kterou může útočník získat pokud ho dokáže překonat.

        Jinak rozdíl v nákladech na plaintext verzus hash jsou opravdu minimální. Nicméně https, o kterém píšeš „HTTPS BY MĚL BÝT základ“, by v mém příkladu byl taky overkill.

        A co se týče tvé poslední poznámky: „šak co, vždyť je to jen moje stránka“.
        Tak co třeba takhle: „šak co, vždyť je to jen moje stránka, přece nemá smysl k ní dělat IPS.“

        1. Martin MalýAutor příspěvku

          Re: Důležitost chráněných dat

          HTTPS není předmětem sporu, jde o nehashovaná hesla. Jaký je důvod místo if (md5(heslo) == „abfde472…“) napsat if (heslo == „syslik77“)? Jen proto, že mi na obsahu „až tak nezáleží“? Otázka je, jak přesně odhadnu hodnotu toho, co útočník může získat…

          Ale popravdě, víc mě v té úvze nadzvedl ten pohrdavý podtón k „nějakému osobnímu webu“. Občas se s tím setkávám v nejrůznějších kombinacích: „Na co SEO, když je to jen takovej obyčejnej web?“, „Na co přístupnost, validita, typografické minimum, … – když je to jen osobní stránka?“ atakdál. Vnitřně se s tím nemohu ztotožnit, je to jako říkat „osobní stránku nemá smysl dělat pořádně“. (Něco jako stavět dórský sloup z vepřovic.) Pokud něco nemá smysl dělat pořádně, tak nemá smysl dělat to vůbec. I proto mi argument „na osobním webu netřeba hashovat hesla“ nesedí – a nejde jen o to, že rozdíl v nákladech je minimální.

          1. kutilm

            Re: Důležitost chráněných dat

            Přesně stejný příklad jsem už do komentáře napsal a nakonec jsem to smazal:), tak to zkusím zrekonstruovat.

            if (md5(heslo) == „abfde472…“) je cca o třicet vteřin nákladnější, musím totiž dohledat md5 pro syslik77. Takže v tom to není. Problém je v dlouhodobé uživatelské podpoře. Pokud mi každý rok ti dva volají, kde ty fotky jsou a jaké je heslo, kouknu do zdrojáků na notebooku a hned mohu diktovat. Pokud by tam byl hash tak nevím a jediným řešením je vymyslet nové heslo (vorvaň88), dohledat md5, po editovat soubor, připojit a nahrát na server.
            Další rok nový telefonát, že v souboru hesla.txt co mají na ploše, mají napsáno heslo syslik77 a že se tam nemohou dostat, co tím?

            Teď přemýšlím jestli bych to nemohl dát rovnou bez hesla na adresu http://www.example.com/tajny-adresar-8e7R/ a bylo by :)

            Jinak se omlouvám pokud jsi si vyložil tu větu o nahrávání dat na osobní stránky přes ftp, jako že tím nějak pohrdám, nikoliv. Chtěl jsem tím jen říct, že na každý projekt je nutné se dívat individuálně a vybírat tomu ekvivalentní nástroje.

          2. kutilm

            Re: Důležitost chráněných dat

            Promiň ještě jsem zapomněl: „Otázka je, jak přesně odhadnu hodnotu toho, co útočník může získat..“

            To není jednoduché ano, ale řádově to stejně vždy musí někdo udělat. Třeba podvědomě a neplánovaně, a ekvivalentně tomu investuje do ochrany.

            Každý soudný jednotlivec, který uploaduje fotky na picasa, tak umí odhadnout zda fotky budou veřejné, nebo pod heslem. Ten kdo má osobní stránky, tak podvědomě vybírá hosting zadarmo a cítí, že to nebude takové jako hosting za 500/měsíčně.
            Každý majitel prosperujícího eshopu je schopen odhadnout, jak citlivé by byli informace o objednávkách pro konkurenci a podle toho zaměstná studenta, nebo firmu. Kamkoliv víš nad eshop je to ještě jednodušší, tam už jsou si manažeři vědomi citlivosti svých dat.

            A ano ne vždy se to povede, ale o tom je život, SONY taky přišlo o data.

            PS: možná bychom tu diskuzi mohli ukončit, věřím že si na 99% rozumíme a kvůli tomu jednomu procentu je škoda plevelit diskuzi. Každopádně děkuji.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3519