Vlákno názorů k článku
Jabbim.cz byla ukradena uživatelská hesla od JmJ - jako dlouhodoby uzivatel jabbimu ted premyslim, jestli se...

A tak... a tak určitě! :-D

Tohle prostě neberu. Tvořím vlastní redakční systém i pro "tupé" uživatele. Nemůžete jim mít za zlé, že používají jedno heslo na více místech. Ano, je to nebezpečné, ale nuťte je znát 100 hesel. ;) Já neříkám, že hash je jediná správná metoda, ale říkám, že ukládat hesla jako plaintext je naprostá prasárna. Žádný, naprosto žádný důvod neobstojí, abych ukládal hesla jako plaintext. Svalovat vše na jiné je fajn věc. Já ale říkám - pokusit se zvýšit bezpečnost autentifikace by měly všechny strany. To je jako s formáty, které si s lidmi vyměnuji - já se umím přizpůsobit. Neřeknu někomu, posílej mi jen tar.gz, protože jsem linux fan. Pošleš rar, zip? No problemo. Já se přizpůsobím.

Dle mého je pěkná myšlenka OpenID a MojeID.

> Žádný, naprosto žádný důvod neobstojí, abych ukládal hesla jako plaintext.

Duvod je vysvetleny v dokumentaci:

the server needs to know the user password to support the most secure authentication mechanisms.

https://www.ejabberd.im/plaintext-passwords-db

Jestli to jako duvod obstoji pred tebou, to myslim svet zas az tak netrapi :)

> Prosody umí SCRAM a TLS bez problému

Co si zkusit precist prvni vetu z toho odkazu?

Všimněte si, že jsem napsal, že v případě webu je to chyba především autorů webových prohlížečů a specifikací - ti mají v tomhle případě snadnou možnost udělat to tak, aby uživatelé, kteří prostě jen chtějí používat web, to dělali bezpečně.
Vedle toho jsem pak komentoval ty komentující, kteří musí hned rychle přispěchat s komentářem, že hashování hesel spasí svět a kdo nehashuje je ďábel. Tyhle také řadíte k "tupým uživatelům"? A pokud to tupí uživatelé nejsou a o hashování hesel vědí víc, než že to jenom někde zaslechli - jak se jich to pak týká? Vždyť z té uniklé databáze je jejich heslo ten jediný údaj o nich, který pro nikoho není zajímavý.

Žádný, naprosto žádný důvod neobstojí, abych ukládal hesla jako plaintext.
To je zajímavé, jak to tady kde kdo opakuje, že je to prostě špatně, ale všichni se úzkostlivě vyhýbají odůvodnění, proč by to tak mělo být. Zatím jsem nějaký "důvod" uvedl jen já.
Jen tak mimochodem - máte protokol, který implementuje přihlašování tak, že server pošle klientovy výzvu, klient spojí výzvu s heslem a spojená data zahashuje (třeba SHA-2). Hash posle na server. Jak implementujete ověření uživatele na serveru, když nebudete znát jeho heslo v otevřeném tvaru?

Já ale říkám - pokusit se zvýšit bezpečnost autentifikace by měly všechny strany. To je jako s formáty, které si s lidmi vyměnuji - já se umím přizpůsobit.
Ne, s bezpečností je to přesně opačně. Když jako klient pošlete heslo serveru, ať si s ním dělá, co chce, rozhodně to není bezpečné. Bezpečné je jenom to, když serveru heslo vůbec nikdy nepošlete - pak nemá co zkazit.

Konkrétně? Dokončete následující větu citací ze zprávičky: "Uživatelé musí poslat serveru heslo v otevřeném tvaru, a server musí heslo uložit do databáze zahashované, protože..." Pro jistotu rovnou upozorňuju, že "k datům z databáze může získat přístup někdo nepovolaný" důvodem není, například proto, že i k databázi zahashovaných hesel může získat přístup někdo nepovolaný.

Než odpovíte na nějaký komentář, dočtěte jej až do konce. Pak se vám nebude stávat to, co se vám stalo právě teď - že jste potvrdil, že ukládání hashovaných hesel je úplně stejně nebezpečné, jako ukládání hesel v otevřeném tvaru. Protože i u hashovaných hesel platí, že "k datům z databáze může získat přístup někdo nepovolaný".

Stejně tak existuje možnost úniku hashů z databáze. Buď je špatně ten únik, takže je stejně nebezpečné ukládat hashovaná hesla jako hesla v otevřeném tvaru. Nebo je nebezpečné něco jiného, a pak odpověď "protože existuje možnost úniku dat" není správnou odpovědí na otázku "proč hesla neukládat v otevřeném tvaru ale jako hash".
Co tím dokazuju? Pravdivost svého předchozího tvrzení, že u většiny těch, kteří se neváhají pod každou zprávičkou pohoršovat nad tím, jak může někdo ukládat nehashovaná hesla, vůbec netuší, o čem je řeč, a tím pádem ani nedokáže napsat relevantní důvod, proč je lepší hesla ukládat zahashovaná. Zatím jsem jediný relevantní důvod uvedl já,a to je ten, že pokud někdo používá stejné heslo pro více služeb, a dojde k prozrazení jeho hesla spolu s identitou, kterou je možné použít k přihlášení k jiným službám (typicky e-mailová adresa), získá útočník uživatelův přístup i k těm jiným službám. Podmínkou toho, aby hashování bylo účinné, je pak to, že se používá sůl, aby nebylo možné použít duhové tabulky. Samozřejmě pokud útočník získá i sůl, může stejně vést útok na konkrétního uživatele (pokud má slabé heslo). A provozovatel může na účty uživatele u jiných služeb zaútočit vždycky, protože mu uživatel své heslo v otevřeném tvaru typicky dává opakovaně při každém přihlášení.

> odpověď "protože existuje možnost úniku dat" není správnou odpovědí na otázku "proč hesla neukládat v otevřeném tvaru ale jako hash".

Ale ona to JE správná odpověď.

Protože existuje možnost úniku dat, tak je velmi nerozumné ukládat hesla v otevřeném tvaru. Kdo tu databázi získá, má X hesel k okamžitému použití.

Pokud je uložím jako hash, nemá útočník X hesel k okamžitému použití, ale hromadu práce před sebou, která může a nemusí vést k použitelným heslům.

Pokud to je správná odpověď, proč ji pak ještě doplňujete? Navíc „má X hesel k okamžitému použití“, to taky ničemu nevadí. Na webu existuje spousta generátorů hesel, tam si klidně naklikáte X nebo 10×X hesel k okamžitému použití. Vy jste možná myslel, že má útočník spoustu hesel spolu s přihlašovacím jménem, a že je velice pravděpodobné, že uživatelé stejné přihlašovací údaje používají i jinde. No jo, ale to je věc, kterou má každý hlasatel „nehashovaná hesla jsou zlo“ vypálit okamžitě, ne že je potřeba to z každého tahat jak z chlupaté deky, napovídat a stejně to pak nenapíše celé.
Akorát mne utvrzujete v domněnce, že tihle hlasatelé mají jakousi mlhavou představu, že „nehashovaná hesla jsou zlo“, a když se jich zeptám na důvod, tak to teprve musí pracně začít vymýšlet.

Já ji nedoplňuji, já ji vysvětluji, abyste to pochopil i vy.

X hesel k okamžitému použití = na 90 % fungují i jinde. X hesel z generátoru = na 99 % nefungují nikde.

Že jsem myslel to, že je k nim znám login/email, je pravda, předpokládal jsem, že to každému čtenáři přece musí být jisté.

Já vidím, že vás baví slovíčkařit, a pokud vám někdo neodpoví přesně vše, včetně všech okrajových případů, tak má u vás za pět. Tak přeji příjemnou zábavu, ale mě tohle nebaví.

Nikdo hnedka neodpoví kompletně, protože se předpokládá, že čtenář má nějakou přirozenou inteligenci a to, co vynechal, si umí domyslet.

Lepší je podlě mě, když každý ví, že nehashovaná hesla jsou zlo, i když úplně přesně neví proč, než aby každý používal plaintext hesla, protože neumí vymyslet důvod, proč by to měl dělat jinak.

To je přesně to, o čem píšu. Máte o tom jenom mlhavou představu, vymlouváte se na to, že předpoklady jsou přece jasné a jsou to jenom okrajové případy – a když pak ty předpoklady a okrajové případy máte pořádně popsat, tak to nesvedete.
Jak můžete očekávat, že si čtenář něco domyslí, když si to nejste schopen domyslet ani vy sám? Když se zeptám na to, jaké jsou k něčemu důvody, asi nechci slyšet odpověď, že si to mám domyslet.
Když někdo neví, proti čemu a jak brání hashovaná hesla, je úplně jedno, zda hesla bude ukládat hashovaná nebo v otevřeném tvaru, protože okolo naseká takových bezpečnostních chyb, že fakt, že měl záměr hesla ukládat hashovaná, ničemu nepomůže (protože dá útočníkovi spoustu jiných možností, jak ta hesla v otevřeném tvaru zjistit).

Já to vím. Nemám chuť tady vše opisovat.

Z vás mám pocit, že je úplně zbytečné používat hashovaná hesla, protože například někdo může provést MITM attack a hesla odposlechnout.

Jistě, důvodů, proč to nenapsat, je spousta. Každý si domyslí, nemám chuť… Do mé představy vyznavače víry v hashovaná hesla to krásně zapadá.
Ten pocit máte špatný. Já netvrdím, že hashování hesel někdy nemůže být užitečné. Ale tvrdím, že pokud někdo o bezpečnosti ví jenom to, že „hesla musí být v databázi vždy hashovaná, protože proto“, stejně mu to nijak nepomůže.

Hesla je potřeba v databázi skladovat téměř vždy osolená a prohnaná kdf. Pokud použití nejakého komunikačního protokolu za systémem skladujícím ta hesla požaduje hesla v plaintextu... tak je něco hodně blbě v návrhu celého toho systému.

Tohle není jediné, co by měl člověk znát. Ale je to bod nula.

Komplexně mu to nepomůže, ale už je o level dál, než kdyby je tam měl v plaintextu…

Někdy může být náhodou o level dál (i když vzhledem k tomu, že se k těmhle věrozvěstům ještě nedonesla informace o solení hashů, musí to být opravdu velká náhoda). Někdy se zase spolehne na to, že má hesla hashovaná, a na ostatní bezpečnost bude kašlat už úplně, takže je na tom naopak ještě o level hůř. V průměru to vyjde tak nějak nastejno.

Pouzivej v aute pasy. Kdyz se te nekdo zepta, tak mu rekni, at pouziva pasy. Ukaz mu, jak je spravne nastavit.
Nemedituj o tom, jestli kvuli tomu neskonci s falesnym pocitem bezpeci s mytim rukou pred jidlem.

"Komplexně mu to nepomůže, ale už je o level dál, než kdyby je tam měl v plaintextu…"

Dobře, evidentně máte pojetí o tom, co je víc bezpečné a co méně. Fajn.

Vysvětlete mi prosím ale jednu věc.

Proč se rovnou nezavede to nejlepší aktuálně dostupné řešení?

Každá diskuse na téma plain hesel má pokaždé stejný průběh:

"Ééééé, to jsou lamy, mají hesla v plainu, bééé looseři. Hash, hash, hash."

Potom někdo upozorní na to, že samotný hash nestačí. Že se musí solit. Že ani salt nestačí. Že se musí bránit proti MITM. Že ani to nestačí. A navrhne řešení, které je v dané době to nejlepší možné. Třeba asymetrickou kryptografii.

Potom nastane další kolo:

Néééééé, salt néé, digesty néééé, scram nééé, klííče néééé. Stačí hash. Stačí prostě hash. Tečka.

Mezi pouhou haší a plainem je ve skutečnosti mnohem menší rozdíl, než si myslíte. Aby hash vůbec k něčemu byla, musí se k tomu přihodit hromada dalších věcí, která znamená v zásadě kompletní změnu protokolu. Které ale ti, kteří křičí: hash, hash, houfně odmítají.

Takže ve výsledku se to udělá tak, že se tam nasadí prostě fce (jakákoliv) jen proto, aby někdo v db neviděl svoje nbusr123, ale nějakou změť znaků.

Nikdo neřeší to, že se to heslo dál posílá internetem (často po nešifrovaném kanále, a když šifrovaném, tak stejně nikdo neřeší možnost MITM), nikdo neřeší to, že na tom serveru to heslo putuje hromadou kódu a útočník kamkoliv může dát sniffer. Nikdo neřeší ani kvalitu hashovací fce samotné. Lidem, kteří nejvíc křičí hash, loooseři, amatérismus, potom stačí zalepit ústa v podstatě i funkcí rot13. Jen tam hlavně nesmí vidět to svoje heslo.

A že by snad měli používat pro každou službu unikátní hesla? No to už vůbec.

Tohle mi tedy vysvětlete. :-)

Já říkám, pojďme to rovnou udělat pořádně. Nepřidávejme jeden krok, který vůbec nic nevyřeší. To je jen lakování na růžovo, ale pod tím lakem to pořád hnije.

Mám pro vás jeden strašně nebezpečný web: https://www.random.org/passwords/. Máte tam X hesel k okamžitému použití.
Potřebuje to například jistý Seti, který je doteď nedokázal dát dohromady. Já se na ty důvody neptám proto, že bych je neznal. Ptám se na ně proto, že si myslím, že je neznáte vy. Mohl jste to velice snadno vyvrátit, ale zatím se tomu úspěšně vyhýbáte.

Zkus rozlisit mezi "okamzite pouziti jako heslo pro sebe" a "okamzite pouziti k pokusu pwnout dalsi ucty toho sameho uzivatele" (+jako bonus moznost pridat do seznamu znamych hesel pro slovnikove utoky).

Já to rozlišuju, jak si můžete všimnout v mém předchozím komentáři. Nerozlišuje to Seti a původně to nerozlišil ani Michal Wiglasz.

Vsak jsi ale zautocil na tu nejdementnejsi moznou interpretaci jejich tvrzeni, prestoze s trochou vstricnosti existovala (nejspise i zamyslena) varianta, ktera davala velmi dobry smysl.

S trochou vstřícnosti se i „to co je za jebnutost ukladat hesla ako plaintext?“ dá vykládat tak, že dotyčný přesně ví, v čem je ukládání hashů lepší, jak se to má udělat, aby to k něčemu bylo, má přehled o autentizačních metodách podporovaných Jabberem i webem a ví, jaká je jejich podpora na serverech i klientech.
Jenže já se obávám, že je to celé založené na tom „vždyť to přeci všichni tak nějak tušíme, takže nepotřebujeme zabíhat do detailů, přesně to formulovat, vyslovovat předpoklady“. Protože když se na ty podrobnosti zeptám, tak se je nedozvím, místo toho se pořád dokola opakuje ono „to ví každý“, „to není potřeba popisovat do detailu“ atd. Kdyby to bylo jednou dvakrát, dobře, opravdu to považují za tak samozřejmé. Ale co si o tom mám myslet, když je to pokaždé, ani jednou nedokážou pojmenovat, v čem je problém a jaké jsou předpoklady?
Já nepochybuji o tom, že si Seti i Michal Wiglasz myslí, že vědí, proč je to špatně a jaké jsou tam předpoklady. Ale kdybych já byl třikrát usvědčen z toho, že jsem místo aspoň trochu rozumného popisu plácnul obecný nesmysl, sám bych se snažil to konečně zformulovat pořádně, abych sám sebe ujistil, že to opravdu vím a že to není jen pocit, že tak nějak přibližně by to asi mohlo být.

Když si hrajete na učitele, který zkouší žáky (nás) ze znalosti ukládání hesel, nechcete nám tady rovnou napsat výklad, jak to teda je? Vy jste tady taky nic nezformuloval pořádně, jenom si dokola vybíráte nejdementnější interpretaci všech tvrzení, na které se nám snažíte ukázat, že nic nevíme.

Mám ten výklad psát ještě potřetí, nebo stačí, že jsme ho už napsal dvakrát?
Proč tedy těm dementním interpretacím nepředejdete a nenapíšete relevantní důvody, proč hesla hashovat, a základní předpoklady, za kterých to hashování funguje a jaké problémy řeší?

Protože i kdybych to vypsal všechno, tak se chytnete prvního slůvka, které lze vyložit různě - a vyložíte si ho tím způsobem, jakým to nebylo myšleno. Kašlu na vás, jdu si radši otevřít flašku a udělat si hezký večer.

Výmluvy, výmluvy, výmluvy.

> Výmluvy, výmluvy, výmluvy

Jo, tych ste tu ukazal naozaj hodne. Precital som cele vlakno a napada ma jedine rozumne vysvetlenie toho, co tu predvadzate:

To jelito, co malo na svedomi "bezpecnost" na Jabbim ste bol Vy. Dufam, len za Vam pri vyhadzove zbytocne neotvarali dvere.

Vám unikla hesla na internet (píšete v první osobě) a já se ztrapňuju?

Ukladat hesla v hashi je sice takova jasna poucka, kterou lide omilaji dokola, ale nejak to asi muselo vzniknout, ze ? A vzniklo to presne kvuli temhle pripadum, kdy se nekdo dostane k databazi.
A to je právě ten problém. Místo aby se řešila bezpečnost, implementují se poučky. Moc bych se nedivil, kdyby bezpečnost na uveden serveru zajišťovaly jiné poučky, např. že SSH zásadně musí běžet na jiném portu, než 22, musí být zakázáno přímé přihlášení roota, a musí být nasazen fail2ban. Ony ty poučky většinou bezpečnost přímo nezhorší, nanejvýš zbytečně znepříjemňují život administrátorům. Problém je, že ti, kteří aplikují poučky, tomu zpravidla moc nerozumí, a nechají se ukolébat pocit, že aplikací poučky udělali pro bezpečnost vše. Ostatně je to vidět i na téhle diskusi, kdy obhájci poučky "nepřemýšlet a hashovat" nebyli za celou dobu schopni dát dohromady nějaké smysluplné důvody, proč to dělat ("protože proto" není smysluplný důvod).

A proc by mel klient spojit vyzvu z heslem a ne s hashi hesla + saltu ?
Protože je to tak nadefinované v protokolu. Pokud si všechny klienty pro své aplikace píšete sám, tak si samozřejmě autentizaci můžete napsat, jak chcete. Ale pokud budete provozovat veřejný server, ke kterému se budou připojovat různí klienti, asi budete muset podporovat ty samé autentizační mechanismy, které podporují klienti. Pokud bude autentizační protokol fungovat tak, že klient spojí výzvu s heslem a to zahashuje, těžko budete přesvědčovat uživatele, ať si přeprogramují klienta, aby to dělal jinak. A že takhle navržený autentizační protokol by byl pěkně hloupý? No ano, byl, ale uvědomte si, že že nejpoužívanější autentizační protokol na internetu je přihlašování jménem a heslem, která se posílají v otevřeném tvaru nešifrovaným kanálem.

Strašně bullshituješ. Ukládat hesla zahashovaná je výchozí stav. Počet případů, kdy je dobrý nápad ukládat hesla v plaintextu se limitně blíží nule.

Pokud se najde zatraceně dobrej důvod je ukládat nezahashovaná, tak se o tom může přemýšlet a případně to tak udělat. Ale měla by to být až úplně poslední možnost, když všechno ostatní selže a na ukládání v plaintextu závisí lidské životy, a lidé budou dostávat rakovinu když budeš hashovat hesla. Pak možná.

Pro mne je tedy "výchozí stav" to, že se nikdo nepovolaný nedostane k datům z databáze, a že se server heslo uživatele vůbec nikdy nedozví (takže ho logicky ani nemůže uložit do databáze). Poskytování hesla v otevřeném tvaru serveru a uložení jeho hashe je pokus o slabou záplatu toho, že neumím zajistit ty první dvě vlastnosti. A k tomu, aby to hashování k něčemu bylo, je potřeba splnit spoustu předpokladů.
Jinak toho, čemu má zabránit hashování hesel, lze docílit i jinými způsoby. Třeba šifrováním hesel, uložením hesel mimo dosah webové aplikace (ta jen předá heslo získané od uživatele jiné komponentě k ověření), nebo uložením hesla do databáze pod jiným uživatelským účtem a alespoň kód pracující pod tímto účtem napsat tak, aby nebyl náchylný k SQL injection.

Ano.

Tu díru tam většinou zanese sám. Díru v SSL zanesl někdo jiný, za to fakt nemůže.

Jenomže to použití tls je z docela dobrých důvodů best practise a chyba, kdy kvůli tomu tekla data ven byla dost výjimečná. Stát se o může, ale to se může stát i pád letadla na datacentrum.
Napsat si do kódu SQL injection nebo si k tomu najmout Inda je běžné, až to bolí. A neochránit hesla slušným uložením do DB proto kritiku schytá - kdo to udělal, ignoroval posledních X let vývoje v bezpečnosti.

Ti, co měli problém s heartbleedem kritizováni nebyli, protože v rámci svých možností chybu neudělali. (Kritika se potom snesla na ty, co pomalu updatovali, ale to už je jiný příběh.)

>Jj, za poslední rok bylo v SSL a openssl nalezeno asi jenom 50 chyb.

Jenomze z tech chyb byl heartbleed jenom jeden.

> Není, není, není. Můžeš použít prepared statements, případně programovací jazyk, který ti to prostě jinak nedovolí.

Hele, ja vim, jak to udelat. Coz nemeni nic na tom, ze *inejctions jsou bezne, az to boli...

Připojení je typicky šifrované? Kéž by.

"Použití SSL je IMHO v pořádku."

Vážně? Víte o tom, že SSL dneska už nemá žádnou bezpečnou variantu? SSLv1 se nikdy veřejně nepoužívala (protože se našly problémy ještě před uveřejněním), rovnou vyšla SSLv2, ve které se v zápětí rok poté našly takové problémy, že se vydala SSLv3, u které se objevila zranitelnost letos? Žádná další verze SSL už není a všechny předchozí jsou nebezpečné? Vážně je SSL v pořádku?

Btw: Toho IMHO jsem si všiml.

"SSL po HeartBleed"

No HeartBleed nemělo se SSL nic společného, v té době se myslelo, že je ok. Od desátého měsíce 2014 už ale není ok.

O komunikaci se nebavím záměrně, o tu tady totiž momentálně nejde, jde o leaknutí databáze s hesly.

Jenže ta databáze s hesly musí nutně korespondovat s přihlašovacím protokolem. Každá varianta vám nějakou možnost uzavře. Zbývá si jen vybrat, kterou.

To, že má linux hesla zahashovaná a osolená automaticky znamená, že při autentizaci se to heslo musí dostat až do onoho stroje. Po síti. Až v tom stroji se to předá procesu, který má přístup k souboru shadow (to nemá kde kdo) a ten proces k tomu přidá onu sůl a porovná výsledek.

Takže ochrana souboru s hesly se nám právě změnila na ochranu hesla putujícího po síti.

Když budu mít hesla v plaintextu, tak to heslo po síti mohu klidně poslat jako hash (domluvenou mezi klientem a server), server přijme onu hash, z uloženého hesla si spočítá svou a porovná.

Kterou variantu si vyberete? Obojí mít nelze. Ochráníte soubor nebo síť?

A těmito kroky se pomalu dostáváme k chalange response, digestům, a scramu. Dostáváme se k řešení problému s MITM, dostáváme se k potvzení identity servery klientovi apod.

Celá ta věc je mnohem složitější, než jen křičet hash, hash, hash. Na mnoha stupních jsou kompromisy (něco získáte, něco ztratíte).

Jenom doplním, že jakmile má heslo putovat v otevřeném tvaru po síti, to heslo se samozřejmě jako první dozví klient. Takže je to spíš "ochráníte soubor nebo klienta a síť"?

Můžu se zeptat co v tom hesle schováváte? To musí být šíleně cenné. Mnohem cenější než ta data, která ukradením databáze získají též. Fascinuje mě, jak kde kdo řeší ztrátu několika náhodných znaků, ale nikdo neřeší, zda neuniklo i něco jiného. Pokud jste tam nic jiného neměli, tak proč to řešíte?

Když nemůžeme zabezpečit to, aby se heslo na server vůbec nedostalo, tak se na to úplně vyse.eme a hesla prostě uložíme v plaintextu, že.
Píšete to, jako bych to tvrdil já. Já jsem ale nikdy nic takového nenapsal. Že by straw man?

Když je tedy hash slabou záplatou, tak se předveďte: 2d88841511a72­f8d81d0a84490ac3865
Takhle to ale nefunguje. Ve skutečnosti vy pošlete serveru heslo v otevřeném tvaru při registraci, a v drtivé většině případů ho posíláte v otevřeném tvaru při každém přihlášení. A pak doufáte, že s tím heslem server bude zacházet nějak rozumně. Ve spoustě případů to celé probíhá nešifrovaným spojením.
Takže pokud to chcete napodobit, napište sem vaše heslo v otevřeném tvaru a doufejte. Pak se mne na to vaše heslo zeptejte. Pokud jste doufal správně, po vašem hesle v otevřeném tvaru už nikde nebude ani stopy.

Já měl dojem, ža tady se diskutuje o hashování vs. plaintextu uložených hesel v DB
To je právě ten problém. Nejprve si úplně špatně vymezíte problém, a pak pro něj najdete geniální řešení.

Proč bych heslo posílal v otevřeném tvaru a proč bych měl doufat?
Protože tak to v reálném světě na drtivé většině webů funguje.

Tak já chci, abyste mi dokázal, že pro hashování není žádný důvod
Já jsem ale nikdy netvrdil, že k tomu nikdy žádný důvod být nemůže. Dokonce si myslím, že často je to dobrý způsob druhé obranné linie (první je samozřejmě to, aby se útočník k datům v databázi vůbec nedostal). Já se jenom podivuji nad tím, že spousta kritiků nehashování žádný relevantní důvod pro hashování nezná.

přístup k DB s hashovanými hesly a k DB s plaintext hesly je to stejné
Vy tvrdíte, že problém je únik dat z databáze. Já vás už po několikáté upozorňuju na to, že hashování hesel úniku dat z databáze nebrání, takže pokud např. webová aplikace má přístup do tabulky s přihlašovacími údaji (přihlašovací jméno a heslo nebo hash) a zároveň má útočník přes SQL injection možnost vypsat obsah té tabulky, její obsah získá bez ohledu na to, zda jsou tam hesla nebo jejich hashe. Vy se asi snažíte dostat k tomu, že obsah tabulky s hesly v otevřeném tvaru může útočník využít jinak, než obsah tabulky s hashy. Ale zatím jste se k tomu nepropracoval. A to jsem vám přitom už napověděl, v čem je doopravdy problém.

Zprávička je o tom, že byla odcizena databáze uživatelů Jabbim.cz.
Pokud vám nevadí, že provozovatel serveru má vaše heslo a může si s ním dělat, co chce, jak vám může vadit, že si jej ukládá v otevřeném tvaru do databáze? Vždyť to druhé je jen speciální případ toho prvního.
Důvody zná každý, kdo o tomhle již někdy diskutoval. Dokonce u průměrně inteligentního člověka lze očekávat, že ho nějaký důvod napadne.
Takže si o vás mám myslet, že jste podprůměrně inteligentní? Já nevím, když se zeptám „proč“, a vy tvrdíte, že odpovědět je strašně jednoduché, připadalo by mi nejlogičtější, kdybyste prostě odpověděl. Místo toho tady už několik komentářů píšete o tom, jak je to jednoduché, jak to ví každý, ale nenapsal jste to ani jednou. Takhle snadno dokázat, že máte pravdu, kdy zase budete mít takovou příležitost?

A "placne vsechna hesla volne na web" je take specialni pripad prvniho. Ale vetsinou to provozovatele serveru nedelaji, protoze je to prasarna, a stejne tak neni prilis odvazne chtit, aby neukladali hesla v plaintextu.

(Jsem ted trochu zmatenej, trolujes pro ten pocit z trolovani, nebo jsi proste najel na spatne udrzitelne stanovisko a to se ted snazis hajit za kazdou cenu?)

Původně jsem si myslel, že se dozvím alespoň nějaké argumenty, proč je lepší ukládat do databáze hashe hesel. A že bude stačit upřesnit, že je kvůli duhovým tabulkám potřeba hesla solit, a pak můžeme řešit, za kterých předpokladů je lepší použít jednu sůl a kdy je lepší solit každé heslo zvlášť. Ale ukázalo se, že je v pohodě udržitelné i stanovisko, že argumenty pro ukládání hashů neznají žádné, protože zatím nepřišel nikdo, kdo by to moje stanovisko jednoduše rozbil tím, že by ty argumenty pro hashování napsal.

A vaše stanovisko je… ?

2014. Tady neni co resit: temer vzdycky *) ukladat cizi hesla prohnana skrz KDF a temer vzdy solit unikatni a nahodnou soli pro kazde.

Kdyz nehashujes, tak ti mohou utect cizi hesla ven vcetne tech uzivatelu, co se neprihlasovali a to sparovana s jejich loginem a typicky emailem a dalsimi udaji. Kdyz hashujes, tak ti mohou v plaintextu utect jenom hesla tech, co se v dobe, kdy jsi pwnuty, prihlasuji. Kdyz hashujes slabou funkci (MD5), tak jde hadat slaba hesla hrubou silou. Kdyz hashujes bez soli, tak funguji vyhledavaci tabulky. Kdyz pouzivas porad stejnou sul, tak maji dva ruzni uzivatele se stejnym heslem ten samy hash.

*) a ty vyjimky jsou situace, kdy je nekde neco moc spatne, ale ty s tim nemas moznost nic delat

Ale tohle bychom vazne nemeli resit, tohle je snad dneska samozrejme.

Pokud se používá pro každého uživatele náhodná sůl, musí se ta sůl ukládat, a bude nejspíš uložená hned vedle toho hesla. Pokud bude chtít útočník zaútočit na konkrétního uživatele, zná sůl a pokud bude mít uživatel slabé heslo, může ho hrubou silou rozlousknout. Pokud bude sůl jednotná, může být snadno uložená mimo databázi, a útočník pak nemá šanci ani v případě, kdy bude heslo uživatele slabé. Nejvýhodnější je samozřejmě varianta, kdy jsou soli dvě, jedna globální a vedle i uživatelská. Mimochodem, hashování není jediná možnost, dá se to řešit třeba také šifrováním hesel, nebo uložením hesel takovým způsobem, že je webová aplikace nemůže číst.

Já bych za samozřejmé v roce 2014 považoval, že se provozovatel nějaké služby heslo uživatele vůbec nikdy nedozví. Tyhle hrátky s tím, že získá jeho heslo a pak ho možná zahashuje, jsou dost chabá záplata. Ostatně, pokud někdo používá všude stejné heslo, nemusí být útok veden jenom tak, že někdo získá neoprávněný přístup k cizí službě. Útočníkem může být klidně provozovatel té služby. Vlastně mne překvapuje, že zneužívání získaných přihlašovacích údajů z různých pochybných webů se neděje moc často.

Už zde padlo, že není možné chtít po uživatelích, aby používali na každou službu jiné a bezpečné heslo. Že to můžeme chtít po odbornících, ale ne po lidech, pro které je počítač jenom nástroj. Já si myslím, že to samé platí i pro provozovatele internetových služeb. Tam taky můžeme chtít po odbornících, aby se svěřenými hesly pracovali zodpovědně, ale můžeme to chtít po někom, kdo si na koleně splácá web? Zrovna v případě těch hesel je to snadno řešitelné, aby heslo nebo jeho ekvivalent provozovatel vůbec neznal. S ostatními údaji je to horší, ty často potřebuje a uniknout mohou také.

> Vlastně mne překvapuje, že zneužívání získaných přihlašovacích údajů z různých pochybných webů se neděje moc často.

Spis o tom ty nevis.

"Já bych za samozřejmé v roce 2014 považoval, že se provozovatel nějaké služby heslo uživatele vůbec nikdy nedozví."

+1

"Tyhle hrátky s tím, že získá jeho heslo a pak ho možná zahashuje, jsou dost chabá záplata."

+1

"Útočníkem může být klidně provozovatel té služby. "

+1

"Vlastně mne překvapuje, že zneužívání získaných přihlašovacích údajů z různých pochybných webů se neděje moc často."

Ono se to děje často. Akorát se o tom veřejně nemluví. Pinky má můj bod za zveřejnění svého problému, tohle se děje u jednoho případu ze sta.

Prodávají se seznamy živých emailů, roztříděných do kategorií. Odkud asi jsou? Prodávají se kombinace login a heslo (pokud se získají) i login a hashe (ty lze jednak spočítat z onoho hesla a také získat samostatně). Pouhým srováním hashů lze doplnit další hesla (už jen díky tomu, že lidé používají jedno heslo na x místech, pochopitelně stačí leaknou jedno místo a hned se získá hromada hesel, ta stačí zkusit zahashovat a porovnat s již existujícími v tabulce). Tímto se vytvoří poměrně pěkná tabulka loginů, hesel v otevřeném tvaru a všech běžně používaných hash fcí a případě i dalších údajů.

"Zrovna v případě těch hesel je to snadno řešitelné, aby heslo nebo jeho ekvivalent provozovatel vůbec neznal."

+1

Nevadí vám, že provozovatel serveru má vaše heslo a může si s ním dělat, co chce. Ale když si s ním dělá co chce a ukládá ho do databáze v otevřeném tvaru, tak vám to vadí. Tak hlavně že jste konzistentní.
Zatím se ukázalo, že kde kdo tvrdí, že důvody pro hashování jsou všeobecně známy, ale když je má někdo napsat, tak to nedokáže.
Nikde jsem netvrdil, že je jedno, jestli uniknou hesla v otevřeném tvaru nebo hashovaná. Mimo jiné proto, že u „termínu“ „hashovaná hesla“ vůbec není jasné, zda je to opravdu pouhý hash hesla, nebo zda je to hash pořádně osoleného hesla. Mezi těmi dvěma variantami je větší rozdíl, než mezi heslem v otevřeném tvaru a hashem čistého slabého hesla.

Upřesnil jste sice hezky, ale vyhnul jste se té nekonzistenci, na kterou jsem upozorňoval. Která je tak zřejmá, že už nevím, jak vám ji ještě lépe ukázat.
Tvrdíte, že vám nevadí, že provozovatel má vaše heslo a může si s ním dělat, co chce. Pak ale píšete, že vám vadí, když ho ukládá v otevřeném tvaru. Jenže ukládat heslo v otevřeném tvaru je jedna z možností, co s tím heslem dělat, když si s ním může provozovatel dělat, co chce.
Mohl by kolem toho být třeba následující rozhovor:
Seti (S) provozovateli serveru (PS): "Tady máš moje heslo, dělej si s ním, co chceš.
PS: "Opravdu si s ním můžu dělat, co chci?"
S: "Opravdu, dělej si s ním, co chceš."
PS: "A co když chci uložit ho v otevřeném tvaru do databáze? To také spadá pod !dělej si s ním, co chceš'?"
S: "Samozřejmě, 'co chceš' znamená, že si s ním můžeš dělat, co tě napadne. Smazat, zveřejnit, uložit do databáze zahashované, uložit do databáze v otevřeném tvaru... Prostě co chceš."
PS: "OK, tak já to tvoje heslo tedy uložím do databáze v otevřeném tvaru, když ti to nevadí."
S: "Ne, to nedělej, teď jsem si najednou vzpomněl, že mi to vadí! Dělej si co chceš neznamená, že si jen tak budeš dělat, co chceš, to je přece jasné každému tupci!"
Teď už to chápete?

Důvody jsou zde uvedeny několikrát, ale pokaždé je napsal někdo, kdo hashovací víru nezastává. Zastánci se zmohli akorát na to, že by údaje z databáze mohly uniknout, čemuž ale hashování nijak nezabrání.

To, že jste si vymyslel nesmyslný příklad, který nemá s realitou mnoho společného, není výmluva. To je bohužel hloupá vada vašeho příkladu. Tím příkladem perfektně předvádíte tu nejhorší chybu, kterou je možné při zajišťování bezpečnosti udělat - zaměřit se na jeden detail, a ignorovat celek. Takhle nějak klidně mohlo dojít k tomu úniku z Jabim.cz. Někdo se tam mohl zaměřit na detail, třeba aby se do databáze nedostal nikdo nepovolaný. Takže databáze přijímá požadavky jenom od webového serveru, všude pekelně složitá hesla, SSH jedině z jiného portu přes VPN z jediné IP adresy ne na roota, prostě nedobytná databáze. Takže kdo by myslel na nějaké hashování, ten detail s neoprávněným přístupem k databázi je přece perfektně vyřešen. Akorát pak jednoho dne někdo údaje z databáze získal, protože nepřišel jako neoprávněný uživatel, ale přistupoval k ní jako oprávněný uživatel přes webový server - akorát ten oprávněný uživatel dělal něco, co dělat neměl.
Ďábel sice bývá ukrytý v detailu, ale málokdy v tom detailu, na který se zaměříte.

""jak vám může vadit, že si jej ukládá v otevřeném tvaru do databáze?"

Takže speciálně pro slaboduché, kteří nejsou schopni domyslet důsledky úniku hesel: protože při úniku má útočník okamžitý přístup do mého účtu k dané službě. Nehashovat je amatérismus nejhrubšího zrna."

To už má už ve chvíli, kdy je schopný získat tu db hesel.

"Pokud vám nevadí, že provozovatel serveru má vaše heslo a může si s ním dělat, co chce, jak vám může vadit, že si jej ukládá v otevřeném tvaru do databáze? Vždyť to druhé je jen speciální případ toho prvního."

Ano, tohle mě fascinuje také. Dokonce tak moc, že jsem si dovolil o tom něco ublognout.

To, co říkají odpůrci plain hesel mi prostě nedává smysl. Asi jsem málo inteligentní (podle setiho). Co mě mrzí je, že nikdo své znalosti neprozradí.

1) Nikomu nevadí posílat své heslo volně internetem.

2) Nikomu nevadí, že ono heslo poskytovatel nějaké služby zná.

3) Ale všem hrozně vadí, že si ho dovolí uložit do db.

4) Skoro nikomu nevadí fakt, že se k té db někdo dostal.

5) Vůbec nikomu nevadí fakt, že si odnesl i jiná data.

Při své nízké inteligenci (podle setiho) jsem si z toho udělal následující závěr:

ad 1) Nikdo o tom neví, nebo alespoň o tom nepřemýšlí.

ad 2) To se bere jako samozřejmost, nikomu to nevadí.

ad 3) Někde si přečetli poučku, kterou papouškují, nepřemýšlí o tom. Kdyby ano, tak jak může být 2 v pořádku a 3 ne? Přesně jak píšeš, je to jen speciální případ.

ad 4) Pro toto nemám vysvětlení.

ad 5) Žádná data tam nemají.

Když se to shrne tak:

V zásadě chtějí ochránit svoje heslo, které používají na více místech. Nechtějí slyšet ani slovo o tom, že je problém na jejich straně. Kdyby se používala unikátní hesla, nic z výše uvedeného (kromě bodů 1 a 4) by vůbec nevadilo. Zkrátka viníka svého problému hledají jinde.

Mě osobně, kdybych měl účet na službě, která byla právě cracknuta, by nejvíce zajímalo, jaká moje data útočník získal nebo mohl získat. Od tohoto zjištění bych pokračoval dál. Pokud bych zjistil, že jediným údajem, který unikl, byl nějaký náhodný řetězec, byl byl kompletně v klidu. Ten totiž žádnou informaci nenese.

"Já jsem tady nenašel jediný názor, kde by někdo tvrdil, že mu to opravdu nevadí. Tedy pouze váš předpoklad."

Ale současně zde není ani jediný, který to řeší. Z toho lze učinit závěr, že to lidem vadí mnohem méně, než bod 3.

"Opět váš výmysl. Kde kdo tvrdil, že únik DB nevadí?"

Skoro nikdo se tu o tom nezmiňuje. Takže stejně jako v předchozím, vadí to méně, než bod 3.

"Já pořád dokola opakuju, že pokud už se stane ten průser a unikne DB, je lepší, když jsou hesla zabezpečena proti okamžitému zneužití."

Já pořád opakuji, že pokud je pro někoho problém únik hesla, tak si to může vyřešit na své straně. Má k tomu kompletně všechno, co k tomu potřebuje. Ano, je to nepohodlné, ale nikdo nikdy neříkal, že bezpečnost je zadarmo.

Zatímco když z té db uniknou i jiná data, tak to on sám nijak neovlivní (snad jedině tím, že onu službu nebude používat, ale tím vyřeší i ten problém s hesly.)

A přesto po sto padesáté tady někdo napíše, že vadí únik hesla a o tom, že uniknou ostatní data jaksi pomlčí, to mu je jaksi jedno (nepřekročí to jeho práh významnosti o tom psát komentář).

"To by mě zajímalo, jak to mám řešit na své straně. Jak mám vyřešit to, že nějaký mimoň nehashuje a nechá si ukrást databázi."

Když budete mít pro každou službu unikátní heslo, tak je vám celkem jedno, že to heslo při útoku na tu službu někdo získá. Protože se s ním nikam jinam nepřihlásí.

"Ono totiž vůbec nemusí znamenat, že s přístupovými údaji uniknou i nějaká další data"

Aha. Takže ten útok povedou speciálně tak, aby se k ničemu jinému nedostali. Jasně. Chápu. Hmm, proč to budou dělat?

"Minimálně se s ní přihlásí k té službě, ke které to heslo patří. "

Myslíte do té služby, do které už má boční vstup díky kterému získal onu db?

"Asi je to nad vaše chápání, nevím."

Asi je to nad vaše chápání. Podle vás bude ten útok na ona hesla veden tak fikaně, že útočník získá pouze heslo a dá si velký pozor, aby náhodou nezjistil i ještě něco dalšího a potom se přihlásí tím heslem? WTF? Proč by tohle dělal, když už má tu službu napíchnutou?

> Myslíte do té služby, do které už má boční vstup díky kterému získal onu db?

A to i pote, co nekdo ten bocni vstup zalata...

Pokud někdo ten boční vstup zalátá, mělo by být samozřejmé, že informuje uživatele a hesla jim změní.

Ono se to zalatani muze stat v ramci bezneho update kodu ("cywe, cos to napsal? jeste ze si toho nekdo nevsimnul!" "No jo, uz tam tlacim fix"), zrovna tam, kde se deji *inejction bych necekal obzvlast kvalitni intrusion detection...

Ale je mi celkem jasne, proc jeden znamej bezpecak rozesilal odkaz na tuhle diskusi jako vtip.

Tam, kde to funguje takhle, a únik hesel ani nezjistí, je dost pravděpodobné, že je ani to hashování hesel nezachrání.
Kampaň za hashování hesel zaměřená na provozovatele webů je evidentně neúspěšná, možná by stálo za to zaměřit svou pozornost jinam a pod každým dalším článkem o úniku dat z databáze se pohoršovat nad tím, jak to že dotyčný hacker hesla uživatelům nezresetoval sám, když měl k té databázi přístup.

Myslíš, že na nějakém lékařském webu je hlučná skupina diskutérů, která bagatelizuje význam mytí rukou před operací protože část doktorů stejně dělá i jiné chyby?

To je špatný příklad. Mytí rukou před operací je součást v současnosti nejlepšího známého postupu, jak operovat. Naproti tomu hashování hesel provozovatelem webu před uložením do databáze není součástí v současnosti nejlepších známých postupů autentizace uživatele - z toho jednoduchého důvodu, že ani jeden z těch dvou postupů nezahrnuje okamžik, kdy by provozovatel webu znal heslo, takže ho logicky ani nemůže hashovat.
Já jsem se bagatelizování významu hashování vyhýbal, protože to nebylo to, na co jsem původně reagoval. Ale mám-li se k tomu vyjádřit, pak ano, hashování hesel je podle mne nepodstatná prkotina ve srovnání třeba se zabezpečením údajů z databáze. Pokud si někdo tisíckrát zkontroloval, že se do databáze nedá dostat zvenku, že někdo nemůže zneužít aplikaci k získání dat z databáze, na která nemá mít práva, že bezpečně zachází se zálohami - ano, pak ať začne připravovat scénáře obrany pro ústup do předem připravených pozic začne přemýšlet třeba nad hashováním.

Tak si plivni do dlaně a tisíckrát kontroluj zabezpečení databáze.

My ostatní to zkontrolujeme stokrát, a budeme poctivě hashovat, protože to implementovat je trapně jednoduché, až to bolí. Poměr cena/výkon tady není potřeba řešit, zrovna tohle je implementovat radost a je to hotové před svačinou.

Ty postupy, kdy majitel webu nezná heslo jsou prima na papíře, ale stejně nakonec téměř vždy skončíš s tím, že nějaké vlastní přihlašování udělat musíš.

Bohužel ty trapně jednoduché implementace jsou prakticky k ničemu, protože vznikají tak, že si někdo na Rootu pod diskusí přečte, že je potřeba hesla hashovat, tak do INSERTu a SELECTu přidá funkci md5 a má hotovo. Problém s bezpečností je v tom, že se nad ní musí především přemýšlet. Implementace pak skutečně někdy může být trapně jednoduchá.
Když se při registraci místo hesla posílá rovnou hash, nebo když se přihlašuje certifikátem, vůbec to nevylučuje mít vlastní přihlašování.

Jestli nejsi schopen trapne implementaci zrovna hashovani hesel vyfrknout za chvili bez velke meditace... tak mozna cas si zapsat najky kurz trebas na Coursere.

Jak jsem psal, problém není v samotné implementaci, ale v přemýšlení o souvislostech. Třeba o tom, že když zahashuju samotné heslo pomocí MD5, tak jsem sice umlčel komentátory na Rootu, ale z hlediska bezpečnosti jsem to moc nevylepšil, protože slabší hesla útočník získá stejně.

Prosimte strc si MD5 nekam, uspokojovani komentatoru nekam a bez vetsiho premysleni pouzij nejakou moderni KDF *). K tomu nepotrebujes mozkovou kapacitu, k tomu ti staci elementarni znalosti. Stravis tim podstatne mene casu nez resenim vsech moznych *injection a dalsich der. Bonusove body ziskas tim, ze hned po zahashovani hesla ten kus pameti, ve kterem byl plaintext, prepises (coz uz na rozdil od toho hashovani muze byt tezsi, kdyz se zamyslis nad souvislostmi).

*) Jo, najdes protipriklady. Ale je to jeden pripad ze sta **). To jsou situace, kdy MUSIS premyslet.
**) nadsazka. Mozna z padesati, mozna z dvou set.

Když jsou ty komentáře „to co je za jebnutost ukladat hesla ako plaintext?“ tak bezchybné, co je špatně na tom se jimi řídit? Já se snažím vžít do kůže někoho, kdo má aplikaci s SQL injection, a teď se dočetl v komentářích na Rootu, že má hesla hashovat. Taky v těch komentářích psal nějaký Jirsák, že je potřeba nad tím hlavně přemýšlet, a že při tom přemýšlení už dojde k tomu, jestli hashovat nebo to třeba řešit úplně jinak. Ale Jirsáka tam umlátili neustálým opakováním, že programátor nemá vůbec přemýšlet a má hashovat. Tak jsem si našel, že v PHP existuje funkce hash(), jako první parametr bere nějaký algoritmus, v nápovědě je jako první uvedeno md5, to už jsem někde slyšel, na webu píšou, že je to hash, tak to bude OK. A mám hotovo.
Je to přesně podle postupu, který tady kde kdo doporučuje. To není protipříklad, to je typický postup. Ano, najdou se i výjimky, které se nebudou řídit tím, kolik lidí zastává nějaký názor, ale posoudí i obsah těch komentářů, a dojdou k tomu, že přemýšlet nad zabezpečením není zas tak špatný nápad. Ale těch bude menšina.

Tak pokud se bavime o "programatorech", co v PHP objevili funkci hash a nekde slyseli o md5.. tam je potreba je poslat do skoly, ne jim davat praci.

> Když se při registraci místo hesla posílá rovnou hash

Tím se z hashe stalo heslo a jsme (skoro) tam, kde jsme byli ;)

Nestalo.

Ale stalo. Útočníkovi stačí získat pouze hash hesla, aby se úspěšně přihlásil. On vlastně ani neocení, že se to heslo před odesláním zahashovalo.

Můžete to ukázat na konkrétním případě pro algoritmus SCRAM?

Ale vy jste napsal doslova "Když se při registraci místo hesla posílá rovnou hash". O scramu ani slovo.

Jste to přece vy, kdo tady brojí za přesné a precizní vyjadřování…

SCRAM je algoritmus. Který při registraci potřebuje od uživatele získat pouze hash. Hashovací algoritmus a počet iterací bude spíš posílat server klientovi. A pouze tyto tři údaje si server musí k uživateli uložit.
Takže teď už nám to předvedete?

Ale vy jste nenapsal scram, vy jste napsal, že klient místo hesla pošle zahashované heslo. Neboli vezme heslo, prožene ho přes md5 a výsledek pošle na server.

MD5 není jediná existující hashovací funkce. A i ta MD5 se dá se SCRAM použít. Napsal jsem, že klient pošle zahashované heslo. Což znamená, že pošle hash, který vznikl na základě hesla.
Chápu, že když ani nevíte, že existují i jiné hashovací funkce, než MD5, musel byste toho hodně nastudovat, abyste pochopil princip SCRAM. Nechápu, proč o tom pak diskutujete a proč tvrdíte, že něco nějak funguje, když o tom nevíte vůbec nic.

Pouze si vybírám nejdementnější možnou interpretaci vašeho tvrzení, stejně jako to tady celou dobu předvádíte vy. Je to docela hnusné, že?

Spíš smutné. Protože vy jste tady ještě žádnou jinou interpretaci nepředvedl. Ptal jsem se mnohokrát, jak ta vaše tvrzení interpretovat lépe, a dozvěděl jsem se jenom to, že to přece ví každý, nebo že je zbytečné to psát.

Psal jste různé důvody, ale nikdy to nebyly důvody pro hashování hesel. Důvod pro hashování hesel v databázi je například to, že uživatelé často používají stejné heslo se stejným login pro více služeb, takže pokud by heslo z databáze uniklo, může ho útočník použít k přihlášení k jiné službě uživatelovým jménem. Aby se tomuhle důvodu předešlo, nestačí hesla hashovat, ale je potřeba je i osolit. A hashování není jediný způsob, jak tomuhle problému předejít.
Vy jste jako "důvod" uváděl, že data z databáze mohou uniknout. To ale samo o sobě žádný důvod pro hashování hesel není, protože samotný únik hesel ničemu nevadí. Nebo chcete tvrdit opak? Tady máte moje přihlašovací údaje k účtu na Root.cz: login Filip.Jirsak, heslo cb52kyN&r^+yuSPg. Komu nebo čemu zveřejnění vadí?

Abyste se trochu dovzdělal – trollení předvádíte vy, když napíšete „byly“, aniž byste se obtěžoval to nějak doložit. K čemu takový komentář je? Vy jste napsal něco, o čem jste si myslel, že jsou to důvody, já jsem vám to vyvrátil, a vy na to nedokážete zareagovat jinak, než že jak kolovrátek opakujete, že to důvody jsou. Aniž byste se jakkoli pokusil argumentovat proti mému tvrzení.
To, že další reakce z vaší strany nebudou, není žádná novinka, mnoho vašich odpovědí postrádá reakci na to, na co odpovídáte.

Ty duvody ti tu ruzni lide popsali nekolikrat pri ruzne urovni presnosti. Uzivatele recyklujici hesla a tak dal, a tak dal.

Jestli to chces pojmout, jako soutez v retorice, kde je cilem zvitezit, tak
- a) pripadne vyhry na internetu se ti stejne nepocitaji do skore
- b) nic to nemeni na tom, ze tu mas spoustu vygooglitelneho materialu ke sve osobe, ktera napriklad odradi potencialni zamestnavatele, ktere o problemu neco vedi
- c) je to tak nejak vseobecne povazovano za nekooperativni strategii a podle toho je s tebou zachazeno

Ty duvody ti tu ruzni lide popsali nekolikrat pri ruzne urovni presnosti. Uzivatele recyklujici hesla a tak dal, a tak dal.
To odpovídání, které není reakcí, je nějaké nakažlivé, ne? Seti psal, že on uváděl nějaké důvody - vaše odpověď, že různí lidé psali různé důvody, tedy jeho tvrzení nijak nepodporuje.
Jinak to, že různí lidé psali různé důvody, samozřejmě vím. Byl jsem totiž první, kdo tady nějaký důvod uvedl - a bylo to právě to, že uživatelé používají stejné heslo na více místech.
Potenciální zaměstnavatel, který má v kódu SQL injection a ještě přes něj umožňuje útočníkovi zobrazit obsah celé tabulky, a který o bezpečnosti ví jenom to, že na Rootu v komentářích psali, že hesla je potřeba v databázi hashovat, ten o problému neví prakticky nic. Moje komentáře ať si klidně vygoogluje, aspoň se poučí a bude vědět, že bezpečnost se nedá řešit tak, že si zvolím jediný vektor útoku, a proti němu se budu bránit tou nejméně vhodnou metodou.
To, že se na arogantní komentář obvykle dostane arogantní odpovědi samozřejmě vím. Vždyť jsem sám takhle na první arogantní komentáře reagoval.

Takze ty chces, aby ti ty duvody zopakoval kazdy jednotlive? :-D

Nikoli. Mám silné podezření – rostoucí s délkou této diskuse – že ti komentující, kteří se podivují jedině nad tím, že hesla byla v databázi uložena v otevřeném tvaru a nebyla hashovaná, vůbec nevědí, o čem píšou, a akorát papouškují, co někde zaslechli. Což se podle mne projevuje mimo jiné tím, že nedokáží ani napsat, co je na tom špatně (protože kdyby to věděli, tak ten původní komentář nenapíšou tak, jak ho napsali). Tomu Seti oponoval, a jako důkaz svého tvrzení ty důvody – nenapsal. A to ani po opakovaných výzvách. Zmohl se jedině na to, že se mají hesla hashovat proto, aby neunikla, což jako odůvodnění nemůže obstát (a každý, kdo se nad tím aspoň trochu zamyslel, uvede lepší důvody, a únik hesel tam bude pouze jeden z mezikroků).
Původně jsem myslel, že se nad věcí alespoň některý z těch papoušků zamyslí, a příště napíše něco rozumnějšího, nebo se alespoň zdrží komentářů ukazujících, že o věci nic neví. Místo toho diskusi ovládl Seti (a pár různě odhodlaných sekundantů), který se rozhodl, že se nad tím nezamyslí i kdyby ze sebe měl udělat totálního trotla. A své předsevzetí splnil perfektně. Vy už jste se k tomu přimotal až v průběhu, kdy už se projevilo ono známé pravidlo "nikdy nediskutuj s hlupákem, lidé by nemuseli poznat, kdo je kdo".

E-maily uložené v sousedním sloupci nemohou uniknout? Nebo se mají e-maily v databázi také hashovat, protože mohou uniknout?
Ono také záleží na tom, kdo uniká - jestli hesla nebo hashe. Hashe mohou uniknout stejně snadno, jako hesla uložená v otevřeném tvaru.

Naopak, jste jediný, kdo tady žádnou představivost nemá. Představíte si jeden z milionů možných útoků, a pak se pořád dokola točíte na tom, že zrovna pro tenhle jediný útok je to vaše řešení použitelné.
Pokud by to skutečně bylo tak, že přihlašovací údaje má web uložené odděleně, třeba v databázi přístupné pod jiným uživatelským účtem, pak to asi navrhoval někdo, kdo o zabezpečení aspoň trochu přemýšlel. Takže přístup k téhle speciální tabulce pořádně zabezpečí, aby tam neměl SQL injection – proto to do té samostatné tabulky dává.

A tímto chcete dokázat konkrétně co? Že když se k tomu nedostane konkrétní člověk (nebo kdokoliv z místních), tak to budete považovat za bezpečné?

To je stejný nesmysl jako honit si ego na tom, že sem plácnu MD5 hash a budu se kochat tím, jak na to nikdo nereaguje.

Ano, z několika desítek místních diskutujících to třeba opravdu nikdo nedokáže. Z několika tisíc čtenářů třeba taky ne. A co jako? Co když to dokáže tisící prvý, který se o tom (samozřejmě) nepochlubí?

Necháte se ukolébat pocitem, jak jsou všichni tady neschopní looseři a dál budete používat fci, o které je 19 let známo oslabení a pro kterou se 9 let umí hledat kolize na počkání? Jen proto, že to nějaká vámi definovaná skupina lidí nedokáže (spíše ale z toho titulu, že se tím prostě nechce zabývat a třeba má lepší využití pro těch 15 Kč)?

Opravdu na tomhle chcete stavět bezpečnost?

Ano, sáhl mi na kuří oko, protože já rád dělám věci pořádně.

(Nejen) tady v diskusí se neustále řeší, jak zalepit (žvýkačkou) nějakou dírku a kompletně se ignoruje ta 200 metrová díra v trupu.

A když někdo, třeba já, řekne hele, pojďme to teda udělat už konečně pořádně tak se dozvím milony zástupných důvodů, proč se to pořádně nedá dělat a proč je nutné tam jen plivnout tu žvýkačku a tvářit se, že je vše v pořádku.

Tohle se týká i ssh na jiném portu, fail to ban, přihlašování hesly, a hromady dalších věcí (O tom jsem se krásně rozčílil zde: http://www.heronovo.cz/ne-bezpecnost-ssl/ :-D ).

Prostě není zájem to dělat správně, naopak je obrovský zájem to ojebávat. Já se toho ojebávání účastnit nechci.

Ke kterému webu se lze přihlásit tímto způsobem? Tedy že mu do políčka pro heslo napíšete „heslo v plaintextu pod jednu diskusi na serverech jedné ze služeb iinfo.cz“?

wtf?

Já to dělat nebudu, ale víte o tom, že brute force attack na MD5 vás vyjde na půl piva?

http://www.linuxexpres.cz/novinky/na-uspesny-utok-proti-md5-staci-10-hodin-a-65-centu

To je hledani kolizi, coz neresi problem, jak se dostat k plain heslu a zkusit ho pouzit jinde (tedy pokud to jinde nepouziva schodou okolnosti take MD5 a stejnou - tedy nejspis zadnou - sul pro daneho uzivatele).

(Cimz se tedy nechci zastravat pouziti MD5 k cemukoli)

Jenže je to hledání kolizí hrubou silou. Nikoliv chytrystikou, jakou před 9 lety vymyslel Klíma. Tehdy bylo toto hledání kolizí na pár minut (viz. články zde na rootu). Dnes je to za půl piva.

Chápu, že vy MD5 neobhajujete, ale co mi i na této diskusi vadí je (asi jako Jirsákovi), že hromada lidí tady volá amatérismus, a potom si pletou TLS a SSL, považují SSL za OK, uvádějí MD5 jako příklad a nakonec se ukáže, že někteří vlastně nevolají po hašování ale po šifrování. Jako když takhle vypadá diskuse na rootu (a abclinuxu a hromadě dalších webů), nelze se potom divit, že software vypadá tak jak vypadá. Protože, a to vím z dřívějších zkušeností, potom zítra přijdou do práce a tam udělají přesně stejnou kravinu, jakou dneska vyčítají někomu jinému. Třeba nechají otevřený upload pro php soubory, které se potom na serveru vykonávají (tohle je mor stejně jako třeba sql injection).

Pánové, když už někomu vyčítáte amatérismus, tak by bylo dobré, kdybyste vy sami amatérismus nešířili. Prostě uklidit si před vlastním prahem.

Mně ta diskuse v jedné věci otevřela oči. Dříve bych tvrdil, že současný systém je navržen tak, že je chybou uživatele, pokud používá stejné heslo pro více služeb. Že ale nelze po uživatelích chtít, aby používali desítky hesel, a že je to tedy chyba systému, chyba odborníků. To oni to mají vyřešit tak, aby se uživatelé mohli bezpečně přihlašovat k webům i když se budou chovat tak, jak se lidé přirozeně chovají. A stavěl bych provozovatele webů na stranu těch odborníků, k těm, kteří mají ten systém změnit.
V téhle diskusi mi došlo, že to tak není, že provozovatelé webů patří na stranu uživatelů. Oni také jen chtějí používat nějaký nástroj (web), a očekávají, že ten nástroj je udělaný tak, aby fungoval bezpečně.
Pro mne to znamená, že nelze čekat tlak od provozovatelů webů ("necpěte nám ty hesla, my je nechceme"). Místo toho je potřeba, aby ti lidé, kteří chápou aspoň základy bezpečnosti a zároveň si uvědomují, jaká je role uživatele nějakého nástroje a jaká je role tvůrce toho nástroje, aby tlačili především na autory webových prohlížečů a hned po té i serverů. A pravděpodobně to znamená nechat v rámci GSoC nebo nějakého CZ.NIC Summer of Code naimplementovat do prohlížečů bezpečnou registraci a zkulturnění HTTP autentizace. Dál už to půjde samo podle současného pravidla "webový standard je to, co implementuje alespoň jeden velký prohlížeč".
S SQL injection to tak snadné nebude, spálit veškeré tutorialy, které učí přístup k databázím na PHP mysqli asi nebude možné. A mnohé NoSQL databáze se od SQL databází nechtějí lišit zas až tak moc, takže pro jistotu mají API navržené API tak, aby pro programátory nebylo příliš obtížné napsat kód s NoSQL injection.

Já to nechci vést úplně off topic, protože se konce stejně nedobereme a taky už je moc hodin a zítra v práci chci taky dělat něco jiného než předstírat, že nespím, tak snad jen pár vět k zamyšlení.

Existovaly technologie, jako například OpenID. Každý mohl mít na svém serveru providera OpenID a pomocí toho se přihlašovat na weby. Stačilo jedno heslo, které by se provozovatelé nikdy nedozvěděli. Služba se nikdy neujala. Dlouho potom přišlo MojeID, vzalo OpenID protokol a udělalo to centrálně. Do tohodle zase hromada lidí, včetně mě, nepůjde jen z principu (z principu toho, že mi přijde, že si jedna organizace na sebe nabaluje až příliš mnoho informací. To, že mi NIC podepisuje doménu na cz tld, to vyplývá tak nějak přímo z účelu NICu. To, že o mě díky registraci domén zná hromadu infa, to taky snesu. Ale to, že by ještě věděla, kam se přihlašuji a jak často, tak to už je na mě trochu moc. Autentizační provider má být co nejblíž uživateli a co nejdál od hromady dalších údajů centrálně zpracovávaných.)

Existuje DNSSEC a TLSA. Zadarmo. Přes to jaksi se stále více používají a stále více tlačí komerční serverové certifikáty od autorit, které mají hodně velký škraloup z minulosti.

Už 40 let existuje asymetrická kryptografie, přes to se používají jen střípky z jejích možností.

Atd.

Já nevím čím to je. Kdybych to věděl, tak bych neseděl v diskusi na rootu. Ale zdá se, že některé technologie se prostě ne a ne prosadit i když jsou mnohem lepší, jednodušší a často i levnější, než to, co se aktuálně používá.

S OpenID je podle mne problém v tom, že vyžaduje od provozovatele webu jiný přístup k autentizaci uživatelů. Jenže zároveň musí dál podporovat přihlášení jménem a heslem (protože si nemůže dovolit říct „uživatel musí mít OpenID účet, založte si ho třeba tamhle, tamhle nebo tamhle“). Takže nezíská výhodu z toho, že by se nemusel starat o hesla, naopak musí naroubovat OpenID na stávající systém. Další problém je v tom, že obvykle musíte stejně udržovat osobní údaje jak u OpenID poskytovatele, tak na webu, kam se přihlašujete (a OpenID pro to nemá rozumné řešení).
Komerční certifikáty bych nezatracoval, EV certifikáty mají smysl (pokud by tedy nebyly extended, ale bylo by to to základní, co CA poskytuje). DV certifikáty dnes technologicky smysl nedávají, zabezpečení přes DNSSEC ověřuje doménu spolehlivěji, než jako to dělají CA. Na druhou stranu, dnes se stále ještě nelze spolehnout jen na DNSSEC, protože v celém řetězci je málo implementací. Zrovna nedávno jsem s hrůzou zjistil, že sice ČR patří ke světové špičce v zavádění DNSSEC, ale je to jenom díky tomu, že velký registrátoři zapnuli DNSSEC na svých autoritativních serverech. Spousta českých registrátorů se sice chlubí podporou DNSSEC, ale když se zeptáte na generické domény, odpoví vám, že DNSSEC jenom .cz a případně .eu. A spousta jich dokonce podporuje DNSSEC pouze pokud doménu hostujete na jejich serverech, vložit DS záznam do TLD zóny nebo nastavit vlastní KeySet vám neumožní.
Ty technologie se samozřejmě rychle neprosadí samy od sebe, pro rychlejší šíření je musí prosazovat někdo. My máme to štěstí, že pár rozumných technologií prosazuje zrovna CZ.NIC – i když zrovna u toho DNSSEC by už mohl být přísnější.

Ony se ty bruteforce na MD5 dost dobre paralelizuji... Navic kdyz mas kopec hashu se stejnou (tedy nejspis prazdnou) soli, tak muzes snadno testovat heslo proti vsem moznym hashum.

Co tuhle cast proste zavirt tim, ze pri pruniku do DB je MD5 moc spatne a plaintext jeste horsi?

> A teď si vyber.

Takze si vyberame medzi napadnutim jedneho uzivatela, ktoreho si niekto cielene vyhliadol a investuje znacne prostriedky na MITM attack a medzi moznostou, ze nam niekto ucoruje hesla uplne vsetkych uzivatelov. Sofiina volba, fakt -_-

Jak? (bavime se o situaci, kdy je to udelane poradne?)

Moderní kdf se dají louskat asi tak jako moderní šifry. Skoro vůbec.
Proto je použití hashe ještě víc doručováno.

"jen te dane sluzby"

A všech ostatních služeb, které používají tentýž mechanismus. Jinými slovy úplně stejná situace, jako u ukládání hesel přímo v plainu.

Jo, ale pocita se rychle. Takze sul-nesul je vetsi riziko pro slabsi hesla nez u funkci specialne navrhovanych pro ukladani hesel.

A když v té stored funkci bude chyba, tak co?
Tak nám leaknou všechny plain text hesla.
Nebo bude chyba v oprávněních.
Nebo bude buffer overflow v DB serveru.
Nebo se naštve kolega s root přístupem a tu databázi hesel si stáhne a vystaví na net.

Nebo bude chyba ve funkci, která ověřuje zahashovaná hesla.
Nebo bude buffer overflow ve WEB serveru.
Nebo se naštve kolega, která dělá webový fronted nebo firewall, a všechna příchozí hesla si bude ukládat do logu, který pak vystaví na net.

Co z těch 4 odrážek je důvod používat plaintext?

Samo o sobě nic. Stejně jako žádná z těch vašich čtyřech odrážek není důvod používat hash.

Není? Nasraný kolega, který vystaví seznam uživatelských hesel na net není důvod k tomu ty hesla zahashovat, aby k nim neměl přístup ani on?

ty hesla zahashovat, aby k nim neměl přístup ani on
To je právě ten problém, že zahashováním hesel mu v přístupu k heslům nezabráníte. Protože ta hesla se v otevřeném tvaru posílají při registraci a pak při každém přihlášení. Takže ten kolega k nim má přístup a vaši databázi vůbec nepotřebuje.