Jak bylo v clanku zmineno o sifrovani hesel, blahovy je ten, ktery je uklada v plaintextu. Pro uzivatele, ktere neco takoveho nenapadne je toto pomerne velkym bezpecnostnim rizikem, protoze spousta lidi si dava stejna hesla a kdyz ho nekam ulozim v plaintextu, tak pak jako bych ho vyvesil primo na webu (temer). Kazdopadne ho muze zneuzit administrator DB!
Administrator ho muze zneuzit v kazdem pripade, i kdyz je sifrovane. Jen je to o malinko tezsi, nez kdyz je plain. Nebezpecim je spis unik plain hesel pri neopravnenem pristupu do databaze. Ale i kdyz jsou hesla sifrovana, tak si moc nepomuzete, protoze spousta uzivatelu ma takova, ktera jdou vylouskat slovnikovym utokem :-|
A ze jsem tak smely, jak nebohy uzivatel, ktery akorat chce vyuzivat nejakou webovou aplikaci zajisti, aby system hesla ukladal kryptovane? ;-)
Podle me ma akorat prave tu moznost, pouzivat ruzna hesla. Jinak bych si dovolil zminit, ze pekna serie o nabouravani PHP skriptu vysla jiz na intervalu.
Jinak souhlasim s autorem clanku, ze toto nebezpeci je neustale treba pripominat, protoze je az neuveritelne, jak casto se prave v kontrole dat od uzivatele chybuje.
Zakladny a jednoduchy krok ku kryptovaniu hesiel je pouzivat MySQL-funkciu PASSWORD(). Pri vytvarani noveho uzivatela sa heslo ulozi v kodovanej podobe a neskor uz nie je potrebne toto heslo vobec citat.
INSERT INTO user SET login='uzivatel', password=PASSWORD('heslo');
Pri prihlaseni sa potom porovnava ulozene zakodovane heslo so zadanym heslom, ktore prejde funkciou PASSWORD:
SELECT login FROM user WHERE login='zadany_uzivatel' AND password=PASSWORD('zadane_heslo');
ak je heslo spravne, tak to vrati jeden riadok. Vyhoda tohoto systemu je, ze ani administrator nemoze odhalit (v realnom case dostupnou vypoctovou kapacitou) ulozene hesla. V pripade, ze uzivatel zabudne svoje heslo, je vsak jednoduche jeho heslo zmenit na nahodne vygenerovane, poslat mu ho mailom a poziadat ho, nech si ho okamzite zmeni:
UPDATE login SET password=PASSWORD('nove_heslo') WHERE login='zadany_uzivatel' AND password=PASSWORD('nahodne_vygenerovane_a_zadane_heslo');
ech. Blbost! Jak chcete aministrátorovi zabránit aby si po každém zavolání
SELECT login FROM user WHERE login='zadany_uzivatel' AND password=PASSWORD('zadane_heslo');
v případě úspěchu uložil dvojici 'zadany_uzivatel' a 'zadane_heslo' přímou úpravou PHP aplikace. Nijak. Tož a tak je to se vším. Když ještě uvážím, že administrátor může být v určitou chvíli 'administrator' tak jsou hesla uložená v db v pr.. tak jako tak bez ohledu na to jestli jsou v plain, nebo ne. Jediné co se změní je míra průniku. Je to stejné jako udělat patch na login, nebo odchytávat stisknuté klávesy. Zkrátka jediné správné a obecně platná pravidla zní: 1/ Pro různé služby !vždy! používat různá hesla. 2/ Proti administrátorovi neexistuje neprůstřelná ochrana.
Tak tak,
stejne jako Buh je i Administrator, ve vetsine soucasnych systemu vsemocny. Proto se zavadi Auditor, ktery vladne nad vsemi Administratory, ale nema zadna prava vuci sluzebnictvu (alias BFU).
seth
Mluvilo se o administratorovi databaze. Ja treba v praci provozuji webowou aplikaci, pouzivam databazi kterou ale administruje nekdo jiny. Ani nevim kolik ruznych lidi vlastne k te databazi ma pristup. Protoze ale hesla jsou sifrovana, tak mi je to v celku jedno. Takze smysl to ma. To same plati i na ruznych webhostincich a podobne.
Navic u me se sifrovane odesli uz heslo z prohlizece, navic pokazde v jine podobe a v databazi je tak uz vlastne dvojnasobne zasifrovane. Nabourat takovy mechanizmus uz da vice prace, musi se tomu rozumet a musi byt pristup ke zdrojakum. U PHP je to problem i kdyz by take bylo mozno napr. sledovat jejich CRC32. Je-li aplikace napsana napr. v Pythonu, tak tam staci mit jen kompilovane objekty a ty se modifikuji uz velmi tezko, prakticky to je nemozne.
Nějak nechápu ten váš první odstavec. Co to řeší? Když dělám tu aplikaci, tak můžu udělat cokoliv. Z toho vyplývá, že je úplně šumafuk kdo administruje databázi. Ten administrátor databáze mi dal nějaká práva abych mohl udělat výše uvedený dotaz a uživatel mi dal důvěru. Co chcete víc? Jediné řešení je auditing kódu aplikace a zdravá dávka skepse a nedůvěry, nebo důvěry.
a hele, dalsi lame admin, PASSWORD se neodporucuje pouzivat - totiz v pripade mySQL 3 a 4 to sifruje na jinou delku - je to funkce pro vnitrni potrebu mySQL. Misto toho je lepsi mit MD5, SH1 a sifrovani provadet na strane PHP - to vyplyva z toho ze data mohou putovat po spojeni s mySQL taky v plain textu.
vice na http://www.mysql.com/doc/en/Password_hashing.html
v odstavci
4.3.12 Implications of Password Hashing Changes for Application Programs
Tak nejak mi prijde volani md5(passwd) nebo sha1(passwd) vicemene nesmyslne ... :-/
Myslim, ze to je srovnatelne s volanim crypt(passwd, 'aa') ...
Kdyz se podivate na zdrojaky md5-crypt treba v glibc, zjistite, ze to neni ubohe md5(passwd), ale je to slozitejsi (a osolena) transformace vyuzivajici jako zaklad md5. A pokud vas zajimaji duvody, google je kamarad.
ČLÁNKY DO MAILU