I use the following code to store user password into a mysql table with the password column being a BINARY(20) type:
$salted_hash = sha1($salt . $password);
$sql = sprintf("INSERT INTO foo(user, password) VALUES ('guest', UNHEX('%s'))", $salted_hash);
The select query to match password looks like:
$salted_hash = sha1($salt . $password);
$sql = sprintf("SELECT `userID` FROM `foo` WHERE `user`='guest' AND `password`=UNHEX('%s')", $salted_hash);
The code works fine when I connect to a web server running on a windows or mac machine. However, my production web host is a linux machine, and the SELECT is failing there.
I can only phpMyAdmin to my web host (mhpMyAdmin version 3.4.7.1). Through phpMyAdmin I execute the following query:
SELECT UNHEX('3530280EDB5AA715929266D1D6F0423ABC27B104')
The result displayed is the same number hex number 3530280EDB5AA715929266D1D6F0423ABC27B104, which seems to indicate that the UNHEX function is not doing anything on linux.
If I execute the same query in Sequel Pro on Mac I get 50(ÛZ§fÑÖðB:¼'±.
I’m not sure what’s going on and where to look. I’m thinking either phpMyAdmin cannot display binary or there is indeed some problem with UNHEX(seems unlike) Any help is appreciated.
It seems it’s a configurable setting: “Show binary contents as HEX”. I’ve tried your query in the same server…
… but using two different clients. I can confirm that phpMyAdmin escapes binary output the way you’ve found. You can double check that the output is correct with:
…, which should return 1, or running the original query with simple PHP script. To sum up: there’s nothing wrong with
UNHEX().Most hosting services I’ve used actually allow external MySQL clients, you just need to enable it in the control panel. Make sure it’s not the case. It’s silly to use a dumb web client if you can connect with Sequel Pro.
I suggest you do further debugging with your PHP code. It’s not clear to me how you build the hash to match (do you retrieve the salt in some other query?).