Dotaz: MySQL ENCRYPT - jaká funkce v PHP ?

[Petr Maleček]

Zdravím všechny,

dotaz - v MySQLku my dotaz

SELECT ENCRYPT('nějaké-heslo')

vrátí asi takovýto řetězec:

MeXkFnYUhP7cw

Jakou funkcí v PHP dosáhnu stejného výsledku ? Koukal jsem na mcrypt, crypt, ale stejně jsem nenašel tu správnou

Díky za radu.

Odpovědi

[Kit]

K čemu potřebuješ stejný výsledek? Pokud šifruješ v MySQL, ověřuj také v MySQL. Pokud šifruješ v PHP, ověřuj také v PHP.

Kromě toho se doporučuje v MySQL spíš využít funkci password().

[Petr Maleček]

Na svém serveru mám postfix, který ověřuje uživatele naproti databázi, kde jsou ta hesla šifrována pomocí mysql encryptu. Píšu si jednoduchý nástroj na změnu hesla uživatelem, a proto bych chtěl vědět, jakou funkci na toto využít.

Je mi jasné, že můžu při ověřování původního hesla porovnat, jestli encrypt uživatelem zadaného hesla je schodný se současným řezězcem za pomocí mysql dotazu, ale to mi přijde takové těžkopádné.

[Filip Jirsák]

To není těžkopádné, ale naopak jediné správné řešení. Funkce encrypt() v MySQL je definovaná dost vágně na to, aby mohla být implementována někde jinde ještě jednou a bylo zaručeno, že obě implementace budou vracet vždy stejné výsledky.

[l0gik]

Navíc stejně do tý databáze pro to heslo musíš, ne? Takže místo SELECT * FROM .... WHERE ... uděláš SELECT *, password = ENCRYPT(vstupoduzivatle) as spravneheslo FROM ... WHERE ... a je to. Nevidim kde je problém. Nebo taky SELECT * FROM ... WHERE password = ENCRYPT(vstupoduzivatle) AND ... podle toho, na co to potřebuejš...

[Kit]

Jeden drobný problém tam je: Při ověřování potřebuje funkce encrypt() i druhý parametr. Nějak se na něj zapomíná.

Jinak je samozřejmě nesmysl tahat zašifrované heslo z databáze a snažit se ho porovnávat v PHP. Na to máme SQL.

[l0gik]

Jo, v tom máš pravdu, bez soli je to nesmysl.

Tak mě napadá, nevíte, k čemu vlastně ta varianta na volání bez soli tam vůbec je? Nějak mě nenapadá, k čemu ji použít (na generování náhodnejch čísel jsou lepší postupy).

[Kit]

Bez soli si tu sůl náhodně vygeneruje. Zkus si opakovaně spustit:

SELECT encrypt('heslo');

Pokaždé to vygeneruje něco jiného. První 2 znaky jsou použitá sůl. Když výsledek uložíš do sloupce např. password, tak pro ověření stačí:

SELECT encrypt('heslo',password)=password;

Z uloženého hesla password použije jen první 2 znaky.

[Kit]

Ještě pro zajímavost: Funkce encrypt() bere z šifrovaného řetězce jen prvních 8 znaků, zbytek ignoruje. Možná proto je místo ní doporučena funkce password(), která bere v potaz všechny znaky.

[l0gik]

Jo jasně, ono to tam tu sůl přidá, pak jo. Já tu fci snad nikdy nepoužil, radši šifruju něčím, co aspoň vím jak šifruje.

[EsoRimer]

The PASSWORD() function is used by the authentication system in MySQL Server; you should not use it in your own applications. For that purpose, consider MD5() or SHA1() instead. Also see RFC 2195, section 2

Viz: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html#function_password

[Petr Maleček]

Díky za odpovědi, už jsem tu logiku překopal tak, že je vše řešeno přes mysql, jak mi bylo zde napovídáno :) vše funguje, skvěle :)

Bohužel jsem nějak nepřišel na to, jak ověřit, zda zadávané heslo uživatelem odpovídá heslu po encryptu MySQLkem (jak víte, pokaždé je řetězec jiný), tak jsem zavolal na pomoc přímo fci imapu v PHP - viz:

// overime existenci mailove schranky
    if ($db->query("SELECT email FROM users WHERE email = '$_REQUEST[email]'")->num_rows) {
      
      // overime spravnost zadaneho hesla, bohuzel musime primo imap pripojenim, protoze funkce encrypt v MySQL vraci pokazde jiny retezec
      if ($mbox = @imap_open("{127.0.0.1:143/notls}", $_REQUEST['email'], $_REQUEST['old-password'])) {   

... 

Abyste chápali čeho jsem chtěl dosáhnout - chtěl jsem umožnit uživatelům měnit heslo do jejich schránky.

[Šangala]

Jen pro info, vrací různé hodnoty, protože náhodně generuje „salt“.
Např.

SELECT (ENCRYPT('ahoj','AB'));

Dá vždy stejný výsledek.

A když juknete na následující, tak zjistíte jak to lze porovnat:
Použil jsem řetězec 'TGlcRH68Dkg3g', kterýžto vznikl jako

ENCRYPT('ahoj','TG');

(respektive jako ENCRYPT('ahoj'), kde se náhodně vygenerovalo to 'TG')

SELECT CASE WHEN 'TGlcRH68Dkg3g' = ENCRYPT('ahoj',SUBSTRING('TGlcRH68Dkg3g',1,2)) THEN 
       'rovna se to' 
      ELSE 
       'NErovna se to' END  AS result;

Prostě si musíte vzít ty první dva znaky z uloženého encrypt-ovaného řetězce a použít je jako salt.

PS: Ale samozřejmě nenabádám k používání fce ENCRYPT() - ba naopak .

[Kit]

Však jsem tu podmínku psal:

encrypt('heslo',password)=password

Jako druhý parametr dáš to šifrované heslo v databázi.

[Šangala]

Jo jasně, protože fce ENCRYPT() bere jen tolik znaků kolik potřebuje, takže ten SUBSTRING() co jsem psal výše, je naprosto zbytečný až špatný.

[EsoRimer]

Doufám, že je tenhle kus kódu zjednodušený jen pro ukázku ..

if ($db->query("SELECT email FROM users WHERE email = '$_REQUEST[email]'")->num_rows) {

[Kit]

Obávám se, že je to kus skutečného kódu a autor si o SQL injection koleduje zcela záměrně

[Petr Maleček]

Noo, chybí tam ta podstatnější část nad tím, nebudu jí kopírovat, ale $_REQUEST[] je protažen mysql_escape_stringem

[Kit]

Manipulace s formálními parametry nepatří k dobré programátorské kultuře. Když si pak někdo vzpomene, že parametry bude předávad odkazem, diví se všichni.

Ano, nadávají mi do defenzívního programátora. Chápu to a naučil jsem se s tím žít.

[l0gik]

Ne to není defenzivní programování, to je prostě čistej rozum. Takhle napsaný je to prasečina. Holt to psal někdo vyrostlej na magic quotes a supluje si je.

A prasečina hned dvojnásobná, protože místo num_rows v uživatelském prostoru tady naprosto stačí použít SELECT EXISTS(SELECT ....).

[Kit]

Dosud jsem netušil, co je to Magic Quotes. Když jsem si to vyhledal, tak jsem zjistil, že jsem o nic nepřišel. Stejně jsou nejlepší parametrické dotazy, tam se nic takového řešit nemusí.

[Petr Maleček]

Ten formát jaký jsem použil jsem použil z toho důvodu, že vím, že funguje. To co píšete třeba vidím prvně, zase až tak do hloubky jsem schopnosti dotazů pod MySQL nezkoumal, takže přiznávám, že určitě Vaše řešení bude lepší, nebo správnější, ale to moje prostě funguje tak, jak jsem očekával a 99% programátorů pozná, co tím chtěl básník říci, takže mne to nechává klidným. Jednoduchý účel ke kterému to slouží nemá ani znatelný rozdíl na výkonu.

[l0gik]

No pokud tuto konstrukci vidíte prvně, tak si kupte nějakou knížku o SQL a naučte se ho. Protože jinak budete vyrábět prasečiny jak na běžícím pásu. - Samozřejmě zrovna v tomto kontextu to není takový problém, rozdíl ve výkonu tady bude malý (daleko větší prasečina je to přímý vkládání REQUEST_, protože u něj není jednoduše vidět, že ej už enkódovaný a navíc modifikovat globální pole je opravdu VELKÁ prasečina). Jen to prostě ukazuje na to, že používáte něco, s čím neumíte zacházet. A to prostě není dobře, protože jednou vyrobíte prasečinu, která už nevinná nebude. - Já Vás nechci prudit. Jen se mi zdá, že tendle styl programování (moc tomu nerozumím, jen když to nějak funguje) je cesta do pekel...

[Petr Maleček]

Možná je to cesta do pekel, ale budete se divit, že mi je za tuto možnost většina uživatelů vděčna. Tady nejde o nějakou velkou službu, jedná se jen o drobnost změny hesla pro mailové schránky, které spočítáte na prtech obou rukou. Nějaký vehementní útok na tuto "službu" neočekávám, takže i kdybych neměl SQL Injeciton nijak ošetřen, tak se houby stane.

Jen to prostě ukazuje na to, že používáte něco, s čím neumíte zacházet. A to prostě není dobře, protože jednou vyrobíte prasečinu, která už nevinná nebude.

Fajn, řekněme - smyšelný příklad - že najezdím ročně kolem 200 tisíc kilometrů (jakožto zahraniční řidič tahače), osobní auto umím řídit i se zavázanýma očima a mám za tu dobu za sebou jednu nehodu, kterou jsem nezpůsobil. Vy najezdíte jakožto běžný motorista ročně kolem 15ti tisíc a máte za sebou třeba 2 zbořená auta vlastní vinou.

Jsem oprávněn Vám říkat, že používáte něco s čím neumíte zacházet a to prostě není dobře, protože jednou někoho zabijete a to už tak nevinné jako sešrotovaná auta nebude ? Je to cesta do pekel.

[Kit]

Tady ale jde principiálně o něco úplně jiného. Modifikace globálních parametrů je v přímém rozporu např. s funkcionálním programováním. Vytváří se sekvenční závislosti, které znemožňují paralelní programování. Ale hlavně se vytváří špatné programovací návyky.

To je tak těžké si dát ošetřenou hodnotu do nové proměnné? To je tak těžké používat parametrizované dotazy? To je tak těžké si nechat poradit od zkušenějších?

[Petr Maleček]

Nějak nevidím důvod, proč bych měl současnou hodnotu z pole requestu cpát do nové proměnné, když současný formát i po ošetření mysql_escape_stringem odpovídá mému požadavku a jeho formát není nikterak pozměněn.

Mě to naopak připadá jako zbytečné plácání proměnnými. Pokud vám jde čistě jen o modifikaci hodnot v gobálním poli, tak můžu samotnou fci escape_stringu přesunout s klidem do složené části SQL dotazu, kdy se nic modifikovat a znovu přiřazovat nebude.

Ale tohle, jsou jen detaily u tak jednoduché části kódu, jako je ten, který jsem napsal. Modifikace hodnot v globálním poli je možná trošku prasečina a možná se to ani nemá, ale v mém případě použití to nehraje roli.

[l0gik]

Proč? No protože programátorské zkušenosti praví, že když se to neudělá, tak se kód dřív či později při údržbě rozbije. Prostě je to nečitelný kód který vede zvětšuje pravděpodobnost chyby a navíc se bude daleko hůře udržovat.

Přístup "v mém případě to nehraje roli" je přesně to, za co by se měli programátoři střílet. Dřív či později se to člověku šeredně vymstí. A pokud ne Tobě, tak tomu, kdo po Tobě bude ten kód udržovat.

[Kit]

Převzal jsem údržbu aplikace, která byla napsána podobně hnusným přístupem. Šetření proměnnými se dělalo v dřevních dobách programování, kdy se musel šetřit každý byte. V mém případě to značně ztížilo údržbu, kusy kódu jsem musel přepsat a při té příležitosti jsem našel i pár fatálních chyb, které původní autor udělal, ale v rámci "úspor" si jich prostě nevšiml.

Netvrdím, že by se pamětí mělo plýtvat, ale v daném případě se nic neušetří, spíš naopak. V obou případech dojde k alokování nového prostoru, v "úsporné" variantě se uvolní původní řetězec do smetí. Při opuštění funkce či metody se v "úsporné" variantě uvolní další proměnné do smetí, ale vznikne o jeden fragment víc. Garbage collector bude mít o něco víc práce. A jak funguje GC v PHP, to přece víme. Takže "úsporná" varianta je vlastně méně úsporná.

Pokud se jedná o malý projekt nebo jen pokus, tak plácání proměnnými nás nemusí trápit. V případě velkého projektu zase musíme hlídat udržovatelnost kódu. Ani v jednom případě tedy tyto "úspory" nejsou vhodné. I při pokusech je potřeba udržovat kulturu programování, protože se tím získávají správné návyky. Takže to hraje roli vždy.

Mnoho špatných postupů se dostalo i do různých učebnic programování, protože si na ně autor tak zvykl, že mu vlastně přišly v pořádku. Typickou učebnicovou chybou je například SQL dotaz "SELECT * FROM tabulka;", který nacházím i v komerčních aplikacích. Prostě si to někdo zjednodušil a pak už se k danému kódu nevrátil, protože mu připadal OK. Chybu to nezpůsobí hned a nemusí to způsobit nikdy, ale udržovatelnosti programu to neprospěje. Ovšem je to mnohem menší zlo, než modifikace superglobálních polí.

[Filip Jirsák]

Zrovna použití mysql_escape_string k přepsání hodnoty pole z požadavku je první polovina vytvoření SQL injection. Pak se vám někde stane, že tu hodnotu escapujete dvakrát, jako opravu to escapování zrušíte a tam, kde se to escapovalo správně jednou, máte vyrobené SQL injection. Mnohem lepší je vyhnout se přepisování parametrů požadavku, vyhnout se i mysql_escape_string a použít parametrizované dotazy.

[l0gik]

Ten příklad nesedí. Protože jezdit v autě se člověk nenaučí jinak, než tak, že bude jezdit. Programování se ale člověk musí učit i jinak, než jen že "začne programovat". Stejně jako když člověk jezdí autem, tak dřív, než do něj sedne, tak by měl si přečíst a dosti dobře znát silniční pravidla, tak když člověk chce programovat, tak by taktéž měl znát pravidla.

[Kit]

Kdybych to měl dát do souvislosti s příkladem, tak dodržováním pravidel silničního provozu se výrazně sníží pravděpodobnost autonehody u obou typů řidičů.

[Petr Maleček]

Ano, silniční pravidla musí znát každý motorista, ale je stejně jako s programátory. Kolik nehod na silnicích vznikne každý den ? Mnoho, protože vždycky nějaký řidič udělá chybu, protože nedodržel některý z bodů silničních pravidel.

Stejně tak programátoři, ale u nich to není tak horké (do cíle dojedou bez nehody, přestože to vezmou třeba objížďkou, nebo zkratkou, nebo po poli).

A stejně jako se z řidiče stává dobrý řidič až časem s ježděním, kdy si vše vžije, chyby napraví a přiučí se od ostatních účastníků silniční dopravy, tak i programátor bude dobrým programátorem až po letech programování a zdokonalování se samoukou nebo sledováním druhých.

A teď babo raď, co a kdo to dělá správně a proč.

[l0gik]

Ano - pro dobré programování i pro dobré ježdění je třeba praxe. Ale pokud se člověk nenaučí předpisy, tak dobrý řidič být prostě nemůže a pravděpodobnost havárky mnohonásobně stoupá - a s programováním je to totéž.