Já jim dlouho přispíval, ale vzhledem k tomu, že na googlu mám ještě větší prostor pro soubory a navíc zdarma, a přes skype a icq mi skoro nikdo nepsal, tak to začalo postrádat smysl. Vlastní jabber server se zdá fajn, někdy o tom přemýšlím. Jenže situace je už trochu jiná než dříve. Na to, na co bych používal jabber používám Talk. Jen mě mrzí, že přijdu o jabber adresu, nicméně já už ji stejně nepoužívám. A možná je to škoda. Nevím.
Nejspíš ne všichni sdílejí tuhle víru „ukládání hesel v otevřeném tvaru je vždy špatné, jediná správná metoda je ukládat hash“. Jsou i lidé, kteří jsou schopni položit si otázky: Je možné používat zahashovaná hesla spolu s protokolem XMPP? Jak budeme postupovat, až se objeví nová metoda přihlašování, která bude používat jiné schéma zacházení s hesly?
V situaci, která právě nastala, je problém v tom, že někdo získal obsah databáze. Únik hesel je jenom jedním z důsledků. Pokud není žádný důvod uchovávat hesla v otevřeném tvaru, je samozřejmě špatně mít je tak uložené. Ale neznamená to, že neexistují relevantní důvody pro ukládání hesla v otevřeném tvaru (a pak zase samozřejmě mohou existovat postupy, jak hesla chránit více, třeba šifrováním).
Z hashování hesel se stala taková mantra, podobně jako z „Java je pomalá“ nebo „NSA všechny špicluje“, kterou neustále opakují lidé, kteří někde něco zaslechli, ale vůbec netuší, o čem je řeč. Ono například ta hesla v otevřeném tvaru jsou problém jenom pro ty, kteří používají na více místech stejné heslo. Takže někdo provozovateli webu dobrovolně prozradí své heslo k jiným systémům, a pak se rozčiluje, že to heslo může znát i někdo další. Bylo by dobré si ujasnit, že ta největší bezpečnostní chyba je v takovém případě na straně uživatele. Odpovědnost jde především za autory webových prohlížečů a dále autory webových serverů a standardů, protože by bylo velice snadné zajistit, aby uživatel hesla zadával jen do speciálního bezpečného okna prohlížeče, takhle zadané heslo by nikdy neopustilo prohlížeč, a součástí běžné osvěty uživatelů (jako že nemají stahovat neznámé programy z webu a otevírat neznámé přílohy e-mailů) by bylo, že své heslo nikdy nemají v prohlížeči zadávat jinam, než do tohohle okna.
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.
> Žá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 :)
To je jak říkat, že abych mohl provozovat masivní železnou bránu, nesmí kolem ní být žádná zeď. Prostě to dělám blbě. Prosody umí SCRAM a TLS bez problému, takže používání starého ejabberd je jen na jejich zodpovědnost. Ano, přejít není jednoduché, ale tady je vidět, že byznys neberou vážně. Byl jsem několik let platícím zákazníkem, ale jen co jsem zjistil, že ukládají hesla v plaintextu (asi rok zpátky), odešel jsem k dukgo.com, a dobře jsem udělal.
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ý".
Hesla se mají hashovat PRÁVĚ PROTO, že existuje možnost úniku databáze. Fakt nechápu, co se tady snažíte dokázat. A zřejmě nejsem jediný, kdo to nechápe. Pro vaši informaci opakuji: bavíme se o úniku databáze a o snadném přístupu k heslům z důvodu jejich uložení v plaintextu.
" 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."
Nic takového jsem nepotvrdil. To tvrdíte vy a já chci, abyste mi to dokázal tím, že máte mé hashované heslo. Dokonce jsem vám to ulehčil nesaltováním a prozrazením délky hesla.
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).
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.
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.
"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.
"Navíc „má X hesel k okamžitému použití“, to taky ničemu nevadí."
OMG :-D Vy jste teda fakt případ, neuvěřitelné.
"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."
Obecný dotaz: existuje zde v diskuzi kromě Jirsáka ještě někdo, kdo potřebuje explicitně uvádět důvody, proč nemít hesla v plaintextu?
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.
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.
"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."
S trollem se odmítám dále bavit. Minimálně jeden důvod je zde zmíněn x-krát a já ho nebudu opakovat po x+1. BTW i kdybych je neznal a ani si nedokázal představit žádné možnosti zneužití jako vy, když ty důvody potřebujete vyjmenovávat od jiných, na věci to vůbec nic nemění.
No unik hesel jsem tak nejak pochopil, stane se, meli jsme to v plaintextu, jsme blbi, moc se omlouvame, ale takhle ztrapnovat byste se nemusel :)
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.
Staci kdyz te zdiskredituju na tomhle:
"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?"
A proc by mel klient spojit vyzvu z heslem a ne s hashi hesla + saltu ?
Jedine co na tvoji argumentaci chapu, je fakt, ze hashovani hesla neni samospasitelne.
Nejen webem a přihlašováním je internet živ. Z historických důvodů existuje spousta komunikačních protokolů (icq, jabber atd.), klientů a jejich implementace. Často je nutné je ještě relativně dlouho podporovat a přesně tyhle staré protokoly mají tyhle zrůdnosti pro ověření identity.
V současné době se vše samozřejmě řeší již jinak a máme tady mnoho různých protokolů založených na OAuth, dříve to ale nebývalo. Já nevím jak vy, ale já někdy ocením zpětnou kompatibilitu, přepisovat klienty při každé aktualizaci serveru je relativně drahé nebo komplikované.
> Ukladat hesla v hashi je sice takova jasna poucka, kterou lide omilaji dokola, ale nejak to asi muselo vzniknout, ze ?
A taky je poučka, že máš před bouřkou zapálit na serveru hromničku. Lidi z Netlabu to určitě neudělali a proto je hackli.
> A vzniklo to presne kvuli temhle pripadum, kdy se nekdo dostane k databazi.
A pak jsou zase jiné případy, kdy někdo odposlechne komunikaci. Ta tam to zase potřebuješ naopak.
> A proc by mel klient spojit vyzvu z heslem a ne s hashi hesla + saltu ?
Protože to programoval člověk, který kryptografii moc nerozuměl.
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.
Nějak tam nechcete zohlednit masovost. Zmiňujete bezpečnost jedince. A v té máte naprostou pravdu. Ale hashování hesel je o ztížení napadení všech účtů najednou. Pokud ukradnu databázi zahashovanou, tak i v případě MD5 budu louskat pár desítek hesel za hodinu. Pokud tam nebude ani ta pitomá MD5, tak mám statisíce hesel a můžu je okamžitě zkusit zneužít.
Cílem hashování hesel není bezpečnost jako taková, ale zpomalení útočníka v použití ukradených dat. Nedat mu všechna hesla k okamžitému použití.
Opakuji výzvu, předveďte se s rainbow tabulkami: http://www.root.cz/zpravicky/jabbim-cz-byla-ukradena-uzivatelska-hesla/525366/
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.
Tohle jsou hrozné plky. Nevětší úniky byly vždy způsobeny získáním dat z databáze. 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. Když je tedy hash slabou záplatou, tak se předveďte: 2d88841511a72f8d81d0a84490ac3865
Je to obyčejný MD5, nesaltovaný, s jednoduchým zapamatovatelným heslem, které lze snadno obměnit pro různé služby. Delka hesla je 14 znaků.
Právě proto jasně píšu, že největší úniky vždy byly způsobeny získáním databází. A týká se to i tohoto případu. Jak dlouho by musel někdo sniffovat netový traffic, aby získal stejné výsledky, jako zcizením databáze s plaintext hesly?
Uložení plaintext hesel v DB nepovažuji ani za šlendrián, ale přímo za zločin. Takového prgátora pověsit za koule do průvanu.
Může být. Třeba pro mě je důležitější, aby heslo neputovalo v plaintextu po síti, než aby nebylo v databázi (protože jeho únik z databáze mě netrápí, protože ho samozřejmě nikde jinde nepoužívám). Můžu se totiž díky tomu připojit třeba z J2ME klientů, které SSL neumí. Nebo u toho SIPu dosud spousta HW telefonů neumí SIPS, tam je to taky důležité.
OK, vy mluvíte o jedné možnosti zneužití, tedy použití stejného hesla na jiné služby. A co takhle zneužití té konkrétní služby, jejíž databázi někdo odcizí. Pořád si myslíte, že hashování je zbytečnost? Plaintext = OKAMŽITÝ přístup ke všem účtům dané služby! Myslíte, že hashovat hesla třeba v /etc/passwd je taky zbytečnost?
O komunikaci se nebavím záměrně, o tu tady totiž momentálně nejde, jde o leaknutí databáze s hesly.
> OK, vy mluvíte o jedné možnosti zneužití, tedy použití stejného hesla na jiné služby.
Ne.
> Myslíte, že hashovat hesla třeba v /etc/passwd je taky zbytečnost?
/etc/shadow. Možná. Pokud bych já nevím chtěl provozovat OTP a to to vyžadovalo, tak asi jo.
> O komunikaci se nebavím záměrně, o tu tady totiž momentálně nejde, jde o leaknutí databáze s hesly.
To je hezké, ale jako hypotetickému provozovateli Jabberu k prdu. Dnes se řeší, že jsem nastavil to řešení, které nepřenáší heslo po síti, ale musí ho ukládat v DB. A všichni mi tu nadávají. Tak já to přepnu. A za měsíc tu bude zprávička, že se objevil Heartbleed a někdo mi ta hesla vytáhl z paměti SSL terminátoru. A zase mi budou všichni nadávat, že jsem měl použít řešení, které heslo ukládá v DB, ale nepřenáší ho po síti.
"/etc/shadow"
Ups :-)
"Možná. Pokud bych já nevím chtěl provozovat OTP a to to vyžadovalo, tak asi jo."
Tak to já bych si tedy netroufnul.
"Dnes se řeší, že jsem nastavil to řešení, které nepřenáší heslo po síti, ale musí ho ukládat v DB. A všichni mi tu nadávají."
Pokud jsem si všimnul, tady se kritizuje ne obecné ukládání hesel v DB, ale jejich ukládání v čitelném tvaru.
"Tak já to přepnu. A za měsíc tu bude zprávička, že se objevil Heartbleed a někdo mi ta hesla vytáhl z paměti SSL terminátoru. A zase mi budou všichni nadávat, že jsem měl použít řešení, které heslo ukládá v DB, ale nepřenáší ho po síti."
Tak z takových nadávek bych si já nic nedělal. Použití SSL je IMHO v pořádku. Že se v něm objeví nějaká díra, za to vývojář web aplikace nebo admin nemůže. Nevšimnul jsem si, že by někdo nadával někomu za použití SSL po HeartBleed.
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.)
> 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á.
Jj, za poslední rok bylo v SSL a openssl nalezeno asi jenom 50 chyb.
> Napsat si do kódu SQL injection je běžné, až to bolí.
Není, není, není. Můžeš použít prepared statements, případně programovací jazyk, který ti to prostě jinak nedovolí.
> Ti, co měli problém s heartbleedem kritizováni nebyli, protože v rámci svých možností chybu neudělali.
Podle mě udělali - mohli přece použít způsob autentizace, který heslo vůbec nepřenáší.
>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...
"Jj, za poslední rok bylo v SSL a openssl nalezeno asi jenom 50 chyb."
Už jsem tady byl sprdnut, tak jen poupravím: místo SSL se spíše používá TLS, ten chybami SSL netrpí.
"Není, není, není. Můžeš použít prepared statements, případně programovací jazyk, který ti to prostě jinak nedovolí."
LOL, to byste se divil, jak "běžné" to je, bez ohledu na prepared statements či alespoň použití escape funkcí.
"Podle mě udělali - mohli přece použít způsob autentizace, který heslo vůbec nepřenáší."
Takhle to můžete delegovat ad absurdum až na samotné použití počítačů. Kdyby se posílala papírová a pošta a chodilo na přepážky do spořitelny místo do bankomatů, nebyly by žádné (hromadné) úniky informací a krádeže peněz.
"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.
Moje chyba, bral jsem SSL v tomto případě jako obecný výraz pro šifrovanou komunikaci, měl jsem to opravit na TLS. Nenapadlo mě, že si to někdo vezme doslova vzhledem k tomu, jak protokol SSL vypadá. Sypu si popel na hlavu.
"No HeartBleed nemělo se SSL nic společného"
Nemělo nic společného s konkrétním protokolem SSL, nýbrž s knihovnou OpenSSL, která ovšem implementuje TLS :-) Opět, spíš jsem to bral jako obecnou diskuzi o šifrování vs. ukládání hesel do DB.
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).
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: 2d88841511a72f8d81d0a84490ac3865
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, vy zřejmě diskutujete o něčem jiném, ovšem já absolutně nemám představu o čem.
"Takže pokud to chcete napodobit, napište sem vaše heslo v otevřeném tvaru a doufejte."
Proč bych heslo posílal v otevřeném tvaru a proč bych měl doufat? Vy jste výše žádal důvod pro hashování a uvedl jste ž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ý." Tak já chci, abyste mi dokázal, že pro hashování není žádný důvod a že přístup k DB s hashovanými hesly a k DB s plaintext hesly je to stejné.
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.
"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í."
Ne. Já diskutuji o tom, o čem je zprávička. To vy si vymýšlíte různé důvody,mkteré oak chcete obhajovat. Já od začátku jasně diskutuji o uložených heslech v plaintextu, ostatně jako všichni ostatní zde kromě vás.
"Protože tak to v reálném světě na drtivé většině webů funguje."
Ježíši... no a co? Co má společného mechanismus posílání hesel s tím, že útočník získá databázi? Odpovím sám: naprosto nic.
"Já se jenom podivuji nad tím, že spousta kritiků nehashování žádný relevantní důvod pro hashování nezná."
Tak buďto je tohle vaše vůbec první diskuze ohledně hesel, nebo trollujete. 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.
"Ale zatím jste se k tomu nepropracoval."
LOL :-D Tuhle směšnou hru na školení s vámi opravdu nepovedu.
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.
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é.
> 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é.
Poznámka: v tom případě musí být sůl dostatečně silná, ne jen pár znaků, jak se často používá. Kdyby to totiž bylo jen pár znaků, může si útočník najít svůj vlastní účet, u kterého zná heslo, a pak cracknout tu globální sůl.
> 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.
Třeba se tím útočníci jenom nechlubí :)
"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
"Pokud vám nevadí, že provozovatel serveru má vaše heslo a může si s ním dělat, co chce"
Nevadí.
"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.
"Takhle snadno dokázat, že máte pravdu, kdy zase budete mít takovou příležitost?"
Já nic dokazovat nemusím, důvody pro hashování jsou všeobecně známy. Vy jste tvrdil, že je jedno, jestli uniknou plaintext nebo hashovaná hesla, dokázat to neumíte.
Dál odmítám na toto trollování reagovat.
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.
"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í."
Upřesnění pro tupé: nevadí mi, že zná mé heslo, protože nikde jinde s ním neuspěje. Vadí mi, že ho ukládá v plaintextu, protože při úniku DB má útočník okamžitý přístup do mého účtu. Jsem naprosto 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."
Trololol... Důvody jsou zde uvedeny x-krát.
"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."
Dal jsem zde MD5, abyste se předvedl. Výsledek nikde, místo toho to začnete zamlouvat, že takhle to nefunguje a podobné výmluvy. Termín je naprosto jasný, je to u té MD5 popsáno dokonce včetně délky, takže zase jen výmluvy.
Tohle byla poslední má reakce, vy si tady klidně trollujte dál, jestli máte tu potřebu.
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.
Vy tady předvádíte to samé, co Jirsák, tedy vymyslíte si nějaké předpoklady nebo myšlenky druhých a s těmi pak polemizujete. Já se vůbec nedivím, že pak tomu, proč nemít hesla v plaintextu, nerozumíte. Pro příklad:
1. Já jsem tady nenašel jediný názor, kde by někdo tvrdil, že mu to opravdu nevadí. Tedy pouze váš předpoklad.
2. Tohle může vadit pouze těm, kteří používají stejná hesla na různé služby, jiný důvod, proč by to mělo vadit, si nedokážu představit.
3. Nevadí uložení do DB, vadí uložení v čitelné podobě.
4. Opět váš výmysl. Kde kdo tvrdil, že únik DB nevadí?
5. Stejně jako 4.
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í. A už mě nebaví to psát furt dokola jak pro blbečky.
"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ář).
"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."
No, možná tak pro vás, pro mě nikoliv. Já tady diskutuju o způsobu ukládání hesel a k tomu se také vyjadřuji. Až budu diskutovat o úniku databáaze, tak se budu vyjadřovat k tomu. Už jsem to tady psal 2x, evidentně to nestačilo.
"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."
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.
"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"
Tak já po 151. říkám, že diskutuju o ukládání hesel. Až bude diskuze o ostatních datech, budu se k tomu vyjadřovat. Ono totiž vůbec nemusí znamenat, že s přístupovými údaji uniknou i nějaká další data, klidně se může stát, že uniknou pouze přístupové údaje a útočníci, kteří budou mít hesla jak na stříbrném podnosu, se k těm dalším datům bez problémů dostanou.
"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?
"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í."
Minimálně se s ní přihlásí k té službě, ke které to heslo patří. Už jsem to tady psal taky několikrát. Asi je to nad vaše chápání, nevím.
"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?"
Ne, nechápete.
"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?
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.
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í.
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.
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.
"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."
Přestaňte laskavě takhle hloupě lhát, psal jsem tady různé důvody několikrát. Jste jen ubohý troll, kdybyste měl v sobě alespoň kousek cti a sebeúcty, nebyl by pro vás problém přiznat chybu.
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.
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".
"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."
Jirsák pochopitelně opět nechápe vůbec nic. Ne že by mě to překvapovalo :-)
Vy jste o SCRAMu nepsal v původním příspěvku vůbec nic! Ještě to tady tupě zopakujete, aby to bylo jó vidět. A když vám to někdo několikrát! řekne, tak "chápete", že on něco neví, musí toho hodně nastudovat a vůbec nic o tom neví. To je prostě neuvěřitelný cirkus :-D
"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?"
Zřejmě jsem jediný, kdo tady "trpí" něčím, čemu se říká představivost, ostatní technici jedlu v módu 0/1. Je tedy nad vaše chápání si představit, že uniknou pouze přihlašovací údaje. A ne, nikoliv "sofistikovaným" útokem, ale jednoduše proto, že se útočník k dalším datům prostě a jednoduše oním útokem nedostane, ale může se k nim dostat přihlášením na účty pomocí získaných plaintext hesel. Ó jak složitá myšlenka.
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á.
Technický dotaz:
Jsem majitel firmy, posílám po Karlovi hotovostní platbu řekněme 100kKč. Cestou ho přepadnou a seberou mu ru hotovost. Jaký je pro mě rozdíl, jestli jsou ty prachy v igelitce, nebo v příručním trezůrku?
Přesně to tady totiž řešíte. Ne jak zabránit čórce, ale to, jestli může zloděj jít rovnou nakupovat, nebo jestli se musí ještě zastavit v dílně. Nezajímá vás to, odkud lupičj dostal tip (= neošetřený chyby, kterýma se dostal na server), proč byl Karel sám (= chybějící bezpečnostní analýza), proč to nesl po setmění temným lesem (= nešifrovaná komunikace s klientem), proč to nešlo bezhotovostně (= k čemu vůbec to heslo v plain textu bylo),...
Chápu dobře, že důležitý je jenom to, jsetli pro lumpa bude plechová krabička problém nebo ne a příště pošlete stejnou cestou s prachama Lojzu, je to tak?
"Přesně to tady totiž řešíte. Ne jak zabránit čórce..."
OMG, asi mluvím hotentotstky. Já furt dokola opakuji, že řeším to, jak zabránit zneužití, POKUD UŽ K NĚČEMU DOJDE! Snažit se zabránit čórce je pro mě jasná věc, o tom jsem nemluvil. Zřejmě pro vás a další tady je "zabránění čórce" 100% ochrana a nic dalšího už se řešit nemusí, já tedy naopak s touto možností počítám a vždy se snažím udělat nějaká opatření na více úrovních. Neukládat hesla v plaintextu patří k jedné z nich a předpokládal jsem, že u profíků a nepatlalů je to samozřejmost.
"Chápu dobře, že důležitý je jenom to, jsetli pro lumpa bude plechová krabička problém nebo ne a příště pošlete stejnou cestou s prachama Lojzu, je to tak?"
Nikoliv. Neříkám, že hashovat hesla je nějaká všespása. Říkám, že je to znemožnění/znepříjemnění zneužití, když už k nějakému úniku dojde.
Pokud to přirovnám k tomu příkladu s penězi, tak pokud už peníze z jakýchkoliv důvodů pošlu v hotovosti, bude jistě lepší je poslat v trezoru a ještě přidat patronu se znehodnovací barvou. To ale neznamená, že se nebudu zajímat o okolnosti, jak se tady pořád někteří snaží naznačovat.
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?
Teda vám někdo tady řádně šlápnul na kuří oko :-D MD5 jsem ZÁMĚRNĚ použil jako jednoduchou a profláklou metodu hashe. Pokud vy jste z toho pochopil, že to považuji za nějaký vrchol bezpečnosti, tak je to trošku smutné. A fakt mi není jasné, jak bych si na tomhle mohl honit ego... no, třeba mi to vysvětlíte :-)
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.
"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."
Ale to snad není předmětem téhle diskuze a já jsem ani v nejmenším nikde nenaznačil, že hashování je všelék a že by se mělo rezignovat na nějaká další zabezpečení, nebo snad dokonce, že to nejde.
Přemětem diskuse bylo to, že někdo nabořil nějakou databázi. Autor zprávičky (nebo ten, kdo to pustil do světa) to osekal jenom na hesla. Takže to tady sklouzlo na úroveň "heslo hashovat nebo ne".
Přitom se decentně zapomíná na to, že ta DB asi nebyla vyexportovaná do CSV a hožená veřejně na uložto. A to je primární problém, ne formát dat. Taky můžu mít v autě čtyřbodový bezpečnostní pásy, ale raděj si tam nechám tříbodový a budu řešit lepší brzdy, protože pak jízdu přežiju nejenom já, ale i auto a dokonce opakovaně.
Primární problém je SQL injection :-) Chcete se bavit o tomhle? Já to považuji za házení perel sviním. BTW jsem za stejné házení považoval i NEukládání hesel, nebo JAKÝCHKOLIV JINÝCH citlivých dat v okamžitě čitelné podobě pro případ náhodného úniku (nic není bez chyb). Evidentně jsem se krutě zmýlil :-)
Tak to já budu tedy řešit čtyřbodové pásy, lepší brzdy a dokonce k tomu přidám i airbagy, protože budu předpokládat, že jelikož na silnicích nejsem sám, tak se může najít pitomec, který to do mě napálí.
Víte, dělal jsem několik let ve firmě, kde se na bezpečnost velmi dbalo, i přes téměř tisícovku zákazníků neměli za celou dobu existence jediný únik. Jakožto vývojář jsem byl za každou (stupidní) chybu či zranitelnost peskován a naučil jsem se o věcech přemýšlet. Do přemýšlení byli tlačení všichni tamní vývojáři. Dnes to považuji za samozřejmost. Ovšem jak tak koukám, není to samozřejmé ani náhodou.
U nás je to taky tak, docela nás v tomhle směru hlídají. Pěkně jsem se bavil při čtení diplomky studentíka z MITu, který si vybral zařízení, na kterým jsem dělal, pro demonstraci zranitelnosti IoT a zjistil jenom to, že je komunikace šifrovaná a s pomocí JTAGu nezjistil ani správný typ CPU, natož pak aby vyčetl firmware. A rozváděl teorie o tom, jak by to mohlo, ale nemuselo být...
Právě proto se divím, že taková diskuze tady vůbec vznikla. Já dát hesla v plaintextu, tak dostanu takovou sodu na koberečku, že bych měl minimálně měsíc noční můry :-)
No divím... už vlastně ne, když tady čtu třeba výplody Jirsáka, který je schopný se pořád dokola točit na MD5 a udávat to jako argument proti hashování, prostě když to někteří patlají, tak to nebudeme dělat vůbec.
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
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ší.
"Já to dělat nebudu, ale víte o tom, že brute force attack na MD5 vás vyjde na půl piva?"
No, 10 hodin na jednu MD5, to je při blbé tisícovce uživatelů více než rok, a to jde o ubohou MD5 bez čehokoliv dalšího. Srovnejte si to s okamžitým přístupem k plaintextu. BTW hodně štěstí s louskáním toho mého příkladu, pochybuji, že na to bude stačit 10 hodin.
Ne. Najít někde poučku o hashování hesel a slepě implemntovat je výchozí stav.
Mělo byto být tak, že se udělá SRA (Security Risk Analysis) a řeší se krok po kroku, co se může po...
Co vlastně řeší prostý hash? Když udělám hash na serveru a někdo si odposlechne heslo, tak se přihlásí bez problémů.
Když si udělám hash na klientovi, někdo si prostě odchytí hash a přihlásí se s jeho pomocí.
Pro zákazníka s ukradenou identitou je jedno, jestli to uteklo cestou, nebo z databáze.
Dokážu si představit situaci, kdy jsou hesla v DB plain text, nedá se k nim dostat (už bylo zmíněno, že tam může být ve virtuálu interní autorizační server a jsou i dlaší možnosti), odolný proti MITM s tím, že se v aplikaci pracuje se třemi parametry - user ID, passwordhash a salt. Jenom se u toho musí myslet a vědět, proč co dělám.
> Muzete najit X duvodu, proc mit hesla uzivatelu v plaintextu, ale zadny z nich neobstoji proti situaci, ktera se prave stala.
Zase obstojí v situaci, kdy útočník sleduje spojení, ale nemá přístup k databázi. Což vzhledem k „bezpečnosti“ SSL poslední dobou nemusí být vůbec nereálné. A teď si vyber.
Ti, kdož sdílejí víru že ukládat hesla v otevřeném tvaru není špatné, jsou naprosto mimo. Ano, ukládání hesel v otevřeném tvaru je jednodušeji implementovatelné, ale za cenu snížení bezpečnosti - a co je důležitější, bezpečnost nebo jednoduchost implementace? K použitelnosti s stávajícím XMPP - dá se dělat třeba to co dělá Dovecot, ten v databázi umí mít hash a přesto podporuje přihlášení při kterém po síti (i bez SSL/TLS) neběží plaintext - nastudujte si třeba http://en.wikipedia.org/wiki/CRAM-MD5 a vězte že pokud je potřeba podporovat více přihlašovacích protokolů, není problém mít uložených víc hashů (a při změně hesla aktualizovat všechny).
Mně připadá, že si s tím vývojáři Jabber serverů prostě nechtějí lámat hlavu. Například u Prosody jsem našel obsáhlý elaborát tvrdící mimo jiné, že DIGEST-MD5 vyžaduje uložená hesla v plaintextu.
Což je celkem zvláštní tvrzení vzhledem k tomu, že stejný mechanzmus u Dovecotu ukládání hashovaných hesel umožňuje.
Jako bonus je tam pak tvrzení, že:
This is a form of "mutual authentication", and gives the client confidence that it is connected to the right server, even if the connection is encrypted with an unverified certificate (it does not protect against eavesdroppers, however).
Tedy použitím DIGEST-MD5 máme jistotu, že někde na konci je server, který zná naše heslo. K čemu taková jistota je, když nevíme kolik mezičlánků komunikaci odposlouchává?
kdyz nekdo z db vytahne hash, kterym se muze prihlasit, tak se toto tyka jen te dane sluzby. utocnik ma v ruce muj login a heslo jen pro tu konkretni sluzbu. nedozvi se kombinaci login/heslo, kterou muze zkusit i na jinych sluzbach. ano, na kazdou sluzbu nam treba jine heslo, ale to je jina vec. proto je 100x lepsi mit v db heslo hashovane, byt se pomoci nej primo muzu ke sluzbe prihlasit, nez tam mit heslo v plaintextu. neni to nejdokonalejsi reseni, ale urcite je lepsi nez plaintext.
Tak hashe se dají louskat. Přeci jen hledat vstup když znáte výstup je úloha snadná. V případě MD5 až triviální, ale i tak to bude jen pár desítek hesel za hodinu.
Hashuje se z jiného důvodu - aby v situaci, kdy někdo tu databázi ukradne, neměl okamžitě hesla úplně všech uživatelů. Sbírání hesel pomocí "man in the middle" apod. zabere čas a funguje jen na uživatele, kteří se v té době přihlásí. Naservírovat útočníkovi databázi hesel všech uživatelů najednou je ale jiné kafe. Proto je použití hashe vřele doporučováno.
Doporučuji předpokládat, že se stažením databáze se útočník dostane i k návodu na výrobu soli.
Dobrá sůl vyřadí ze hry raindow tables, což je důvod, proč solit. A pak se tedy jen bavíme o síle hesla (pwd12345 dlouho neobstojí, je na seznamu běžných hesel a bude brzo ozkoušeno) a kvalitě hashe. MD5 má konflikty a dá se poměrně rychle najít text, který s danou solí povede na daný MD5 hash. SHA má sice také problémy, ale zatím bez reálné aplikace. To ale pro MD5 platilo asi do roku 2004 také.
Zkrátka, i to MD5 je lepší než plaintext. Ale zda SHA je se silným heslem 100% ochrana bych raději nedoufal. Po úniku databáze bych stejně ta hesla změnil. Právě to je ta ochrana, kterou zpochybňuji - hashovaná hesla dle mého názoru jen zpomalí útočníka. U silných hesel se solí dostatečně dlouho na to, abych si změnil heslo dříve, než ho stihne prolomit a zneužít (aneb proč se doporučuje každých 30 dní změnit heslo). Že navždy, tak o tom pochybuji. Přeci jen jsem vyrůstal v minulém tisíciletí, v dobách MD5. A byl pak několikrát nepříjemně překvapen. Ale i tak, rozhodně hashovat.
To, že útočník použitou sůl zná, je součást definice soli. Proto by také měla být sůl pro každý hash jiná a navíc náhodně generovaná.
MD5 je prolomené jen v případě, že útočník zná původní zprávu (což je problém třeba u digitálních podpisů), takže pro hashování hesel je stále bezpečné. Výpočetní náročnost SHA-1 hashů je ani ne dvojnásobná oproti MD5, a pokud má heslo méně než nějakých 20 znaků (128 bitů entropie), tak větší délka hashe stejně nepomůže. Samozřejmě je velmi důležitá délka hesla, osmiznaková hesla (alfanumerické + symboly) v MD5 i SHA-1 na dostatečně nové grafické kartě prolomíte za pár týdnů, dvanáctiznaková vám už zaberou milion let.
Nemusia byt hashovane a ide to spravit lepsie.
Podla mna web nema mat co pristup k heslam v DB. Na to IMHO staci overenie cez databazovu funkciu, ktora vracia 0/1.
Pomerne ucinne proti beznym utokom (mimo ovladnutie celej aplikacie) moze byt sifrovanie hesiel - potom pristup k DB nic neriesi, lebo heslo je sifrovane niecim, co je mimo DB.
Vyborna volba. Jeste bych do budoucna doplnil ukladat vsechny plaintext hesla na webovy server do /download/passwords.txt souboru a ta otevrenost je dokonala. Omlouvam se, ale pokud nekdo navrhne ukladat plaintext hesla, pak ho povazuji za amatera. A je uplne jedno jestli je to na urovni xmpp protokolu, nebo jabbim sluzby.
"However in the future when more clients support SCRAM out of the box the choice is clear.", takze je jasne videt, ze plaintext bezpecny neni...
Kdyz nekdo provozuje (navic i placenou) sluzbu, kde se pysni bezpecnosti, je tohle vazne katastroficke selhani, ktere ani zadny blby bastlic webu nedela.
Já neříkám, že hash je jediná správná metoda. Nicméně ukládat hesla v čitelné formě je prostě zhůvěřilost. Zavedu novou autentifikaci? Fajn, požádám uživatele o znovuzadání hesla. Pokud jsou tak líní si heslo měnit (ostatně správně by mělo být měněno poměrně často, prolomit se dá prakticky vše), tak je něco hodně špatně. :-)
Nevím jak u téhle služby, ale u "plain text služeb" bývalo zvykem hesla hashovat na serveru. V protokolu sice létaly plaintextem, ale v databázi byl hash. Odposlech komunikace tedy problém byl, ale dump databáze byl problémem jen u slabých hesel a nebo až po pár dnech. Dělala to tak řada služeb fungujících po telnetu. Podpora na straně klientu nebyla k hashování nutná.
A účel je jediný: pokud někdo tu databázi ukradne, tak nemá hesla ihned, ale musí je nejdříve uhodnout. Což před 15 lety i u MD5 znamenalo několik hodin na heslo. Dnes je možné použít SHA. Útočník tak v řádu dnů dokáže uhádnout jen pár slabých hesel, případně se zaměřit na jeden konkrétní účet.
Nevidím problém v tom, že ta hesla byla v plaintextu, ale že byla v plaintextu v SQL databázi. Třeba v LDAPu ať si klidně jsou v plaintextu, LDAP je ale bez extra autorizace (kterou pro nic kromě synchronizace a případně autorizace obskurním protokolem nepotřebujete a tedy ani nepoužíváte) nedovolí vytáhnout. Pokud by tohle SQL databáze taky uměly, nebyl by důvod pokládat plaintextová hesla v databázi za špatná. Jenže neumí, tak to chce s nimi podle toho zacházet.
Pokud ta stored funkce bude definovaná, že vrací boolean, tak jen spadne.
Chybu v oprávněních můžete mít a mnohem častěji také máte i pro PHP skripty a pak můžete hesla odposlechnout přímo na síti. Stejně tak buffer overflow. Zneužití těchto chyb v backendu je o několik řádů složitější.
Kolega s root přístupem může úplně stejně sniffovat síť nebo přihodit do webovky CSRF.