why session lifetime always 0

[objnoob]

Why would you even need to get the expiration time when you're the one setting the expiration time?

 

When the user logs in, if they checked stay logged in the set cookie expiration in a year, otherwise set expiration time to 0. when they click sign out delete the cookie.

 

You need do nothing more, but this is NOT recommended!

 

Anyways server could care less when your stupid cookie expires. Cookies are a browser thing. If you need the cookie expiration.... then STORE IT!

Edited October 29, 2013 by objnoob

[objnoob]

And, not to forget... it doesn't guarantee the server will even keep the session open for a year.

 

I try to help you and you ridicule me.

Why don't you go... ?logout=true

Lol, just kidding. Seriously, You don't even need =true since logout will never be anything else and an empty string is considered set and (isset($_GET['logout'])) will be true just using mysite.com?logout

[phat_hip_prog]

when someone visits the site a session cookie is set, then they log in. you can't tell if they have a session cookie or not until you start the session (hence this thread). also, without an additional cookie or starting the session you can't get any stored info because we don't know who it is

 

how does an additional cookie provide more security? if someone can hijack one then they'll technically have the other too...?

 

the tutorial on this site *must have been devshed or other (may check later, but here's phpfreaks tutorial http://www.phpfreaks.com/tutorial/sessions-and-cookies-adding-state-to-a-stateless-protocol ) stores the password hash in session vars (personally i see hash's of password n other static data as sensitive, if you ever went on the silk road you'd see the size of hash cracking gangs out there), also numerous commentators on here also swear by session cookies being better that standard cookies because the server does various checks such as ip, etc... (not seen evidence but...)

 

you're right the server may have deleted the session cache if its expiry date was not set correspondingly too

 

 

BTW the login / logout buttons are hypothetical in this case, i avoided db use for this isolated example so it could just be dropped in to test. (probably why i was shocked at GET use gives self a Gibbs slap then does D'nozzo confused look in mirror)

 

at current in production i use both sessions and cookies, but on my smartphone games i don't even use cookies because well, they don't exist, i mention this because these aren't real time and communicate with php pages. this foray was inspired by this thread from last week where someone was discussing doing it without session cookies. http://forums.phpfreaks.com/topic/283245-are-sessions-redundant/

[phat_hip_prog]

for all, this is worth a read if you're interested in security

http://www.phpfreaks.com/tutorial/php-security

[objnoob]

 you can't tell if they have a session cookie or not until you start the session (hence this thread).

 

You can check if a session cookie exists using the $_COOKIE super global before doing any sesssion_* calls. 

 

 

 

how does an additional cookie provide more security? if someone can hijack one then they'll technically have the other too...?

 

• because... it's a remember me cookie!  and it still authenticates the user with username and password before starting a session.
  • ​if user changes username or password, all previous remember me keys will not authenticate
• because... you're not keeping the session open for eons. keeping the session open with extended session inactivity invites session hijacking.
• because... if the user deletes their cookies after you create this year long session, they may eventually log back in and now you have 2 year long sessions open on your server for the same user.
  • delete cookies, long back in and now you have 3, year long, sessions open on your server for the same user.
  • delete cookies, long back in and now you have 4, year long, sessions open on your server for the same user.
  • delete cookies, long back in and now you have 5, year long, sessions open on your server for the same user.
  • ALL THESE SESSION ARE VULNERABLE TO SESSION HIJACKING!!!

Thanks for the link, however you will benefit from reading that more than me!

Edited October 29, 2013 by objnoob

[phat_hip_prog]

hmmm, yes but since you can't query the expiry date it's pointless (it could be non-logged, logged in session or logged in longtime), you only know once the session is started by the existence of the session vars

 

 

 

the remember me cookie can be copied too and its exposing your hashed private details (replay attack / man in the middles, rainbow tables, etc)

 

the remember me cookie would require same lifetime (how long isn't really the issue here, but it'd be same for both)

 

if they delete the cookies then the session vars would be orphaned yes, but if you use any form of session then the issue stands for both, but nice point

[objnoob]

One thing you can do.... which I don't recommend, but is a better solution...

 

Have 2 types of session cookies! You can designate the type in the session name...

SESSION_USER, SESSION_VISITOR     Naming your sessions with Session, or using the default session name is a bad idea. You're basically telling everyone which cookie is the one they want to steal!

 

First thing to do is check if one is set.  You can do this using $_COOKIE superglobal  EX:   isset($_COOKIE['session_user'])

If the cookie is set, then you know the expiration date, because when it's a session_user  it expires a year from now, if not... it expires at browser windows closed.

I want to mention the session cookie expiration time has nothing to do with the set maxlife of the session on the server!

 

It's rare that I ever start a session for a user that has not been authenticated. In other words, I don't create sessions for visiting users.

[objnoob]

the remember me cookie can be copied too and its exposing your hashed private details (replay attack / man in the middles, rainbow tables, etc)

Sure it can, but it's better to exposed hashed private details than it is to expose a year long session cookie that grants full access to your user's account!

And, like I said..... a number of times. If the remember me hash is derived from the user's password, when that user changes their password... any old keys derived from the old passcode wont validate.

In otherwords, when I change my password, all the computers I've used to sign into your site and clicked remember me have now forgotten me!!! 

Edited October 29, 2013 by objnoob

[phat_hip_prog]

One thing you can do.... which I don't recommend, but is a better solution...

 

Have 2 types of session cookies! You can designate the type in the session name...

SESSION_USER, SESSION_VISITOR     Naming your sessions with Session, or using the default session name is a bad idea. You're basically telling everyone which cookie is the one they want to steal!

 

First thing to do is check if one is set.  You can do this using $_COOKIE superglobal  EX:   isset($_COOKIE['session_user'])

If the cookie is set, then you know the expiration date, because when it's a session_user  it expires a year from now, if not... it expires at browser windows closed.

Why didn't I think of that???

I don't see it really being an issue because cookies are easy to see and send all along 'cos that's what happens anyway. (I do in my scraper anyway)

 

I want to mention the session cookie expiration time has nothing to do with the set maxlife of the session on the server!

i know there is an ini setting for it but never read the manual entry for it though, good to know!

 

It's rare that I ever start a session for a user that has not been authenticated. In other words, I don't create sessions for visiting users.

I like those types of sites!

[phat_hip_prog]

Sure it can, but it's better to exposed hashed private details than it is to expose a year long session cookie that grants full access to your user's account!

but an extra cookie with those details does the same thing anyway... it's just two keys instead of one, but if you have access to one you also have access to the other

 

And, like I said..... a number of times. If the remember me hash is derived from the user's password, when that user changes their password... any old keys derived from the old passcode wont validate.

In otherwords, when I change my password, all the computers I've used to sign into your site and clicked remember me have now forgotten me!!! 

absolutely, however many examples do the same but store that as a session var instead

 

i read this many years ago and have always added something somewhat random to hashes and store it along side user info, generally i just store last_login_time, so the hash changes everytime you log in

http://www.amazon.co.uk/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr_1_1?

(a lot of the algorithm stuff may be out dated but the protocol analysis is still valid)

[objnoob]

I cannot lend you any more support. You've missed the numerous points I've made, and the least I can say is you should seriously reconsider your approach to sessions!

 

I don't code games, I code life! :]

[phat_hip_prog]

thankyou, but still not convinced using an extra cookie offers any extra protection

 

but with your session name concept at least it doesn't have to set the session cookie info twice anymore

[DavidAM]

This bears repeating.

I want to mention the session cookie expiration time has nothing to do with the set maxlife of the session on the server!

Even if you set the COOKIE expiration to a year, you can NOT be sure the SESSION data ON THE SERVER will survive that long.

 

Unless you are using a CUSTOM session handler, session.gc_maxlifetime controls how long the session data file survives.

 

If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.

If you try to change the session lifetime, you have to change it for ALL SCRIPTS using SESSIONS at the session.save_path of your site.

 

If you are going to use a custom session handler to get around this issue, then you may as well use a standard COOKIE (not the session one) and handle the extended expiration in the custom session handler.

 

 

The other solution I see, is to leave the standard session cookie alone, and add a second cookie for "Stay Logged In". When you get a request with a "Stay Logged In" cookie (and no active session), you lookup the nonce in the database to identify the user and start a new session (just as if they had logged in). Yes, this effectively reduces the login from two tokens (username and password) to a single token (the nonce), but that is the choice you and the user make when implementing/using this system. You could carry a flag in the session that indicates you don't have a real authentication from the user, so if they try to do something critical (i.e. change their password), you can require them to authenticate by entering their existing password.

 

I don't recommend this (Stay Logged In) for highly sensitive sites, because it is not highly secure. There is a reason you don't see "Stay Logged In" at your Banking sites.

 

And, for the record, the nonce in the "Stay Logged In" cookie is NOT the user's password (hashed or otherwise), it should be (IMHO) a hash generated specifically for that purpose. (And, of course, it must be unique in the database).

[objnoob]

 

 

And, for the record, the nonce in the "Stay Logged In" cookie is NOT the user's password (hashed or otherwise), it should be (IMHO) a hash generated specifically for that purpose. (And, of course, it must be unique in the database).

 

Nope, not a nonce. How do you consider this a nonce when it is used over and over to remember and thus re-authenticate the user?

If you're creating custom strings (to be used as hash) that are not directly derived from the user detail already on file, you better invalidate these when the user changes their password. Or you'll need a forget me button!

 

And, yes.. I agree a 'Remember Me' is insecure to begin with! I've never in my entire career implemented a remember me that was authenticating!

[phat_hip_prog]

This bears repeating.

Even if you set the COOKIE expiration to a year, you can NOT be sure the SESSION data ON THE SERVER will survive that long.

 

Unless you are using a CUSTOM session handler, session.gc_maxlifetime controls how long the session data file survives.

 

If you try to change the session lifetime, you have to change it for ALL SCRIPTS using SESSIONS at the session.save_path of your site.

i was guessing that the session data had a timestamp which got updated on each start?

 

the survival of the session (data) is yes an issue, not wanting to be flippant but it's not a security issue, however it is an annoyance / flaw to this concept...!

 

If you are going to use a custom session handler to get around this issue, then you may as well use a standard COOKIE (not the session one) and handle the extended expiration in the custom session handler.

i was thinking of this last week, considering if it was faster to use session files or just easier and faster to use the database (see your next point)

 

The other solution I see, is to leave the standard session cookie alone, and add a second cookie for "Stay Logged In". When you get a request with a "Stay Logged In" cookie (and no active session), you lookup the nonce in the database to identify the user and start a new session (just as if they had logged in). Yes, this effectively reduces the login from two tokens (username and password) to a single token (the nonce), but that is the choice you and the user make when implementing/using this system. You could carry a flag in the session that indicates you don't have a real authentication from the user, so if they try to do something critical (i.e. change their password), you can require them to authenticate by entering their existing password.

yes i went this way last week, ignored sessions all together

 

I don't recommend this (Stay Logged In) for highly sensitive sites, because it is not highly secure. There is a reason you don't see "Stay Logged In" at your Banking sites.

I can honestly say that my bank does have a stay logged in button, but there is a warning, then they have a default timeout thing (not sure if that doesn't work if check stay logged in because i've never checked it)

 

And, for the record, the nonce in the "Stay Logged In" cookie is NOT the user's password (hashed or otherwise), it should be (IMHO) a hash generated specifically for that purpose. (And, of course, it must be unique in the database).

yes, in my production sites it uses other user info, site salt, user salt and last login time, it is repeatable. Edited October 29, 2013 by phat_hip_prog

[phat_hip_prog]

Nope, not a nonce. How do you consider this a nonce when it is used over and over to remember and thus re-authenticate the user?

If you're creating custom strings (to be used as hash) that are not directly derived from the user detail already on file, you better invalidate these when the user changes their password. Or you'll need a forget me button!

 

And, yes.. I agree a 'Remember Me' is insecure to begin with! I've never in my entire career implemented a remember me that was authenticating!

you're right, it's a salt, but i sometimes use the following interchangably ('cos i smoke too much crack ) iv's, nonce or salt

 

i agree that stay logged in is an issue, but if you want go that way let's enforce excellent passwords too, yet usually our client clients will go else where if they have to log in each time, usability is an annoying from a security standpoint but generally a necessity IMHO

[objnoob]

Nope. Nope. Nope.

 

session.gc_maxlifetime is a misnomer!  And it should be renamed gc_minlifetime!   because it's the minimum time the session is to remain open on the server, unless explicitly deleted.

In reality, the actual session alive time is a probability that the garbage collector run! You can make the probability 100% that each request will fire the garbage collector. Even doing so... the session is theoretically alive until the GC cleans it up...   session maxlifetime =  400        lifetime = 500    the session is alive until the garbage collector fires to delete the session.

[phat_hip_prog]

zulooump, that's the sound of me suggesting "stay logged in", objnoob is the dog btw...

 

[DavidAM]

Nope, not a nonce. How do you consider this a nonce when it is used over and over to remember and thus re-authenticate the user?

Oops! I misspoke. It is not a nonce, it is just a unique token.

 

And, yes.. I agree a 'Remember Me' is insecure to begin with! I've never in my entire career implemented a remember me that was authenticating!

A "Remember Me" (in my book) just remembers and fills in my login name on the login form. It is different from a "Stay Logged In", which actually authenticates. However, I rarely use the "Remember Me" because on most sites, it is not clear if they are using it to "Remember Me" or to Keep me Logged In (which I don't want, most places).

 

 

i was guessing that the session data had a timestamp which got updated on each start?

The garbage collection uses the file's last modification timestamp to determine how old the file is. So the session data ages unless you actually modify/update the session data.

 

the survival of the session (data) is yes an issue, not wanting to be flippant but it's not a security issue, however it is an annoyance / flaw to this concept...!

It is a security issue, especially on a shared host. The default is to write the files to /tmp which is WORLD READABLE. So anyone who has or gains access to the server can read the session data - it is NOT encrypted.

[phat_hip_prog]

A "Remember Me" (in my book) just remembers and fills in my login name on the login form. It is different from a "Stay Logged In", which actually authenticates. However, I rarely use the "Remember Me" because on most sites, it is not clear if they are using it to "Remember Me" or to Keep me Logged In (which I don't want, most places).

never in my life seen it implimented that way

 

The garbage collection uses the file's last modification timestamp to determine how old the file is. So the session data ages unless you actually modify/update the session data.

so it doesn't use access, hmmm and it's monitoring the changes in session vars and only writing them back out if modified, ok

 

It is a security issue, especially on a shared host. The default is to write the files to /tmp which is WORLD READABLE. So anyone who has or gains access to the server can read the session data - it is NOT encrypted.

glad that in reality i don't use session vars and just use the db, not in Linux at mo and i've never checked what permissions that are used in tmp. are we just talking httpd / apache or nginx, lighttpd, etc too?

[DavidAM]

never in my life seen it implimented that way

Yeah, I'm a very literal person, and that's the way I interpret the words.

 

so it doesn't use access, hmmm and it's monitoring the changes in session vars and only writing them back out if modified, ok

According to the manual, it used to use access-time; but now uses modification time. I have an in-house app that uses sessions. When I wrote it, I did not consider the distinction. Sometimes, I can use it all week without having to login again. Sometimes, I have to login twice in the same day. It all depends on how much use the app gets, since garbage collection is only considered when session_start() is called.

 

glad that in reality i don't use session vars and just use the db, not in Linux at mo and i've never checked what permissions that are used in tmp. are we just talking httpd / apache or nginx, lighttpd, etc too?

My only experience is with Apache. I cannot speak to how others handle it. However, these settings are controlled in PHP, so I would think it applies across the board. Wherever the session files are written, the directory MUST be readable and writable by the (system) user that the web server runs as.

[objnoob]

you're right, it's a salt, but i sometimes use the following interchangably ('cos i smoke too much crack ) iv's, nonce or salt

 

It's not even a salt.  Strings are salted before being hashed to prevent them from being found in rainbow tables.

In my authenticating 'Remember Me' example, you'll see that I've salted the user's password twice before hashing it with sha256. Once with the user's internal unique database id, and once with a hard coded string 'Im_A_SaLTiNE_CrAcKEr'

[phat_hip_prog]

using the id as a salt isn't really up to the job, if i was to look at how many registered users there are on the site (if shown) then i could make a guess at the id. generate a new pseudorandom string for each user on password generation

 

many think of rainbow tables having to be generated for each instance, you can build a general lookup table for a given length keyspace, then you can just extract at will, i shouldn't mention that the same can be done for public keys or one time pass's, but yes that comes down to storage (public key primes are set to be a minimum size and generally not over a certain size, so the keyspace isn't as big as some report)(use references for less memory too!)

 

 

numerous tutorials now tell you to regen the session_id on every page request, essentially making this simple cookie ref a nonce

[objnoob]

Yes, session id regeneration is a defense against session hijacking.

 

Leaving a session open for a year defeats the purpose of session id regeneration as a form of protection! 

When the user stops making requests... the session id does not regenerate!

 

 

 

 

using the id as a salt isn't really up to the job, if i was to look at how many registered [...]

I'm not here to write any code to your specification.  The authenticating 'Remember Me' key is salting, not once but twice, and hashing an already salted and hashed password.

The user password should already salted and stored as a hashed value in the database. You never store naked user passwords in case your database becomes compromised!

Edited October 30, 2013 by objnoob

[phat_hip_prog]

Yes, session id regeneration is a defense against session hijacking.

 

Leaving a session open for a year defeats the purpose of session id regeneration as a form of protection! 

When the user stops making requests... the session id does not regenerate!

 

 

 

 

I'm not here to write any code to your specification.  The authenticating 'Remember Me' key is salting, not once but twice, and hashing an already salted and hashed password.

The user password should already salted and stored as a hashed value in the database. You never store naked user passwords in case your database becomes compromised!

KEEP CALM NOBODY IS PERFECT, this is just a discussion