I'm currently working with data I'd like to temporarily store in my database as encrypted data. I'm not worried about the database getting hacked into, I just want to ensure the people that had entered the data that it is not reachable by any other than themselves. (and me of course)
The data is not meant to be stored permanently in the database since I'm exporting it to a third party application using their API, but since they have a rate limit I need to store the data in our database until the limit is over and I can upload it. (Assuming the rate limit occurs)
The process:
The request I receive from the form is in an array, so to begin with I serialize() the array to get a long string which I will unserialize() later.
Then I want to use a method that lets me convert the string into numbers and back again without losing information.
The reason I want to turn the data into numbers is because I use the HashIds library, which only encodes numbers. To my knowledge it's an extra layer of security I'm happy to add.
Read more on HashIds here: http://hashids.org/
What I have tried:
I tried converting the string into hex numbers, and then the hex numbers into decimals. Unfortunately the number was too large, and i haven't had any luck using biginteger with it.
base64_encode() which is not going to turn the data into numbers, but then base_converting them is. But I couldn't figure out the base converting in php since apparently it's rather odd.
Conclusion:
How can I convert the data I'm receiving from a form request into a short encoded string which can be converted back into the data without too much hassle? I don't quite know all the options PHP offers yet.
UPDATE:
To conclude this thread, I ended up using OpenSSL to encrypt my serialized array. Only problem I ran into was if the request contained a file I wouldn't be able to serialize it and save the object to the database. I do still need a way around this, since the third party application expects the file to be a multipart/formdata object i can't just save the filepath to the database and upload that. But I guess I will have to figure out that one later.
That link http://hashids.org/ provides a pretty clear example. Lets assume that your integer is 15.
$hashids = new Hashids\Hashids('some random string for a salt. Make sure you use the same salt if you want to be able to decode');
$encoded = $hashids->encode(15);
print_r(['hashedId' => $encoded]);
$decoded = $hashids->decode($hashed);
print_r(['decoded' => $decoded]);
So the value of $decoded should equal 15
Update
Sorry - the hashids bit of your question threw me and as such, I misunderstood what you were asking. I will update my answer:
You should really be using https://secure.php.net/openssl_encrypt and https://secure.php.net/manual/en/function.openssl-decrypt.php
Related
I'm planning to generate and store salt in database and pass it back to UI. I'm using openssl_random_pseudo_bytes function. Looking at the salt result I see following in PHP debug window
and the following in database record
I'm planning to recreate hash on client-side using this salt.
I'm curious if this random string of is okay to work with when passing it back and forth from server to UI? Or should this be encoded before passing it back and forth?
Following is database column definition for SALT column
You should change the column type to VARBINARY (or just BINARY if the length is fixed) instead of VARCHAR. Since the contents of the column are not meant to represent text, binary data types will be more efficient.
In any case, as long as there are no misconfiguration problem you should have no correctness issues in your application even with the column having its current data type.
Original Question
mysql-server-6.0.10
I have this problem, I'm using the COMPRESS function to update a field with a BASE64 encoded value. The "updated" base64 string is only slightly different than the value that is currently in the database but it IS different. The only part is different is the last few bytes of the string. The problem is that mysql is seeing these values as the SAME and therefore skipping the update. It returns without error letting my program thing it did what it was told but then you go back and the data is unchagned.
For example, the first one is base64 string that was previously INSERTED to the db, the second one is what I'm trying to overwrite with:
YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO2k6MjM0MjM0MjM0MzI0MDAwO319
YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO3M6MTU6IjIzNDIzNDIzNDMyNDExMSI7fX0=
I'm running this query:
UPDATE TABLE SET fieldname=COMPRESS('YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO3M6MTU6IjIzNDIzNDIzNDMyNDExMSI7fX0=') WHERE id = 'SOMEID';
Mysql comes back with 0 rows affected.
I can reproduce this in an SQL Query window via PHPMyAdmin so I know its not a problem with code.
How can I force this to just update regardless if the strings BEGIN the same way, since it obviously inst checking the entire string? Right now my workaround is to clear the present data with one query, then run another query to update against nothing. This is inefficient though and I'm not happy with it.
First question update
I actually found out this is a result of a PHP bug with JSON_NUMERIC_CHECK!
The value was getting saved in the database properly (couldnt tell because of the compression) but when my script to go back was loading the data out of the database via JSON_ENCODE the values were getting mangled by JSON_NUMERIC_CHECK.
See the bug report I filed:
https://bugs.php.net/bug.php?id=60111
Second question update and solution
So it really turns out I was way ahead of my self on this. I was using JSON_NUMERIC_CHECK incorrectly. I was using it as a blanket solution to ensure all numeric values would be, well, numeric. The flaw in this logic is that JSON_NUMERIC_CHECK's purpose in life is to attempt to convert all numeric strings to integers, in 32-bit OS environment there is a limit to how many digits an int val can be and thus using the exponential expression as it should!
It comes down to the fact that in my system, there is a possibility of a [tracking number] could actually be an extremely long string of just numbers. JSON_NUMERIC_CHECK was doing exactly what it was suppose to do by converting this to an exponentially expressed int val.
The actual fix to this was to not use JSON_NUMERIC_CHECK and to make sure that my var types were correct where I actually needed int vals before creating the object that is later passed to the front end via JSON.
Phew, a mouthfull, but i figured if anyone else runs into this problem it might be helpful. Chao!
I'm sorry guys, nevermind, the problem is that value i'm supplying is being treated as INT instead of STRING and its over the max size of an INT so its resetting to the MAX INT and therefore being the same string.
Sometimes just thinking through it enough to post a problem on here is enough to help me figure it out :)
UPDATE:
I actually found out this is a result of a PHP bug with JSON_NUMERIC_CHECK!
The value was getting saved in the database properly (couldnt tell because of the compression) but when my script to go back was loading the data out of the database via JSON_ENCODE the values were getting mangled by JSON_NUMERIC_CHECK.
UPDATE:
I'm actually just way ahead of my self. using JSON_NUMERIC_CHECK incorrectly. My bad!
I have a php script that outputs a json-encoded object with large numbers (greater than PHP_MAX_INT) so to store those numbers internally, I have to store them as strings. However, I need them to be shown as un-quoted numbers to the client.
I've thought of several solutions, many of which haven't worked. Most of the ideas revolve around writing my own JSON encoder, which I have done already, but don't want to take the time to change all the places I have json_encode to instead say my_json_encode.
Since I have no control over the server, I cannot turn remove the JSON library. I cannot undeclare json_encode, nor can I rename it. Is there any easy way to handle all this, or is the best option to just go through each and every file and rename all the method calls?
With javascript being loosely typed, why the need to control the type in the JSON data? What are you doing with this number in javascript, and would parseInt\parseFloat not be able to make the leap from string to number on the client side?
The only option I had was to use my own json_encode method renamed to my_json_encode, and then change everywhere that called that method.
Im currently using base64_encode for some $_GET params that i don't want regular user to mess with.
I was wondering that base64 is not looking too strong or is it ?
I also don't want to make some sort of mega encoding it's not so much of important information, but i would not like that user with average knowledge would mess with params in get.
Should i keep using base64 ? Currently it produces MQ== if value is 1 so it's quite easy to take it out from URL and decode and then insert your own.
Base-64 encoding doesn’t protect the data in any way. It’s a simply base conversion like using hexadecimal instead of decimal for integers.
If you just want to verify data integrity, you can use a salted hash (with a secret salt) that you store along with the data. See for example the hashed message authentication code (HMAC).
base64_encode() is not a security measure! It was designed to make sending of binary blobs possible through mediums that typically transfer ASCII only.
Use a session, or properly encrypt your variables.
I would recommend just using a session, and storing it out of the default /tmp for good measure with...
ini_set('session.save_path', '/sessions');
If you want some real encryption/decryption take a look at the Mcrypt features of PHP. http://www.php.net/manual/en/mcrypt.examples.php
But then you may want to use POST instead of GET because of the URL specifications which are limited in character usage and URL length.
Depends on what you want do do with it.
If you just want to obfuscate it (especially when you're generating those URLs in Javascript or so), you could apply ROT13 to the URL and swap a few additional characters to make decoding it a little bit more difficult.
However, if the security of your application depends on it, you could apply a static-key symmetric encrytion on the data server-side and decode it when you receive a request or so. I think that there are frameworks or so for that.
I'm not much of a PHP expert. I'm encoding a URL with base64_encode.
I get quite a long encoded string with a lot of weird characters exactly as I want it to be.
Is there a way to trim this long line of characters to let's say 10 or 15 chars, so I can decode it later again?
I know there is trim() but that does not exactly what I want. I want a long encoded string to be rather short and later I want to decode it again.
Any ideas?
It's not possible to "shorten" any string without losing some data.
If you want to physically shorten an encoded string (with the end result being only part of that string), apply substr() but not on the encoded version: You need to decode it first, then re-encode the shortened version.
Another option is to compress a string. This may shorten it somewhat: Look into gzcompress(). Your mileage may vary, though: the compression rate will depend on what kind of data you have. With small input strings, the result can even be larger than the original.
If you want to reuse a variable in a multi-page process, and don't want to transport it through a link or a form, consider generating a short random key, and storing the data in the user's session:
$_SESSION[$randomKey] = "lllloooooooooooong data here";
You could pass on the random key, and always access the "long" data using $_SESSION[$randomKey]. You need to have a session initialized for this.