I'm using codeigniter2.1.4.my problem is when i use
$this->encrypt->encode($row['service_id'])
in my view page ,it generates such a key that is not permitted url and i also want short encrypt key bcoz current encrypt key too big.Any solution?Thanks
A simple solution would be to send the encrypted key as a POST parameter instead of GET parameter. In case you do not want to do that, look into
$config['permitted_uri_chars']
in application/config/config.php. Add the characters that you want to send in URL. Remember. THIS IS A SECURITY COMPROMISE.
You can always change to another cipher algorithm using
$this->encrypt->set_cipher();
This is known to mess up your sessions as sessions are encrypted using the default algorithm. So if you set session, change cipher and again try modify or set session, it wont work. You need to make sure you set back the cipher to default after your encryption is done.
Check and try to understand system/libraries/Session.php, especially around the line
$cookie_data = $this->CI->encrypt->encode($cookie_data);
If you are interested in finding answer to "WHY"
Related
In codeigniter,
whenever a user is authenticated, I want to create a random session. This mechanism will be used to encrypt/decrypt the data between views-controllers. For example, I look to open a form as below:
<?php echo form_open('targetcontrollerfunction/'.encryptionfunction(data_to_be_secured)); ?>
Thus if anyone goes to inspect element, they is not able to understand the data that is being passed to the controller.
What I have tried:
I have gone through Codeigniter documentation and several articles on stackoverflow and google too. They suggest using encryption library to generate a random key and encrypt library to encode/decode the data using that key. But the challenge is that they want me to store the newly generated key in $config["encryption_key"]
Here the problem begins. In my Controller function I am validating the user account and setting some session variables. At the same time, I want random key to be generated so that the key is 100% unique for every user, but when I use the following code inside my controller function:
$randomkey=bin2hex($this->encryption->create_key(16));
$config["encryption_key"]=$randomkey;
$this->session->set_userdata('somekey', $this->encrypt->encode("somevalue"));
I also changed it to :
$randomkey=bin2hex($this->encryption->create_key(16));
$config=array(
'encryption_key'=>$randomkey
);
$this->encryption->initialize($config);
$this->session->set_userdata('somekey', $this->encrypt->encode("somevalue"));
I get an error:
In order to use the encryption class requires that you set an
encryption key in your config file.
libraries cannot be loaded into config.php file, encryption_key cannot be set inside the controller, I am totally confused. What else is the way to generate a random key and use the same for every logged in session?
If you are using CI 3, go to folder /application/config, edit config.php, then enter the encryption key (32 characters)
Search the below line:
$config[‘encryption_key’] = ‘yourkeyhere’;
I'm running into trouble with authentication handling in my Laravel 5.5. I have installed an Encryptable trait according to this post here. I then used the authentication generator to establish the base routes, views and handler.
I can successfully register new accounts and visually see that all of the data is encrypted, but I cannot successfully authenticate through the login screen.
This seems to be failing during the Auth::attempt($credentials) call. My troubleshooting is pointing to the encryptable trait because when I comment that section out, the authentication works fine.
Can someone offer insight as to how to handle authentication using this method of model encryption?
I have attempted disabling encryption for the username field, but this didn't seem to help. The password field was never being encrypted, becasue it is being hashed by bcrypt.
1st Edit:
So, with an understanding of how traits work... The Encryptable trait seems to be overloading the getAttribute/setAttribute functions. This would mean that Eloquent's querying functions like where, find, etc. will just be "looking at" encrypted values.
2nd Edit:
The source code provided for the Encryptable trait was not returning proper values for unencrypted values. This was changed and authentication was restored. To those using the same code snippet, in the get_attribute() function, change the else block so that it return $value;.
I appreciate all insights,
Dan
This form of encryption will void your ability to search the table for the encrypted fields. You won't be able to reproduce the same string because Laravel uses a random iv when producing encrypted data. An IV, or initialization vector, serves a similar purpose as a salt in hashing, to randomize the stored data.
Due to this randomization of data, you wouldn't even be able to search your table by re-encrypting the search data:
User::where('email', Crypt::encrypt('email#email.com'));
// won't find anything even if an encrypted value of email#email.com exists
Running in an interactive shell allows you to see encrypt returns a completely different value on subsequent runs:
>>> json_decode(base64_decode(Crypt::encrypt('email#email.com')))->value
=> "zpA0LBsbkGCAagxLYB6kiqwJZmm7HSCVm4QrUw6W8SE="
>>> json_decode(base64_decode(Crypt::encrypt('email#email.com')))->value
=> "VKz8CWVzR66cv/J7J09K+TIVwQPxcIg+SDqQ32Sr7rU="
Therefore, you may want to be selective about what you actually encrypt. Encrypt things that are sensitive and you wouldn't use to lookup an entity. This could be something like social security numbers, government IDs, credit card numbers, and bank account numbers.
Lets say I have a origin server which through the act of a redirect with particular query string params needs to provide details to a target server. However, I need to ensure those details came from my origin server only.
Also I can't sure the integrity of the target server. Or specifically, the target server might be compromised so any encryption keys might have been read by a malicious party.
I'm thinking I could sign the query string using some form of public/private keypair. The origin server uses a private key to sign the string, and the target server uses a public key to verify it came from my origin server, and the message hasn't been tampered with.
I'm far from a cryptography expert or anything, so any assumption here I've made might be wrong, please correct me if so :)
I'm basically after a (hopefully) simple way to do this in Ruby.
Probably, the easiest form of signing the query data (in your case a redirection URL) is by using an HMAC. Your origin and destination server would need to share a common key in this case - HMACs are not a form of public/private key cryptography, but rather a form of keyed hashing.
The module you're looking for is ruby-hmac, and your source and destination server would have to do something like:
require 'hmac-md5'
HMAC::MD5.new("<your shared key>").update("<your URL to check>").hexdigest
and compare on the destination side that the digest computed by the HMAC on the source side is equivalent: both sides thus do the same computation. The hexdigest of the HMAC can simply be transported by an additional query parameter from source to destination.
The AntiForgeryToken is used to prevent CSRF attacks, however the links on MSDN don't give me much insight to what exactly the AntiForgeryToken does, or how it works, or why things are done the way they are.
From what I gather, it creates a hash inside a web page and a cookie. One or both of them use the hashed IPrincipal.Name, and use symmetric encryption.
Can anyone shed light as to:
How the AntiForgeryToken works internally
What should it be used to protect
What should it NOT be used to protect
What is the reasoning behind the implementation choices for #1 above?
Example:
is the implementation safe from "DoubleSubmit" cookies and other common vulnerability
Are there implementation issues if the user opens multiple tabs
What makes MSFT's implementation different from the one available at SANS
Okay, here is my best shot.
1) Internally, mvc uses RNG crypto methods to create a 128 bit string to act as the XSRF token. This string is stored in a cookie as well as in a hidden field somewhere on the form. The cookie name seems to be in the form of __RequestVerificationToken + a base 64 encoded version of the application path(server side). The html part of this uses the AntiForgeryDataSerializer to serialize the following pieces of data
- salt
- value(the token string)
- the ticks of the creation date
- the username (seems like Context.User)
The validate method basically deserializes the values out of the cookie and that of the form and compares them based on the values (salt/value/ticks/username).
2/3) I would think this discussion is more for when to use XSRF tokens and when not to. In my mind, you should use this on every form (I mean why not). The only thing I can think of that this doesn't protect is if you have actually hit the form in question or not. Knowing the base64 encoding of the app name will allow the attacker to be able to view the cookie during the XSRF attack. Maybe my interpretation of that is incorrect.
4) Not sure exactly what you are looking for here? I guess I would have built a mechanism where I would try and store the XSRF token in the session (if one was already available) and if not, then try the cookie approach. As for type of crypto used, I found this SO artcile.
Pros and cons of RNGCryptoServiceProvider
I am working on a guess-a-number game with Ruby that will be online. I know I need to pass the SESSION somehow to keep the number that they are guessing, but I have tried a ton of methods with no luck. My code is here.
Any thoughts on what I can do get this code working? I have declared each of my sections.
A session is, usually, a combination of a cookie (session cookie), or some session id tacked onto the url, which has some unique identification of the current "session" and a way to save the data on the server and retrieve it when given the id from the cookie.
So I would set a cookie based on for example ip + Time.now.to_i and then save that ID and the values I want set into a database or a text file on the hard drive. Note that there is probably a lot better ways to create a unique ID but aim for the simple stuff first. :)
I also recommend that you look into CGI::Session which you require with require 'cgi/session'.