mcrypt and urlencoding issues

Question

First let me make it clear that I don't have any control on frontend application (it's an iOS app and I've to live with it the way it is) that's using the authentication token I'm encoding and decoding through following functions in a class.

My application returns the authToken based on username/password and then that front-end application keeps communicating to me via this authToken, which I decode every time to find the user information.

As you know this algorithm generates characters that needs to be urlencoded, so I'm url encoding them before sending down the wire.

I noticed that front end application is urldecoding the authToken automatically and then sends be back a urldecoded one.

But here things get complicated, I've .htaccess on the server as well which I believe does url encoding or decoding, not sure.

The end result is, by the time the token reaches to the application, it's different from what I sent.

Not sure what can I do to have it handled properly, I've the frontend application urldecoding it, then this .htaccess doing something, and end result I don't have the original token.

public static function encrypt($data, $secret) {
    $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
    $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
    $key = pack('H*', $secret);
    return base64_encode($iv . mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $data, MCRYPT_MODE_CBC, $iv));
}

public static function decrypt($data, $secret) {
    $data = base64_decode($data);
    $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
    $iv = substr($data, 0, $iv_size);
    $data = substr($data, $iv_size);
    $key = pack('H*', $secret);
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $data, MCRYPT_MODE_CBC, $iv), chr(0));
}

in my view tier, the authToken generated by above functions.

echo urlencode($authToken)

.htaccess file

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.+)$ index.php?uri=$1 [QSA,L]

if my approach is wrong, how do you guys handle authentication out there?

Edit (Example Data):

+zrOchaEg6X9oXMsSz2yq7jcxGLsIsh5XpgUEEhqLuoGT6nqNcpwevPXCUCPiUQ9 (my app sent down this)
 zrOchaEg6X9oXMsSz2yq7jcxGLsIsh5XpgUEEhqLuoGT6nqNcpwevPXCUCPiUQ9 (front end app sent me back this)

EzfudmhVDKhfiZU1rN+h5vgdq+JsHFBI6suio2wwvS3415UvHcqaNkj6RCcPNcrN (my app sent this)
EzfudmhVDKhfiZU1rN h5vgdq JsHFBI6suio2wwvS3415UvHcqaNkj6RCcPNcrN (front end app sent this)

p45ho0s2qWBxzCWsOohSL5u+noxUdpkjfjVy/wib58Sx2lqXIfco3uHLpaiDLy58 (my app sent this)
p45ho0s2qWBxzCWsOohSL5u noxUdpkjfjVy/wib58Sx2lqXIfco3uHLpaiDLy58 (front end app sent me back this)

NBEwy2WAInAgqC54WR6kNHVVpTObN1x1Wbu9JRD/UTCuMLbtHAomHFWDX8olFrC9 (my app sent this)
NBEwy2WAInAgqC54WR6kNHVVpTObN1x1Wbu9JRD/UTCuMLbtHAomHFWDX8olFrC9 (front end app sent me back this)

Answer 1

Depends on your implementation, if at any time it will be passed as a get parameter then yes but it seems you are having problems with the + sign, in stead try using rawurlencode() and rawurldecode()

Answer 2

Unless you are logging incorrectly or performing some kind of decoding while displaying the text, it seems to me that your iOS app does not really URL encode.

There should not be plain + signs if that was the case, such characters should be replaced by %XX after URL encoding. Spaces are not part of base 64, so there should be no spaces converted to + signs.

On the other hand, the string that is send looks like base 64 to me, so maybe you don't need to base 64 encode at all.