Authentication and Sessions

[eluser]Peng Kong[/eluser]

Code:

Remember the difference between encrypting and hashing - hashing is one way. Sure, a rainbow table is going to find the hash for integers pretty quick, but it would take quite awhile for a rainbow table to find the hash for an unknown combination of data (let's say, a concatenation of the user's salt, username, password, and timestamp of record creation). That's where the true security lies in this - you grab their ID and token (the concatenation hash), select on the DB, hash their record and see if it matches the token. If not, something has been tampered with.

ok but can't i simple juz copy the cookie when the user isn't at his desk and do a session fixation attack from my own com?

sorry i really dunno how non-db ci sessions works... i always use db sessions because authentication is my main use case for sessions.

oh and what unknown combination are you taking about with a auth library released in the open? haha everyone knows the long combination unless you change it. And if you're smart enough to change it for security you would have figured no cookie standalone auth is going to work.

[eluser]Michael Wales[/eluser]

ok but can’t i simple juz copy the cookie when the user isn’t at his desk

Definitely but then we're getting into physical security issues. There's not much we can do to prevent this form of attack, except for CodeIgniter updating the session with a new ID every [insert configuration setting] seconds.

[eluser]Peng Kong[/eluser]
[quote author="Peng Kong" date="1265408196"]
oh and what unknown combination are you taking about with a auth library released in the open? haha everyone knows the long combination unless you change it. And if you're smart enough to change it for security you would have figured no cookie standalone auth is going to work.[/quote]

sorry bad habit of editing stuff into posted stuff.

yep so as i was saying the worst case scenario is that the programmer won't change the default combination of stuff you used to hash, making it way less secure.
maybe only timestamp isn't guessable... but anyway this discussion won't go far. cookie standalone security is a bad idea. what so hard about

Code:

$config['sess_use_database']    = TRUE;

makes everything so much more secure.

ci session without db isn't mean for auth... it's meant for say.. some flashdata kind of usage. maybe they should write that somewhere in the manual... wait in fact they did.

unless you store session data in a database there is no way to validate it.

[eluser]Michael Wales[/eluser]
Yeah, I thought we were beyond the cookie-based session is insecure discussion and were just discussing general security measures and ways to make the cookie more secure than it is.

oh and what unknown combination are you taking about with a auth library released in the open?

The fields themselves don't matter - it's the content within the fields. There's a lot more content that is not publicly available in an account that one would think - just salt and created_on would be enough to generate a hard to reverse hash - definitely enough to bring it outside of the scope of rainbow tables, leaving brute force the only option available.

That's really the only goal with hashes - get them obscure enough to be outside the scope of a rainbow table and physically random enough to be way down the list of an alphanumeric iterator. If you are hashing abc, an iterator is going to get there pretty quick. If you are hashing ab2010-02-10c, it's going to a bit longer for an iterator to get there.

[eluser]Peng Kong[/eluser]
yep you're right that does makes cookie based session secure

[eluser]Joseph Wensley[/eluser]
[quote author="Michael Wales" date="1265405068"]You're making a lot of assumptions here though - you are assuming the developer has session encryption turned on and is using database storage of the session (which has its own set of pros/cons).

Your post also made it seem as if your authentication library was only storing the ID - no other information, which is obviously a bad idea.

Wouldn't it be exponentially more secure to store the user ID and a hash of some of the user's data in the session? This simple change, regardless of the application's configuration, gives you the means to identify the user (the ID) and validate the session data hasn't been tampered with (the hashed data from their record).[/quote]

I am using encrypted sessions and database storage so I don't think anyone spoofing the session will be an issue.

As for storing the id and a hash in the session would something like this be what you mean?

Code:

<?php
function login()
{
    $CI =& get_instance();
    
    $data['username'] = $CI->input->post('username');
    $data['password'] = $this->hash_password($CI->input->post('password'));

    $query = $CI->db->get_where('users', array('username' => $data['username'], 'password' => $data['password']));
    $rows = $query->num_rows();
    
    if($rows == 1)
    {
        $row = $query->row();
        
        $hash = $this->hash_password($row->username.$row->id.->$row->password);
        
        $session_data = array(
            'user_id'        => $row->id,
            'hash'            => $hash,
        );
        $CI->session->set_userdata($session_data);
        
        return array(TRUE, null);
    }
    else
    {
        return array(FALSE, 'Username/Password combination does not exist');
    }    
}

function is_loggedin()
{
    $CI =& get_instance();

    if($CI->session->userdata('user_id') && $CI->session->userdata('hash')){
        $user_id = $CI->session->userdata('user_id')
        $sess_hash = $CI->session->userdata('hash');
        
        $query = $CI->db->get_where('users', array('id' => $user_id));
        $row = $query->row();
        
        $hash = $this->hash_password($row->username.$row->id.->$row->password);
        
        if($hash == $sess_hash){
            return TRUE;
        }else{
            return FALSE;
        }
    }else{
        return FALSE;
    }
}

?>

[eluser]Michael Wales[/eluser]
Yup - that is pretty much the way I am doing it in ErkanaAuth 2.

[eluser]Peng Kong[/eluser]
if db is used, the hash is pointless, since session data is stored in the db and not on the cookie, the hash would just be taking up db space. tempering with the cookie just means losing access to the session (row in session table), the best someone could do is try to do fixation or spoofing.

Michael concern was regarding distributed auth libraries where there was a possibility of a non db, non-encrypt session configuration, by putting a hash in the cookie the risk is mitigated.

To be secure ALL custom data in the cookie, ALL custom data has to be in the hash together with a non-guessable, non-public viewable piece of data (i thinking the user's password is a perfect candidate of this).

Maybe something like this?

When storing...

Code:

if ( ! sess_db_in_use)
{
    cookie_data['id'] = db_id;
    cookie_data['name'] = db_name;
    cookie_data['hash'] = sha1(db_id.db_name.db_password);
}

Before using session data

Code:

if ( ! sess_db_in_use)
{
    if (cookie_hash == sha1(cookie_id.cookie_name.db_password)
    {
        // we can trust that the cookie data wasn't tampered
    }
}
else
{
    // we can always trust that db custom data isn't tampered
}

what do you guys think?