Laxidasical

I have a script that encrypts data via mcrypt/AES. For some reason I can't seem to store & retrieve that data correctly in MySQL. When I try to retrieve the information and decrypt it I get garbage. I changed my script to base64_encode() the encrypted data, store it in the database, then base64_decode() it before decrypting it, which works great. Everything I've read though says that I should be able to store it in MySQL directly with no problems as long as I'm using a binary datatype (such as BLOB). Any suggestions???

I'm working on Windows (Vista) as well for development, and MCRYPT_RAND is working. I'm using IIS 7 though, and PHP 5.2.4. I've read that quite a few people are having the same problem as you on Windows machines. If what I suggested in my last post didn't work, I was going to suggest creating your own iv. It doesn't have to be created by mcrypt_create_iv(), it just has to be random (and in your case 8 characters long). Keep in mind, when you move it to the UNIX machine, it may expect an iv longer or shorter than 8 characters. Something like this... function iv ($size = '8') { $iv = ''; for($i = 0; $i < $size; $i++) { $iv .= chr(rand(0,255)); } return $iv; } Also, one slight thing... $Key = substr(md5('very secret key'), 0, mcrypt_enc_get_iv_size($td)); should be... $Key = substr(md5('very secret key'), 0, mcrypt_enc_get_key_size($td)); mcrypt_enc_get_iv_size() should only be used on: $initializationVector = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_RAND);

Hmmm...that's very odd! echo $initializationVector and see if it is different every time. If not, that is the issue. Also, did you remove this line: $initializationVector = "CyJ^54%!"; Yes, you will have to store both the encryption result and iv somewhere (session, database, etc), then return them both to your mcrypt function in order to decrypt properly. UPDATE: Also, did you change the mode to cbc, or leave it as it was??? I don't know which, but some modes don't return different results. I know cbc will though...

Try this... $sidebars = array( array( 'section' => 'overview', 'showVideo' => true, 'showContact' => true, 'showTestimonial' => true ), array( 'section' => 'solutions', 'showVideo' => true, 'showContact' => true, 'showTestimonial' => false ) ); foreach ($sidebars as $sidebar) { if ($sidebar['section'] == $section) {// do what you want it to do here} } NOTE: I made your original $sidebar variable plural: $sidebars. Don't forget to make that change!

Oh yeah, as far as the last part of your post... You have to use the same iv that you encrypted with. When you get the random iv part working (which hopefully my above post will fix), you will need to pass that random iv back with your encrypted data in order to decrypt it correctly. This has to be done every time! What I did was pass an array of variables to my mcrypt script, looped through each, encrypted it and added it to second array, added the iv as an element of the second array, then passed back that array using the same array keys with corresponding encrypted strings. This prevents me from having to store x different ivs if I have x different variables. Let me know if that makes sense the way I typed it. If not, I'll explain in detail...

You need to get the iv size when calling mcrypt_create_iv(), not the key size. Thy this... $initializationVector = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_RAND); You won't need the $keySize variable any more unless you use it some place else as well. If you want to pull the mcrypt_enc_get_iv_size() function out, you can do something like... $ivSize = mcrypt_enc_get_iv_size($td); $initializationVector = mcrypt_create_iv($ivSize, MCRYPT_RAND); <b>UPDATE:</b> I see you do use $keySize other places, so DON'T get rid of it!!!

That is because you are using the same iv every time. If the key and iv are always the same, you'll always get the same result. The first issue to solve is why mcrypt_create_iv() isn't working. What version of PHP are you running??? If it's lower that 4.2, then this applies:

Not sure why, but when I stopped the MySQL service and restarted it the broken month variable problem went away. Very weird...but I'm not about to complain! :-X

Try changing your mode to cbc: $td = mcrypt_module_open('tripledes', '', 'cbc', ''); instead of... $td = mcrypt_module_open('tripledes', '', 'cfb', '');

I was always storing it as either a TEXT or a BLOB, I learned varchar strips spaces at the end of a string the hard way about a year ago. I tried UTF-8 as you suggested, no such luck. I also tried several others just for good measure, still wasn't working. Then I decided to have my mcrypt script base64_encode the final output (and of course base64_decode encrypted data that comes in). Bingo! Well, almost... Everything encrypts/decrypts correctly within my script (local variables only). The "month" ALWAYS messes up when storing data in MySQL though. The only thing different about month from the other data is that it is less than three characters. I thought maybe there is a minimum string length limitation when using mcrypt on the data at first, but it works fine when I'm not storing it in MySQL. Off to do some more testing...

Hey Syphon, The key is encrypted via md5, which will ALWAYS output the same result when given the same date string. This is a good thing! Otherwise your script would try to encode/decode your data with a different key every time and you'd get garbage back. Even though your key is encrypted, it is still "super secret"!!! To keep it a secret, a lot of people save their mcrypt script above the route directory and include it from there. Personally, if your script resides on a server that is not your own, someone somewhere at your host has access. I prefer to encode files that contain sensitive information like this. Now the output data is a different story. You should be getting a different encrypted string every time, even if you are encrypting the same exact data! That is why you need to pass the initiation value (iv) every time, it's sort of like a primer for that data's encryption. I'm dealing with an mcrypt issue myself right now. I've been going crazy trying to figure it out. Hopefully passing along a little of what I've learned along the way will help you!

Thanks, I hadn't thought of that! You have any idea what charset I should use? The script has to bill users monthly. I'm order to do so it needs the unencrypted credit card info.

I'm storing the string values separately. I hadn't thought of storing the entire array in the database (like session data), but I'm going to try that now! In case anyone is wondering...when the array is encrypted, the iv is also included in the array containing the encrypted data. I forgot that in my original post: $cc['iv'] = 'lúí²/Ó—5ùï¨Òè±'óKø@ ȤãÖ^';

I created a function that both encrypts and decrypts an array holding credit card data using mcrypt, depending on what I pass. For example: // SET CREDIT CARD ARRAY $cc['type'] = 'Visa'; $cc['name'] = 'John Doe'; $cc['number'] = '1111111111111111'; $cc['month'] = '03'; $cc['year'] = '2008'; // RETURN AN ARRAY CONTAINING THE SAME KEYS WITH ENCRYPTED VALUES $ecc = cc_crypt($cc, 'e'); /* $cc['type'] = 'lúí²/Ó—5ùï¨Òè±'óKø@ ȤãÖ^'; $cc['name'] = 'K5È8ø:3~óY"«FU¯s7ÏÀèjrE%½á'; $cc['number'] = 'ô­mOQM—³Ýld³Ì‰ŸÊÀ´­ïv5g$c'; $cc['month'] = '-®åF[9•ÐRBÓá²ðãì˜È^èGJJ”B:'; $cc['year'] = '_RaWª£¶Îc€ åss)Y«¹jŒ§ érþj8Ó'; */ // RETURN AN ARRAY CONTAINING THE SAME KEYS WITH DECRYPTED VALUES $dcc = cc_crypt($ecc, 'd'); /* $cc['type'] = 'Visa'; $cc['name'] = 'John Doe'; $cc['number'] = '1111111111111111'; $cc['month'] = '03'; $cc['year'] = '2008'; */ It works great within PHP, but when I store/retrieve the data using a my MySQL database it breaks! I know it has something to do with how the data is being stored. I've tried storing it in MySQL field types TEXT and BLOB with no luck. Every so often I noticed I'd get a MySQL error when inserting. I tried addslashes/stripslashes. This solved my insertion problem, but breaks encryption/decryption (both within a script and with the database). Has anyone here successfully stored mcrypt variables in their database? If so, how? ???

Mine is the combination of two words... reLAX and LackIDASICAL  :D

I've used database stored sessions on both low and high traffic sites and have never seen a decrease in speed. The largest of the 6 required functions is only 8 lines of code. I've definitely seen an increase in speed when we scale servers though...

Thank you for mentioning the security point! I meant to address that in my last post. I remedied the session.gc_maxlifetime issues by storing my own expiration date in the session database table (as a UNIX timestamp). The "expires" field is updated every time the session is written to. You can set the variable used in the UPDATE or INSERT query to use the default time as such: $expires = time() + get_cfg_var("session.gc_maxlifetime"); ...or you can set your own time is seconds. So if you wanted the max time to be 30 minutes: $expires = time() + 1800; I run a query in the garbage collection function that deletes sessions based on that field. By the way, in case anyone reading this is completely clueless as to where I am setting these functions or about changing the location of where you store sessions (file or database), see session_set_save_handler().

This is slightly off topic, but there are a couple of reasons for storing sessions in a database: SECURITY: If you are on a shared host, it may be possible for others who share your server to see your session files. Storing sessions in the database restricts access to only those with database privileges. SCALABILITY: If you website grows and requires additional servers to handle the traffic, file based sessions will break. When a session is generated, the session file is stored on the specific server that ran the initial session_start() function. There is no way to reliably re-route that specific user back to that specific server, at least without loosing the advantages of having several web servers behind a load balancer in the first place. By storing the sessions in a database, then having multiple web servers share that one database server, the sessions will remain available regardless of what web server the user hits. There are a couple of other reasons, but these two are why most people who store sessions in the database do so. I'm sure these were the reasons the guys at PHP decided to make the session_set_save_handler() function as well. Also, this isn't related to cookies at all! Sessions HAVE to be saved somewhere in order to maintain a state. This is simply a way of storing the session in a different location, regardless of the cookie. Oh yeah, and the purpose of sessions isn't to give users "a direct connection to specific portions of the databases". You can use sessions and provide completely static file based content. Sessions are used to maintain a state...no more, no less.

So lets say a site sits idle for 3 days with no visitors and there were sessions left in the table undeleted. They would stay there until traffic started hitting the site again, correct? I'm not going to put any more effort into it, this thread is more FMI than application...

Does anyone know how often PHP does garbage collection on sessions, or if there is even a set time interval? I know that you can set sessions to have a max time before they expire in php.ini, but how often will PHP actually go through and delete the expired sessions on it's own? I ask because I recently started storing sessions in a database. I noticed that expired sessions that haven't been explicitly deleted (ie. exiting my site without clicking "Logout" which would delete the session) sit in the database for quite some time. I've only made the session to database change on a development machine, so there is almost no traffic. This leads me to believe it's done after so many calls to session_start(). Is this true? If so, I'm thinking of calling the session garbage collection function at the end of the session close function in session_set_save_handler(). I'd like to avoid this extra query every time a session closes though. ???

Jeremysr's example should fit the bill! I run into situations sometimes where I need to hold all of the rows in a multi-demensional array. In that case, this will work... $result_id = mysql_query("SELECT catname, catid FROM table"); if ($result_id != FALSE && mysql_num_rows($result_id) > 0) { $i = 0; while($results = mysql_fetch_assoc($result_id )) { // LOOP THROUGH EACH ROW AND ASSIGN VALUES TO A MULTI-DEMENSIONAL ARRAY foreach($results as $key => $value) { $rows[$i][$key] = $value; { // INCREASE $i FOR NEXT ROW $i++; } } Now you have a single variable that has all of your query results. To display... foreach($rows as $row) { echo '<li><a href="http://retailsneakerstore.com/brand-name-' . $row['catname'] . '---' . $row['catid'] . '" title="' . $row['catname'] . '">' . $row['catname'] . '</a></li>' . "\r\n"; } I find myself using "foreach" loops with arrays far more than "while" or "for". I hope that helps!

No problem!

How about placing the following under "/* GLOBAL classes - skin & pages */" in the CSS file that you posted: body {background: url(http://www.search-the-world.com/auctions/images/opalbackground.jpg);} If you want the background to repeat, then use: body {background-image: url(http://www.search-the-world.com/auctions/images/opalbackground.jpg); background-repeat: repeat;} Hope that helps!

Not sure why, but it suddenly started working correctly. ??? Before I started this thread I deleted both the session and cookie as well as rebooted several times (for something else). That was yesterday. About 15 minutes ago it started working...wierd! All's well that ends well...

LOL - I hear what you and BlueSkyIS are saying. For some reason it makes me just a little nervous having two session ids out there. Suppose a server or PHP upgrade is made to my host and it suddenly starts recognizing PHPSESSID as the default. I know, I'm probably being paranoid. I'm not going to fiddle with it until I learn some concrete info on how session_name() is suppose to act in this regard...