Starší komentáře ke článku: Salted hash - další krok ke zvýšení bezpečnosti
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 10.2.2005 11:52:59
To, že uživatele maji po hashi stejná hesla zjistím až tehdy, když se přímo dostanu do databáze. Ostatně, stejně až v momentě, kdy se dostanu do databaze zjistím, jestli je heslo kodované nebo není. Jenže, už to že se mi někdo NABOURAL DO DATABÁZE je přece průšvih! Pokud mi někdo čte nebo dokonce přepisuje přímo databázi, tak už to je samo o sobě ohromný problém, ne? Sorry, ale za situace kdy se mi někdo neoprávěný hrabe v databázi jsou uživatelská hesla to poslední co mě zajímá! Už i proto že i pro 'zloděje' jsou užitečnější kontakty na klienty, uskutečněné objednávky, databáze se zbožím a podobně. >Všichni uživatelé mají totiž heslo úplně stejné. Bez saltu je to jasně vidět. Kdyby hacker získal heslo Pepy, měl by rovnou hesla čtyř osob. Použijeme-li salt, musí, chce-li mít všechna hesla, zjišťovat dál analogickým způsobem - přes hešovací algoritmy.
Datum vložení: 10.2.2005 12:21:55
<i>Jenže, už to že se mi někdo NABOURAL DO DATABÁZE je přece průšvih! Pokud mi někdo čte nebo dokonce přepisuje přímo databázi, tak už to je samo o sobě ohromný problém, ne?</i> Obecně máte pravdu, nicméně u hesel se na to takhle dívat nelze. Uživatelská hesla by totiž neměl mít možnost číst ani ten, kdo má k databázi legální přístup (administrátor, provozovatel), a není k tomu ani žádný zvláštní důvod.
Datum vložení: 10.2.2005 13:09:30
presne tak.... ale nekdy nejde treba ani o to, ze ma nekdo pristup do databaze fyzicky, ale staci treba sql-injection s dotazem na vypis jmen a hesel. Pristup do databaze utocnik nema, ale hesla by ziskal.... samozrejme ze zaklad je eliminovat pristup k datum, to vsak neznamena ze to tim konci!
Datum vložení: 11.2.2005 9:33:49
jaky je rozdil mezi fyzickym pristupem k databazi a sql-injection? pomoci sql-injection JE v db! = stejne velky problem jako kdyby mel pristup grantovan loginem/userem nekdo neopravneny. vysvetlete jak jste to myslel - nejak mi to nejde do hlavy jaky je v tom rozdil...
Datum vložení: 11.2.2005 14:54:15
nojo, rekl jsem to trosku divne... omlouvam se :) Rozdil v tom temer neni, jen jsem chtel rozsirit objekt prispevku predchoziho o vic "cumilu" do db... Jisteze pokud aplikace neni odolna proti injection, muze byt vse v haji :( a utocnik muze mit temer neomezeny pristup do db (da-li si tim trochu prace). Jde proste o to, ze byste nikdy nemeli spolehat na to, ze data nikdo nebude cist...
Datum vložení: 15.2.2005 22:47:35
Na uvod bych chtel rict, ze prestoze procitam uz 2 mesice knihu Jeff Prosise Webove aplikace v .NET a k tomu jeste tisice clanku tady na intervalu povazuju se za asp.net novacka a jestli vubec to, takze mozna je muj dotaz az naivne detinsky ; prechod z klasickeho ASP je hodne bolestivy, ale taky se hodne vyplati tedy ten dotaz: sql injenction v .NET, jak provest? pracuju s mySQL(uz jenom pro moznost trivialniho strankovani, narozdil od mssql), kde po zakonceni prvniho sql prikazu pomoci ";", dle me zkusenosti, muze byt napsano cokoliv a stejne se to neprovede, protoze se provadi pouze jeden dotaz resp. prikaz a dalsi vec, jak se divam na repeater a v podstate i na datalist a datagrid, tak jsou vsechny nalinkovany pres DataBinder.Eval(Container.DataItem, "Jmeno_Uzivatele"), to znamena, ze se vazou pres pojmenovani sloupcu, nevim jestli se da uzit indexu sloupce a proc by se pouzil, mozna pro zvyseni vykonu, ale kdyz pouziji jmenne pojmenovani, tak je to v podstate neprekonatelna prekazka, nepletu-li se ? Jeste me napadlo, ze bych v SQL dotazu mohli pouzit rekneme SELECT Heslo AS Jmeno_Uzivatele, coz by slo, ovsem to opet narazime na problem zda-li se spousti jeden ci vice sql prikazu, no nicmene pokud tedy utocnikovi dovolime spustit vice dotazu, stejne narazi na problem, ze musi znat puvodni pojmenovani sloupcu, jejich typu a jejich pocet, aby uspesne rekneme vykompenzoval nalinkovani v asp.net no tak sem si vlastne i castecne odpovedel sam, presto bych rad znal nazor i nekoho jineho, rekl bych .netove zdatnejsiho ;-)
Datum vložení: 15.2.2005 23:19:03
Jsem se musel znovu pripojit a doplnit svoji vypoved ;-))) napadlo me jeste, ze uz v code behind casti pokud se mi tedy podari prinut system, aby provedl dva dotazy a zapsal je rekneme do datasetu, presto me tvurci webu staci, aby pri bindovani treba k datagridu uzil .Tables[0], cimz ten druhy dotaz je sice vykonan, ale presto ztracen, ted nemluvim o tom, ze by to mohl byt dotaz, ktery treba vraci "nekonecne" mnoho zaznamu a zahlti tim server, divam se na to spravne? nebo ten druhy dotaz prekryje prvni a v datasetu je pouze jedna tabulka ? a jeste me napadlo, ze bezpecnostni dira vznika taky pri zmene hesla nejakeho registrovaneho uzivatele, pokud neni overovaneho SessionID (termin z ASP, v ASP.NET zatim nevim, jak se jmenuje a zda-li je vubec vhodne uzit takoveto overovani a neuzit radeji IsAutheticated, to jsou takove drobnosti, o kterych bohuzel nikdo nepise, ale ktere utvareji tu mozaiku, tedy pro ty, co prechazeji z ASP) pokud totiz nekdo uzije nestastne formy uzivatele.aspx?akce=zmen_heslo&iduzivatele=xx a neoveri pri provadeni skriptu zda-li to iduzivatele odpovida tomu danemu uzivateli, tak potom se jedna o velkou bezpecnostni diru, to je fakt nicmene presto vsechno, co jsem zde napsal, jsem dosti skepticky a moc bych se sql injenction nebal, uz jenom proto, ze ole db, odbc atd poskytovatele moc nepodporuji dva a vice sql prikazu v jednom sqlcommandtextu, ale rad se necham presvedcit, ze me zavery jsou chybne P.S.: nekdo by mohl zkusit napsat nejaky clanek o tom jak prejit z asp na asp.net, treba v bodech, treba overoval-li jsem uzivatele pomoci sessionID pouziji nyni IsAuthenticated nebo pokud jsem k databazi pristupoval v asp dbConn.Open strConn, dbRS.Open strSQL, dbConn, if not dbRS.EOF then varRS=dbRS.GetRows, dbRS.Close, dbConn.Close prevedu to na ..., hlavne ta hospodarnost uziti db, kdy pripojit, kdy odpojit, kam ulozit zaznamy, abych hnedle mohl uvolnit connection do db atd... jak rikam tohle jsou drobnosti, ktere aspon mne a myslim si, ze nejsem sam, rozhodne pomohly
Datum vložení: 18.2.2005 16:55:09
Vicemene mate pravdu, co se tyce sql-injection obecne na .netu, byva nekdy tezsi napsat "neodolnou" aplikaci nez odolnou...framework se vicemene snazi, udrzet programatory v bezpecnych mezich, ne ale vzdy... je to tema na cely clanek, ne jen na diskuzi :), ale obecne pravidlo pravi, ze byste meli co nejmene vyuzivat ad-hoc sql-commandu, lepsi (i vykonnejsi) byva pouziti ulozenych procedur primo na sql servru. co se tyce clanku o prechodu z asp na asp.net, myslim si, ze je efektivnejsi zacit uplne od zacatku a nekonfrontovat obe platformy.... jista uroven konfrontace asp a asp.net je myslim v knize asp.net za 21 dni, ale ja jako byvaly aspckar jsem pasaze o srovnani stejne necetl.... :(
Datum vložení: 13.2.2005 16:22:13
Ano, presne... hesla by nemal vidiet ani administrator apod.. Mnozstvo ludi pouziva stale to iste heslo ku svojim emailovym uctom, k pristupu na portaly a podobne ;-) Takto by mal administrator pristup skoro vzdy "skoro vsade".
Datum vložení: 10.2.2005 13:12:30
ja ale nerikam, ze by se mela kryptovat pouze hesla, pokud ale chcete zabezpecit konktakty a podobne zalezitosti, mel byste pouzit spise nektery z sifrovacich algoritmu, u kterych budete schopen ziskat puvodni hodnotu zpet....
Datum vložení: 15.3.2005 19:03:20
Není nutné, aby se vám někdo naboural do databáze - ten hash totiz musite poslat po siti, coz se da pochopitelne odchytit (pokud nepouzivate SSL apod.)
Datum vložení: 14.3.2005 16:50:18
Dobry den! Zajimavy pohled na praci s citlivymi daty, ale osobne bych ho vubec nedoporucil. Jedna se o pomerne dosti naivni pristup ke koncepci ochrany hesel v ramci systemu. Je to pomerne komplikovane tema a zavisi na konstituci systemu, ale i tak jsou k tomuto jiz dane technologie a zaroven kryptograficka schemata. Pokud budu mluvit o jiz dnes hodne opakovanem tematu, tak jim je DPAPI. Pokud ale nebudete chtit vyuzivat DPAPI, je mozne dalsi ochranu vazat take na LSASS pripadne pokud budu mluvit o ochrane citlivych informaci v prostredi, kam ma utocnik plny pristup, tak tomu se venuje tzv. mobilni kryptografie. Proto tento popsany zpusob ochrany hesel (a citlivych udaju vubec) je velmi naivni a z pohledu kryptografie a bezpecnosti je nedoporucovan. To jen kratky komentar a pokud nekoho zajima vice, tak me muze kontaktovat na mailu a nebo navstivit nekterou z mych prednasek na toto tema. Hezky den, Jan Seda
Datum vložení: 14.3.2005 23:30:16
Dobry den, cenim si prispevku nekoho z microsoftu :) O toto tema zajem mam preveliky :) Jen neznam maila a co se tyce prednasek, zatim jsem mel jen tu cest tusim na nekterych konferencich microsoftu, a advanced .net jsem bohuzel nestihl :) ale co jsem zatim cetl o tomto tematu (i texty od zamestnancu microsoftu), nikdo se nevyjadroval takto negativne (spise naopak) a i novy framework vyuziva saltedhashe ve svych providerech (alespon v me verzi frameworku). Byl bych tedy rad, kdybyste me kontaktoval, rad bych podiskutoval na toto tema :)
Datum vložení: 15.3.2005 12:14:33
To mate pravdu, salted hash je spravny postup, ale jde o to v jakem to pouzijete kontextu a s jakym cilem. Jak vyplyva z kryptologickeho popisu salt, tak to je pouze obrana proti klasickym (primarne offline) utoku pomoci tzv. precomputed databases. Tam je pak jiz jen otazkou nekolika milisekund najit odpovidajici heslo vuci hash, proto je zaveden pojem salt a proto je take definovana PKCS5 a doporuceni RSA Laboratories na to, jak a kolik iteraci je minimalne nutne provest pro spravnou praci a "zamaskovani" hesla. Vaseho prispevku si velmi vazim, ale preci jen musim upozornit, ze jsou jine postupy, ktere bych Vam doporucil. Tohle muzeme tedy klidne probrat na Microsoftu a nebo pokud budou mit i ctenari zajem, tak at me kontaktuji na emailu jseda at microsoft.com. Preji hezky den.