Jump to content

Recommended Posts

Yes it is.

 

The only alternative I can think of are cookies, but they store information on a user's computer - a great security risk.

 

Overall, sessions are the best way to go. However, if you are transferring social security numbers or credit card digits - make sure you get a SSL (HTTPS) connection/certificate.

Yes it is.

 

The only alternative I can think of are cookies, but they store information on a user's computer - a great security risk.

 

Overall, sessions are the best way to go. However, if you are transferring social security numbers or credit card digits - make sure you get a SSL (HTTPS) connection/certificate.

 

You do realize that sessions, by default, use cookies, right?

It's true that sessions are with the default php session handler using cookies following the http protocol. But still sessions and cookies are a safe way for user logins.

 

If you use a challenge/response system (with a non-javascript fallback system) you can safely (enough...) login. If you store the session id in a session and user specific information in a database session table (e.g. id, session, user id, last visit and ip) it's a really stable system.

 

I you sent critical data (credit card numbers, username/password for critical systems) it's better to use https, but it cost more (development, certificates etc) to use it.

Yes it is.

 

The only alternative I can think of are cookies, but they store information on a user's computer - a great security risk.

 

Overall, sessions are the best way to go. However, if you are transferring social security numbers or credit card digits - make sure you get a SSL (HTTPS) connection/certificate.

 

You do realize that sessions, by default, use cookies, right?

 

Sessions and Cookies are two separate measures of transferring user data from one page to another. It is true that the two have some overlap at some points, but when they do, they render the other as useless. When you start a session, the server temporarily saves a session log of your stay. This contains all session information, as well as the id of the user. The user on the other hand, is given a small piece of code, an id of his session. Sometimes this is incorrectly assumed as a cookie  (as Nightslyr  does), but in no way is an actual cookie. Its more of a placeholder that tracks the user's id of his session so the server <--> browser can communicate.

 

Therefore, your statement is incorrect, because this "placeholder" is not a cookie, but an identification card.

Thanks for all the input.  For what I am using right now is user logins and members only pages.  The only thing I was worried about is storing personal information about the users.  The HTTPS is a good suggestion when I upgrade to collecting data such as credit card numbers. 

 

This all helps a lot!  Thanks  :)

Therefore, your statement is incorrect, because this "placeholder" is not a cookie, but an identification card.

 

That is essentially what a cookie is. Take a look at the HTTP protocol again and try to monitor the headers sent between your browser and the server. You'll notice that when initializing a session, the server will have a Set-Cookie header which sets a cookie called PHPSESSID. On the following requests your browser will send a header called Cookie containing that (and possibly other) cookies. If cookies are not available, then it will be passed in the URL.

Sessions and Cookies are two separate measures of transferring user data from one page to another. It is true that the two have some overlap at some points, but when they do, they render the other as useless. When you start a session, the server temporarily saves a session log of your stay. This contains all session information, as well as the id of the user. The user on the other hand, is given a small piece of code, an id of his session. Sometimes this is incorrectly assumed as a cookie  (as Nightslyr  does), but in no way is an actual cookie. Its more of a placeholder that tracks the user's id of his session so the server <--> browser can communicate.

 

Therefore, your statement is incorrect, because this "placeholder" is not a cookie, but an identification card.

 

Please.  ::)

 

1) A has been noted (twice) PHP's session management system uses cookies by default. The cookie contains a session ID.

2) Sessions are not a measure "of transferring user data from one page to another".

 

A "session" simply refers to period of time in which a state between parties is maintained. In web applications, these parties are a client and server.

 

A 'session' even in the specific context of a PHP application, is not a method of transferring data. Hence the PHP session management extension has to rely on URI arguments or cookies to transfer the session ID.

 

I cannot believe how many times I have had this discussion. Sessions in PHP are not magic.

 

More specific to the OP, sessions in web applications are far from inherently secure. Sure, since the actual data never leaves the server, you can be certain that, in contrary to using cookies, what's in there was put there by the server.

 

The Achilles heel of using a traditional session management system is the session ID. Risks can mostly be categorized in 'Session Hijacking' and 'Session Fixation'.

 

Some quick advice that goes a long way towards making your session more secure: use session_regenerate_id() whenever the client is about to do something of interest. Pseudo-officially, the credo is to regenerate the ID whenever 'the users access level changes'. A login most certainly qualifies.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.