Storing Encrypted Password in Session variables

[eluser]ufasoli[/eluser]
Hello,
I was wondering if it's really unsafe to store the user's id and password in a session variable after he has logged in. I use this in a form where the user can modify personal information. This is how I thought I could do it

Code:

function checkLogin() //checks to see if the user exists in the database
{



    $login = $_POST['login'];
    $pwd = $_POST['pwd'];

    $query = $this->db->getwhere('utilisateurs', array('userid' => $login, 'pwd'=> $pwd));



        if($query->num_rows() != 1)
        {
            $msgLogin = "<h3 style=\"color: #663300;\"> Erreur de Connexion : </h3> <h4> Votre identifiant ou votre mot de passe est incorrect. </h4>";
            echo $this->ajax->tag("\n adjustSizes('loginError'); \n new Effect.Appear('errorDiv', {beforeStart: function(){Element.update('errorDiv','$msgLogin')}})");


        }
        else
        {
            $query->free_result();

            $userData = array(
            'userid'=> $this->user->userid, 'pwd' => $this->user->pwd,
            'nom'=>$this->user->nom
            );

            $this->session->set_userdata('userData', $userData);
            echo $this->ajax->tag("location.href ='".base_url()."Account/userAccount'");


        }

I have set the

Code:

$config['sess_encrypt_cookie']    = TRUE;

and the

Code:

$config['encryption_key'] = '1111'

the simple 1111 encryption key is only for test purposes

so whenever the user wants to modify some info this is how I do it

Code:

function updateUserInfo()
{
          $userdata = $this->session->userdata('userData'); //gets the userid and password
        
    $data = array
                   (    
                     "habitation" => $_POST['habitation'],
                      "situation_h" => $_POST['situation_h']     )
            ;
                
         $this->db->where('userid', $userdata['userid']);
         $this->db->where('pwd', $userdata['pwd']);
         $this->db->update('utilisateurs', $data);
        
         if($this->db->affected_rows() != 1)
         {
            
             echo $this->ajax->tag("alert(\"Un probl\\350me est survenu les modifications n\\47ont pas \\351t\\351 effectu\\351es\"); ");
         }
        


}

Thank you in advance

Ulises

[eluser]Mark van der Walle[/eluser]
Storing data in sessions is not that unsafe, just note that if you are on a shared host all other sites can read your sessions data. Having it encrypted helps ofcourse. If you use the standard CI session then they are stored in the database and the problem is alot less.

All in all it is not that unsafe really.

[eluser]xwero[/eluser]
Normally the userid would be unique so you can only store that in the session id. If someone hijacks the session cookie he has some id of which the hacker doesn't know if it's going to change randomly. You could even create a userid to put in sessions or cookies so the real id is only reachable internally.

Storing a password in the session is a bad idea i think. Some technical aware users flinch when they see the password is send in plain text but hashing on the clients machine is open to other attacks i read recently. If they know their password is stored in a session cookie + session db if coded they will go crazy You should only do adding, updating and password checks. Maybe for some updating is already a bridge too far.

I think if you want the 'most' secure option not making it to difficult for yourself you should consider a changable unique session/cookie userid.

[eluser]Mark van der Walle[/eluser]
I just commented on the question. Not if it is betetr or not. But to do this now:
passwords should only be stored in one location (well ofcourse the users mind ). There are many other ways to check if someone is logged in. Only the first login should be checked using username password after that something different will suffice.

[eluser]ufasoli[/eluser]
[quote author="xwero" date="1196787168"]Normally the userid would be unique so you can only store that in the session id. If someone hijacks the session cookie he has some id of which the hacker doesn't know if it's going to change randomly. You could even create a userid to put in sessions or cookies so the real id is only reachable internally.

Storing a password in the session is a bad idea i think. Some technical aware users flinch when they see the password is send in plain text but hashing on the clients machine is open to other attacks i read recently. If they know their password is stored in a session cookie + session db if coded they will go crazy You should only do adding, updating and password checks. Maybe for some updating is already a bridge too far.

I think if you want the 'most' secure option not making it to difficult for yourself you should consider a changable unique session/cookie userid.[/quote]

So you think storing the session in the database is a bad idea too? What do you actually mean when you say "consider a changable unique session/cookie userid"? That each time a user logs in I should create a 'fake' id and store it in a session variable?

[eluser]xwero[/eluser]
No i didn't say storing session data in a database is a bad idea. But if you have a password in the session it will get stored in the database so then there are two places where the password is stored which isn't a good idea. The more data (password in this case) gets spread around the more chance somebody could pick it up.

You can create an disposable id when a user logs in but i think if the user logs in on another place at the same time the previous id will be invalid so he can't get back to work on the other machine. If that is what you want you can do that.
But i was thinking about an extra field in the password table where you generate a steal-this-id/fake id and that id is used instead of the the real id. And you use the real id as a foreign key in tables who require it. This way you could regenerate the steal-this-id every other time for extra security.

If you don't have unique ids you could use a collection of fields that make the user identifiable without using the password. For instance if you want users to be able to log in with the same login and password but in another role (admin, author, ...) the user id and the role id makes the user unique.

[eluser]ufasoli[/eluser]
[quote author="xwero" date="1196805578"]No i didn't say storing session data in a database is a bad idea. But if you have a password in the session it will get stored in the database so then there are two places where the password is stored which isn't a good idea. The more data (password in this case) gets spread around the more chance somebody could pick it up.

You can create an disposable id when a user logs in but i think if the user logs in on another place at the same time the previous id will be invalid so he can't get back to work on the other machine. If that is what you want you can do that.
But i was thinking about an extra field in the password table where you generate a steal-this-id/fake id and that id is used instead of the the real id. And you use the real id as a foreign key in tables who require it. This way you could regenerate the steal-this-id every other time for extra security.

If you don't have unique ids you could use a collection of fields that make the user identifiable without using the password. For instance if you want users to be able to log in with the same login and password but in another role (admin, author, ...) the user id and the role id makes the user unique.[/quote]

So let me see if I understand what you are saying(sorry sometimes I can be quite thick)..

I should a create a table like this for example:

Users (userid, password, lastname, firstname, id_code)

When the users logs in using his userid and password, I generate a random Id that I store in the "id_code" field and the session variable, and then use this randomly generated id as unique identifier?
Another solution could be to hash the userid field in the table, do you think this could be a good idea?

[eluser]xwero[/eluser]
If you are going to use the steal-this-id solution you generate an id for the id_code field when the profile is created. To add security you can write a cron script to regenerate the id in the id_code field every week, every day depending how paranoid/security minded you are

The other solution you offer would be a bit faster (no query to get the real id) and one field less in your database so it is a better solution. I guess you could use the encrypt library for this.

[eluser]Mark van der Walle[/eluser]
what about just storing in the session if a certain user is logged in? sessions are user based after all. here is some pseudo code.

Code:

function login()
{
    // check username/password versus database/filesystem/whatever
    
    // if successfull set session flag
    $_SESSION['is_logged_in'] = true;
}

function is_logged_in()
{
    if (isset($_SESSION['is_logged_in'] && $_SESSION['is_logged_in'] === true) {
        return true;
    }
    return false;
}

function logout()
{
    unset($_SESSION['is_logged_in']);
}

if you want you could also store the users IP in the sessions and also check for that. In bases of security this might not be the most safe but it is functional and imho safer than storing passwords in sessions.

[eluser]xwero[/eluser]
@mark : I don't think the problem is if a user is logged in or not but how to log actions for that user (change his data, add something on the site, ...) so you need some kind of id that gets stored in the session to add to the tables where it's needed.