Session_keys table

Discussion forum for MOD Writers regarding MOD Development.
Locked
CMCDragonkai
Registered User
Posts: 483
Joined: Sat Jun 09, 2007 11:37 pm
Location: Australia.. and other parts of the world sometimes...

Session_keys table

Post by CMCDragonkai »

Can anyone please explain in depth what this table is used for?

Thanks for any info.
Show phpbb threads as html articles. V.5.03 Thanks Erik! (This will be updated constantly as I or others contribute...) This code is to be used on external HTML page, but if you want a template version see here.

For the best PHPBB total modification to posting - bbcode, embedding... everything! Visit MSSTI's ABBC3 Modification.
User avatar
AmigoJack
Registered User
Posts: 5774
Joined: Tue Jun 15, 2010 11:33 am
Location: グリーン ヒル ゾーン
Contact:

Re: Session_keys table

Post by AmigoJack »

It's called SESSIONS_KEYS and comments around the usage of that constant are pretty clear: this is for autologin sessions via cookies - better known as "Log me on automatically each visit" feature. In contrast to SESSIONS it stores long time logins.
The worst thing about censorship is ███████████
Affin wrote:
Tue Nov 20, 2018 9:51 am
The problem is probably not my English but you do not want to understand correctly.
...
We will not come anybody anyway, nevertheless, it's best to shit this.
CMCDragonkai
Registered User
Posts: 483
Joined: Sat Jun 09, 2007 11:37 pm
Location: Australia.. and other parts of the world sometimes...

Re: Session_keys table

Post by CMCDragonkai »

Ok, do you know if the session_key id is encrypted? Because when I check my cookies, my 'k' value is not the same as the key value in the database.
Show phpbb threads as html articles. V.5.03 Thanks Erik! (This will be updated constantly as I or others contribute...) This code is to be used on external HTML page, but if you want a template version see here.

For the best PHPBB total modification to posting - bbcode, embedding... everything! Visit MSSTI's ABBC3 Modification.
CMCDragonkai
Registered User
Posts: 483
Joined: Sat Jun 09, 2007 11:37 pm
Location: Australia.. and other parts of the world sometimes...

Re: Session_keys table

Post by CMCDragonkai »

Ok I looked a bit deeper and realized the reason the k value in my cookie and the session key was not the same was because session.php using md5 on the k value.

Upon some more digging, I came to the realization that if someone just hijacked my cookie and got my 'u' value and 'k' value. Couldn't the person log in as me if I had autologin switched on?

I never knew this was that vulnerable. Or am I missing something here?
Show phpbb threads as html articles. V.5.03 Thanks Erik! (This will be updated constantly as I or others contribute...) This code is to be used on external HTML page, but if you want a template version see here.

For the best PHPBB total modification to posting - bbcode, embedding... everything! Visit MSSTI's ABBC3 Modification.
User avatar
AmigoJack
Registered User
Posts: 5774
Joined: Tue Jun 15, 2010 11:33 am
Location: グリーン ヒル ゾーン
Contact:

Re: Session_keys table

Post by AmigoJack »

Code: Select all

    /**
    * Set/Update a persistent login key
    *
    * This method creates or updates a persistent session key. When a user makes
    * use of persistent (formerly auto-) logins a key is generated and stored in the
    * DB. When they revisit with the same key it's automatically updated in both the
    * DB and cookie. Multiple keys may exist for each user representing different
    * browsers or locations. As with _any_ non-secure-socket no passphrase login this
    * remains vulnerable to exploit.
    */
    function set_login_key($user_id = false, $key = false, $user_ip = false) 
Seems so. However, I was unable to hijack myself with a local installation using two different browsers, using auto_login in one of them and then copying all three cookies to the other one - they still always got their own sessions...
The worst thing about censorship is ███████████
Affin wrote:
Tue Nov 20, 2018 9:51 am
The problem is probably not my English but you do not want to understand correctly.
...
We will not come anybody anyway, nevertheless, it's best to shit this.
User avatar
Noxwizard
Support Team Leader
Support Team Leader
Posts: 10406
Joined: Mon Jun 27, 2005 8:41 pm
Location: Texas, USA
Name: Patrick Webster
Contact:

Re: Session_keys table

Post by Noxwizard »

Stealing a session id/key is not enough to get logged in. The IP must match to the extent defined in the ACP. Also, the browser user-agent must match (enabled by default). Additionally, you can have it check the x_forwarded_for value.
[Support Template] - [Read Before Posting] - [phpBB Knowledge Base]
Do not contact me for private support, please share the question in our forums.
CMCDragonkai
Registered User
Posts: 483
Joined: Sat Jun 09, 2007 11:37 pm
Location: Australia.. and other parts of the world sometimes...

Re: Session_keys table

Post by CMCDragonkai »

AmigoJack wrote:

Code: Select all

    /**
    * Set/Update a persistent login key
    *
    * This method creates or updates a persistent session key. When a user makes
    * use of persistent (formerly auto-) logins a key is generated and stored in the
    * DB. When they revisit with the same key it's automatically updated in both the
    * DB and cookie. Multiple keys may exist for each user representing different
    * browsers or locations. As with _any_ non-secure-socket no passphrase login this
    * remains vulnerable to exploit.
    */
    function set_login_key($user_id = false, $key = false, $user_ip = false)  
Seems so. However, I was unable to hijack myself with a local installation using two different browsers, using auto_login in one of them and then copying all three cookies to the other one - they still always got their own sessions...
That is strange. Did you try vardumping the cookie data in the hijacked cookie to see if the cookie actually got passed? Then md5 it to see if it matches the key in the sessions keys table. Maybe you need to quit original browser so it is not accessing a session? Or maybe the session needs to expire first. (after all that's the whole point of autologin, so that when a session expires, a person can still autologin after a day or 2).

I ended up modifying the part where they look for an autologin to match the last used ip to the current ip:

Code: Select all

		// If we're presented with an autologin key we'll join against it.
		// Else if we've been passed a user_id we'll grab data based on that
		if (isset($this->cookie_data['k']) && $this->cookie_data['k'] && $this->cookie_data['u'] && !sizeof($this->data))
		{
			$sql = 'SELECT u.*
				FROM ' . USERS_TABLE . ' u, ' . SESSIONS_KEYS_TABLE . ' k
				WHERE u.user_id = ' . (int) $this->cookie_data['u'] . '
					AND u.user_type IN (' . USER_NORMAL . ', ' . USER_FOUNDER . ")
					AND k.user_id = u.user_id
					AND k.key_id = '" . $db->sql_escape(md5($this->cookie_data['k'])) . "' AND k.last_ip = " . $this->ip;
Noxwizard wrote:Stealing a session id/key is not enough to get logged in. The IP must match to the extent defined in the ACP. Also, the browser user-agent must match (enabled by default). Additionally, you can have it check the x_forwarded_for value.
To my knowledge, the autologin key and the autologin user id are not validated. Are you sure the autologin part is validated, if so, can you show me where in the code it is mentioned.

On line 541, there seems to be some kind of validation for autologin. However there is no method to be called for auth_db. Auth_db is the default authentication method.

Code: Select all

		$method = basename(trim($config['auth_method']));
		include_once($phpbb_root_path . 'includes/auth/auth_' . $method . '.' . $phpEx);

		$method = 'autologin_' . $method;
		if (function_exists($method))
		{
			$this->data = $method();

			if (sizeof($this->data))
			{
				$this->cookie_data['k'] = '';
				$this->cookie_data['u'] = $this->data['user_id'];
			}
		}
I've researched on the vulnerability of 'remember me', 'remain logged in', 'persistent login' systems.

http://stackoverflow.com/questions/549/ ... ion#477579
http://codeigniter.com/forums/viewthread/113781/
http://fishbowl.pastiche.org/2004/01/19 ... _practice/

I think for best secure site, one should remove autologin completely and just extend session time. Even destroy session on browser close.
Show phpbb threads as html articles. V.5.03 Thanks Erik! (This will be updated constantly as I or others contribute...) This code is to be used on external HTML page, but if you want a template version see here.

For the best PHPBB total modification to posting - bbcode, embedding... everything! Visit MSSTI's ABBC3 Modification.
User avatar
Noxwizard
Support Team Leader
Support Team Leader
Posts: 10406
Joined: Mon Jun 27, 2005 8:41 pm
Location: Texas, USA
Name: Patrick Webster
Contact:

Re: Session_keys table

Post by Noxwizard »

Autologin cookies are a slightly different story since the site has no information in which to verify against. If there is an existing session, phpBB will attempt to verify it. If they don't match and you have debug enabled, it will get logged. Failing verification, a new session is started with the autologin key. The session isn't rejected, as this is the entire point behind autologin.

Stealing cookies to log in is hardly new. Cookies are considered a somewhat trusted source as they reside on the user's computer, which is why they're used for autologin on most sites. There was a lot of "drama" a few months ago when Firesheep came out because it automated the process of stealing cookies off the wire and logging into sites like Facebook with them. It's not new, most sites know about it and choose not to do anything about it.
CMCDragonkai wrote:I think for best secure site, one should remove autologin completely and just extend session time. Even destroy session on browser close.
If it's a site that requires security (banking, online purchases, etc...), then:
  1. You shouldn't be saving logins for it anyway (ie. browser's "remember password" option or autologin)
  2. The site should be connecting over https for the entire visit (Facebook only does this for the login form, which is ultimately useless). If the entire visit is encrypted, then cookies can't be read off the wire.
  3. You shouldn't connect to it in a public place unless you've encrypted the connection in another way (VPN).
There's a responsibility on both the site and the user to behave in a secure way.
[Support Template] - [Read Before Posting] - [phpBB Knowledge Base]
Do not contact me for private support, please share the question in our forums.
User avatar
AmigoJack
Registered User
Posts: 5774
Joined: Tue Jun 15, 2010 11:33 am
Location: グリーン ヒル ゾーン
Contact:

Re: Session_keys table

Post by AmigoJack »

CMCDragonkai wrote:Maybe you need to quit original browser so it is not accessing a session?
HTTP only consists of requests and responses; viewing a site does not continue any communication and closing a client doesn't break or end anything. If auto_logins are matched against the last seen user agent its helping a lot, since then you also have to emulate first the same client to "rescue" the session and you don't have to benefit of using your browser of choice in the first.
The worst thing about censorship is ███████████
Affin wrote:
Tue Nov 20, 2018 9:51 am
The problem is probably not my English but you do not want to understand correctly.
...
We will not come anybody anyway, nevertheless, it's best to shit this.
Locked

Return to “[3.0.x] MOD Writers Discussion”