zenonline Posted September 24, 2012 Share Posted September 24, 2012 Hi guys, I have a users table that holds the password as a varchar(200) in a utf8_unicode_ci collation. It uses the multiple passes of the hashmac function to encrypt it as follows : hash_hmac('sha512', $pass, $salt, true) . I know I should set the password as a set character length but couldn't work out what the length should be and i think this must be part of the issue. All works fine and dandy, i can verify the users the lot, the problem is when I create a back up and re-instate it, the passwords don't seem to save properly. Currently I back up using the phpMyAdmin as an SQL file and then copy and paste that file data into SQL query window of phpMyAdmin. I've also noticed that if I try and change the record (any field) using the phpMyAdmin interface (apart from the SQL query window) it also corrupts the password. I'm therefore assuming that I need to change the storage type for the password to keep its integrity but to what to and what size or is there something else that I'm missing? cheers Zen Quote Link to comment Share on other sites More sharing options...
zenonline Posted September 25, 2012 Author Share Posted September 25, 2012 OK, I have changed the password field to char(128) and also tried it as a binary(64), again exported as a sql text file, deleted the table from the DB and then recreated by copying and pasting the sql file text into the sql command in phpMyAdmin and the passwords are still corrupted, my assumption is that some of the encrypted password is acting like a text format or something and is therefore getting 'lost' how can I overcome this? please help as I don't feel comfortable putting this DB into the wild if I cannot do a proper backup on it, all the non-encrypted data is fine cheers Zen Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted September 25, 2012 Share Posted September 25, 2012 I recommend using hash_hmac with lowercase hex-digit output, not binary. Quote Link to comment Share on other sites More sharing options...
zenonline Posted September 25, 2012 Author Share Posted September 25, 2012 Hi PFMaBiSmAd, I'm using Binary as it uses less space overhead (64 bytes vs 128 with char) and as I understand it (which normally means I'm wrong) has a higher computational overhead hence slowing down hack attacks (not a slow as bcrypt I know). I've also found the root of the issue, my testing server is a USB webserver (http://www.usbwebserver.net/en/)so that I can continue testing it on any machine and even though I selected export binary values as hex it isn't doing so, its a fault of the testing system. I've looked at the data exported by the hosting server and it does look like it is ok i.e.binary converted to hex, going to runa few scripts just to make sure. regards zen Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.