PHP Codeigniter Password decode issue?

[Deep_Coder]

In my codeigniter php login form i'm facing these issues.Password is encrypted in the database.I'm going to decrypt it from the database and allow login.I checked where is the problem.I could find it's in decrypt part.So if anyone can help me i really appreciate that.This is my code.

Model

function userLoginAuthentication($logindata){

        $emailentered=$logindata['email'];
        $passwordentered=$logindata['password'];



        $passwordget = "SELECT password FROM `users` WHERE email=?";
        $passwordgotdatabase=$this->db->query($passwordget,$emailentered);
        $passworddecrypted=$this->encrypt->decode($passwordgotdatabase);

        $useractivatedget="SELECT is_activated FROM `users` WHERE email=?";
        $useractivatedgetdatabase=$this->db->query($useractivatedget,$emailentered);


            if ($passwordentered==$passworddecrypted && $useractivatedgetdatabase=1) {
                redirect(base_url().'Index/userLoginSuccess');
                return TRUE;
            }
            else{
                redirect(base_url().'Index/userLoginRedirection');
                return FALSE;
            }

    }

Controller

public function userLogin()
    {
        $this->load->view('header');
        $this->load->view('userLogin');

        if($_POST) {
            $logindata=array(
            'email'=>$_POST['email'],
            'password'=>$_POST['password']
            );

        $login_confirm=$this->indexModel->userLoginAuthentication($logindata);

        if ($login_confirm){
            echo 'USER PROFILE';
            }
            else {
                echo 'TRY AGAIN';
            } 
            }

            $this->load->view('footer');
    }

[Atli]

Passwords generally aren't encrypted, but rather hashed. The difference is that encrypted data can be decrypted, whereas hashed data can not be decrypted. How exactly are your passwords "encrypted" before they are put into the database?

If they are in fact encrypted rather than hashed, you really should consider switching to hashing instead. Nobody ever needs to see - nor should be capable of seeing - the plain-text version of a password saved in the database.

Also a few other things worth mentioning:

• I'm not used to working with CodeIgniter, but executing two queries to fetch two fields from the same table, based on the same primary key, seems a complete waste to me. (Regardless of what framework you are using.) Why not fetch the password and is_activated fields both using a single query?

• It seems a bit odd to be redirecting the client inside the model. That kind of action really should belong to the controller. (Though, granted, the MVC pattern is fairly vague when it comes to specifics like these.)

• I'd also like to comment on the fact that you create an array of un-validated and raw POST values, pass it into a function through one parameter, and then just expand it back into a list of local variables inside the function. It seems to me that it would be far cleaner to just pass each of those values into the function through it's own function parameter.

[Deep_Coder]

Thanks for your valuable comment :)

And anybody can help me to solve this?

[diafol]

I thought Atli made it clear that passwords are hashed not encrypted. That means they can't be decrypted (or 'unhashed'). Passwords are stored as hashes so if somebody got hold of the data from the DB, they wouldn't be able to get the raw passwords - which could be disasterous for individuals if they use the same pw for most of their accounts. However, this means you can't retrieve a pw via 'forgot my password', you need to send a link in an email that includes a unique token to allow the user to create a new pw.

[Deep_Coder]

@diafol:No encryption and decryption is working properly.I tested it manually.But when interacts with the database it's not working.

[Atli]

Could you show us the code that creates the passwords?

[Banderson]

Here is the way it is suppose to be done. When a user registers the password is hashed and salt is applied to that hash and the hash goes into the database with the salt. Now when the user signs in you apply the same algorithm to the password and you match the hash not the plain password. As others have stated do not use encrypt on passwords with codeIgnitor. If a knowingly user gains access to your database they could easily decrypt all your passwords with a rainbow table attack to find your encryption key. Use encrypt for your sessions not passwords.

I am left to wonder why you are reinventing the wheel. Many developers have already created systems that have been time tested and are proven to work for frameworks like CodeIgnitor. That's why we design classes for other developers to build upon. Developers want to move forward, building better, safer and faster apps, not spin our wheels. Here is the one I use in all my apps, commercial and private.

http://haseydesign.com/flexi-auth/

[iamthwee]

Just to echo the importance of hashing a password over encrypting...

You can do this in CI easily

$password = $this->encrypt->sha1('foobar');

If you don't understand why you SHOULD by hashing over encrypting go no further! Your system is a danger to the general public and their sensitive information!

[Deep_Coder]

@Banderson:Thanks for your long comment and your advice.I was used CI encryption,decryption because of they have it.Anyway i'll consider on your opinion.thanks again.

@iamthwee:Thanks for your comment too.I'll chek it.

[Atli]

You can do this in CI easily
$password = $this->encrypt->sha1('foobar');

There are two things about that, though, that are less than ideal.

First, SHA1 is fairly weak at this point. It's not an algorithm you should be using any more. If you are using traditional hashing, then you should at least be using something like SHA2 (SHA256 or SHA512) or Whirlpool. PHP's hash() function gives you easy access to all sorts of algorithms, many of them preferable to SHA1.

Second, the above CI example doesn't deomstrate salting. That's more or less a requirement when dealing with sensitive info like passwords. You can do it the old-fashioned way, or just use functions like hash_hmac() instead of the normal hashing functions.

Additionally, traditional hashing is rapidly becoming obsolete. I won't go into too much detail here (there are discussions about this all over the internet), but I'll just say that not even hashes like SHA512 or Whirlpool can be considered "safe" these days; they can be brute-forced to quickly. If security is important to you, you should be considering a switch to something like bcrypt or PBKDF2.

[iamthwee]

^^ All good points however, I will say unless you're opting for cast iron security (i.e a banking app) or something the likelihood is the OP is needing to store a users' password for a simple website.

Hashing sha1 with a salt would suffice here...

Additionally, I like to throw in a javascript validation at password creation to ensure the user picks a minimum numbers of characters with upper case + lower case characters.

Anything else go for bcrypt of course.

[Atli]

Even simple websites shouldn't really be going easy on password security. I mean, they are actually the more likely target for hackers looking for passwords. Most people tend to reuse their passwords all over the web, so if you get a list of email/username and password combos from the database of some small, inconsequential websites, odds are that many of those same combos will get you into a Facebook or Google accounts, or even something more secure like a bank.

Besides, there really is no reason to use SHA1 when using a stronger algorithm is just as easy.

$password = $this->encrypt->sha1('foobar' . "salt!");
$password = hash("sha512", "foobar" . "salt!");
$password = hash_hmac("sha512", "foobar", "salt!");

The CI documentation for the sha1 method even mentions that using PHP's native hashing functions is simpler than using CI's. - Although, it is specifically talking about the sha1() function, not hash() or hash_hmac(), but the point still stands.

[iamthwee]

Besides, there really is no reason to use SHA1 when using a stronger algorithm is just as easy.

I stand corrected, I just did a bit of research and although sha1 looks secure enough barring banking applications or top government security using SHA256 is just as easy. Thanks for the heads up.