Vlákno názorů k článku Jak silná nebo slabá jsou vaše hesla? A dokážete si je zapamatovat? od randomofamber - "Sůl bývá uložena v databázi s hashi..." Jistě,...
-
"Sůl bývá uložena v databázi s hashi..." Jistě, ale pokud se sloupec přímo nejmenuje "sůl", jak útočník pozná, který ze sloupců ze všech možných tabulek v databázi je používán jako sůl? Co když někdo používá jako sůl odpověď na kontrolní otázku nebo část emailové adresy a podobně... Někdy se spolu s heslem pro vytváření HASHe spojuje heslo a jméno nebo heslo a jméno a příjmení... Útočník by se musel dostat ke zdrojovému kódu stránek, který už nemusí být tak snadno dosažitelný a teprve pak by mohl zjistit jak je HASH tvořen... Nezná-li útočník algoritmus vytváření zdroje textu pro HASH má velmi malou šanci zjistit patřičný HASH...
-
Pořád to nechápete. Já nejsem útočník, který myslí nabourání se do vašeho systému vážně. Řešíte, jak těžké je lámání hashů hesel. Jak už napsal Filip, problém zde neleží. Problém leží v tom, že se vůbec k těm hashům dostanete, a pravděpodobně nejen k nim. Dostanete se k soukromé komunikaci, emailům, časům přihlášení. Jako autor musíte chránit celou databázi, nikoliv jen plaintext hesla. Hash je jenom záchranná brzda, ale při děravé aplikaci to nevytrhne sebelepší fligna. Když jsem se dostal k databázi, proč spoléháte na to, že do obsahu souborů se dostat nedokážu? Pokud to dokážu, váše zlepšováky jsou k ničemu. Prostě CELÝ systém musí odolávat napadení, nejen uložení hesla. Trávíte čas detaily, které žádnou speciální bezpečnost neposkytují. Přitom se nezabýváte tím, kde máte jiné díry. Bezpečnost není jen otázkou hesla, je to komplexní problém. Pokud jsem schopen zblbnout vrstvu, která z plaintextu vyrábí ten váš superbezpečný hash, je celé vaše snažení pro smích. Pokud zbytek funguje dobře, zase jenom zdržuje generování hashů.
-
NN (neregistrovaný)
Príklad OpenSource webová apka, kde je algoritnus výpoštu odtlačku verejný. Ak má jednu časť reťazca soli uloženú v súbore, zabráni to prieniku v prípade, ak útočník dumpne databázu. Bude na úspešné prelomenie systému bude okrem úniku databázy potrebovať ešte úspešný útok na súborový systém, čo je ďalšia prekážka. Podľa mňa to význam má.
Utajenie soli tiež priamo znemožňuje útok hrubou silou na databázu hashov. Alebo chcete tvrdiť, že je rovnako náročné lámať databázu md5 hesiel, ako md5 hesiel osolených 50 znakovou soľov ak nepoznáte algoritnus solenia? Napríklad: md5( left(salt,35) . heslo . right(salt,15)) );
Alebo ak algoritmus poznáte, ale nepoznáte tú 50 znakovú soľ?
-
Tajit algoritmus výpočtu hashe je naprostý nesmysl. Už ve druhé světové si ověřili, že důležitý není na enigmě. Důležité a zásadní je tajit data k algoritmu - klíče.
Už několikrát jsem narazil na podobnou pseudo bezpečnost, kterou tu předkládáte. Salt MUSÍ být generovaný náhodně ke každému heslu. Salt nesmí být pevně uložený v jednom souboru a stejný pro všechna hesla, jinak je jeho bezpečnost relativně slabá.
Pokud už vám někdo dumpne databázi, máte velký problém. Řešit to přidaným saltem je možné, ale zabezpečení tohoto je spíš virtuální. Prostě musíte zabránit dumpnutí databáze, při možnosti číst nebo modifikovat databázi beztak útočník může dělat všechno, aniž by potřeboval se přihlašovat.
Nicméně pokud by salt byl statický, stačí vám zlomit z celé databáze jediné heslo. Což není tak nemožné, určitě najdete alespoň jednoho uživatele s velmi slabým heslem. Dál už víte, že stejné části jsou všude stejné. Takže jediné, co to zabezpečí, je první hash na prolomení.
Jediný smysl to dává v případě, že máte jeden saltc v konfiguraci v souboru. Potom máte saltu, který je pro každého uživatele vygenerovaný náhodně. A teprve kombinací těhle dvou solí s heslem získáte něco použitelného. Tím vaším způsobem rozhodně ne. A vážně nehraje roli, jestli přidáte kus na začátek a kus na konec, akorát to ztěžuje chápání algoritmu.
-
NN (neregistrovaný)
Nech sa páči, pmocou bling SQL injection na webe ste sa dostali s hashom:
0a01c923e9989d65e0e64f0eec8ce589
29e705f646c9b8d47676fd79f838d48bPrezradím Vám, že heslo má 7 znakov, len nalé veľké písmená a číslice. Slovníkovému útoku ani hrubej sile prvý hash neodolá. Druhý odolá.
Prvý hash je neosolený, druhý osolený saltom, ktorý nie je v databáze a nemôžete ho dupmnúť pomocou zraniteľnosti, ktorou ste sa dostali k hashom (Blind SQL Injection).
Ukážte mi, že to nemá zmysel a prelomte to, bez použitia toho prvého hashu aj druhé heslo, ktorého zložitosť je rovnaká:
713b276e7fb3793ba833804fdb319f7a
;-) prajem príjemnú zábavu. -
NN (neregistrovaný)
<cite>
Ještě k tomu saltu. Pokud si v databázi vytvoříte svůj účet s heslem, které znáte, zjistit, jak ho zamíchali před hashováním nebude příliš složité.
</cite>OK, pre Vaše heslo Petr je hash takýto:
73605cd42b4f96f0d33dc35cf20c4861
poprosím si heslo k hashu:
713b276e7fb3793ba833804fdb319f7a
;-)
Algoritmus poznáte. Je použitý nevhodný alrogitmus s md5.
Ukážte mi prosím, čo je podľa Vás "nie príliš zložité". -
NN (neregistrovaný)
Potrebujete nakopnúť?
http://www.root.cz/clanky/tunely-v-hasovacich-funkcich-kolize-md5-do-minuty/
Určite sa to pre md5 dá, ale zas tak úplne triviálne a jednoduché to nebude… ;-) a ak by som miesto md5 použil sha512 tak môžete snívať… -
NN (neregistrovaný)
Ja to chápem veľmi dobre, nechápete ma Vy. Je mi jasné, kde je problém a čo ako autor webovej apky musím robiť a ako. V tom sa absolútne zhodneme.
Ja sa ale bavím o tom, že ak už hashe z databázy niekto dostane, najčastejšie a typicky zneužitím bling SQL injection, salt v súbore zabráni napriek diere v apke prelomeniu účtu. To je celé a preto tvrdím, že nápad s hashom mimo databázu nie je úplná blbosť ako tvrdíte. Zo skúseností s útokmi to hodnotím ako nie zlý nápad. Nejde tu totiž len o kód ktorý máte vy ako autor pod kontrolou. Berme ako príklad nejaký modulárny syustém, kde si na Vámi vytvorenú a dobre zabezpečenú aplikáciu žívateľ nainštaluje deravý modul vlastný alebo tretej strany, ktorý má SQL Injection. Tým že v takomto systéme použijete ten hash mimo databázy, zabránite úspešnému vedeniu útoku na Váš systém, cez deravý modul tretej strany. Toto je dosť častý scenár, nie nejaká fantazmagória. Nebavme sa o tom, že primárne je chyba v tom deravom module s SQL injection, ktorý by deravý byť nemal. To je bez debaty. Bavme sa o tom, že aj v takomto prípade máte ako autor aplikácie možnosť ako zabrániť úspešnému vedeniu útoku ak pri chybe v module tretej strany.
Nemusíme sa tu baviť o tom, čo bude ak sa útočník dostane k súborom na úrovni filesystému, pretože to už nepotrebuje nič. Má absolútnu kontrolu nad aplikáciou a dostane sa k službe aj bez lámania hashu, heslá si kľudne odchytí pri logovaní userov a pošle si ich, nepotrebuje už nič lámať, zmení si priamo výkonné scripty.
-
Podle mne je nejdůležitější vůbec nikdy nepředávat hesla v otevřeném tvaru nebo jeho ekvivalentu serveru. Technicky je to triviální, prakticky tomu brání jen chybějící standardy. Evidentně totiž bezpečnost zajímá jen hrstku lidí, ostatní místo ní řeší obezličky typu solení hesel.
Na straně provozovatele je pak druhou nejdůležitější věcí to, aby se útočník nedostal k databázi.
Solení hesel je jenom taková obezlička pro případ, kdy není splněn první odstavec a nepodaří se zabránit druhému. Při „kvalitě“ dnešních webových aplikací ať radši každý hesla hashuje a solí, ale je dobré mít na mysli, že to není žádné zásadní bezpečnostní opatření, ale nouzová záplata jednoho detailu v případě, kdy je ta aplikace děravá jak řešeto.
-
Petr (neregistrovaný)
Tohle je jen varianta security through obscurity. Bezpečnost, kterou lze nějak významně posílit tím, že algoritmus bude tajný, je iluzorní. V ideálním případě se bezpečnost malinko zvýší; v realistickým případech se zhorší.
Utajení soli neřeší žádný problém, který by neřešila už dostatečně dlouhá sůl.
-
Můžete mi objasnit tu část o statické soli a rozlousknutí jediného slabého hesla? Konkrétní příklad: Mějme uživatele zuzanka s velmi slabým heslem zuzanka. Hashovací algoritmus je md5( left(salt,35) . heslo . right(salt,15)) a pro zuzanku je hash 0c0e48fc7192656605208fc06d01c03d. A teď mi řekněte heslo uživatele s hashem fc70749842b417eb45a91f02026cdfa1.
Máte sice pravdu, že v případě statické soli stačí rozlousknout jediné heslo, jenže to nespočívá ani tak v uhodnutí toho hesla jako v uhodnutí té padesátiznakové soli. A tu už si nemusí nikdo pamatovat, takže je to náhodný řetězec, omezíme-li se jen na alfanumerické znaky, dělá to nějakých 4E89 kandidátů. Přeju hodně štěstí a trpělivosti.
Problém statické soli je, že pro různé uživatele se stejným heslem vrací stejný hash, takže když rozlousknete heslo zuzanka (třeba tak, že předtím, než ukradnete databázi hashů, si uživatele s takovým heslem založíte), víte, kdo všechno toto heslo použil. Ale o jiných heslech Vám to fakt nic neřekne.
ČLÁNKY DO MAILU