sessions and security

[dino d.]

Hi Everyone-

I was reading a few posts about sessions and security, and it seems
that the best way to address sessions security is to require
authentication every time the user needs to get to sensitive data (or
protect the session data with SSL). In other words, assume that the
world can see your session data stored in cookies if you're not using
SSL. So, I started looking for exceptions to this rule of thumb
(requiring authentication for sensitive data, even if the user has
already logged in and has session data in a cookie), and I found one
on ebay. If you log on to ebay, and then go to your personal
information, and then try to edit, say, your credit card information,
you are asked to log in. However, if you check the check box that
says "keep me logged in for 1 day unless I log out" (or whatever), you
no longer have to log in to get to your credit card information. So
obviously, they have secured the session data without SSL (or https).
How is this accomplished? Is there an equivalent construct in PHP?

Thanks,
Dino

[Jerry Stuckle]

dino d. wrote:

Hi Everyone-

I was reading a few posts about sessions and security, and it seems
that the best way to address sessions security is to require
authentication every time the user needs to get to sensitive data (or
protect the session data with SSL). In other words, assume that the
world can see your session data stored in cookies if you're not using
SSL. So, I started looking for exceptions to this rule of thumb
(requiring authentication for sensitive data, even if the user has
already logged in and has session data in a cookie), and I found one
on ebay. If you log on to ebay, and then go to your personal
information, and then try to edit, say, your credit card information,
you are asked to log in. However, if you check the check box that
says "keep me logged in for 1 day unless I log out" (or whatever), you
no longer have to log in to get to your credit card information. So
obviously, they have secured the session data without SSL (or https).
How is this accomplished? Is there an equivalent construct in PHP?

Thanks,
Dino

Dino,

You don't "protect the session with SSL". You protect data being sent
between the browser and the server with SSL.

Yes, some of this data can be the session ID (via cookie or URL), and to
be perfectly secure the session ID should be sent over a secure connection.

But obviously EBay has decided this part is not required for their needs
- which is their choice.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Umberto Salsi]

"dino d." <di*********@ya hoo.comwrote:

I was reading a few posts about sessions and security, and it seems
that the best way to address sessions security is to require
authentication every time the user needs to get to sensitive data (or
protect the session data with SSL). In other words, assume that the
world can see your session data stored in cookies if you're not using
SSL. So, I started looking for exceptions to this rule of thumb
(requiring authentication for sensitive data, even if the user has
already logged in and has session data in a cookie), and I found one
on ebay. If you log on to ebay, and then go to your personal
information, and then try to edit, say, your credit card information,
you are asked to log in. However, if you check the check box that
says "keep me logged in for 1 day unless I log out" (or whatever), you
no longer have to log in to get to your credit card information. So
obviously, they have secured the session data without SSL (or https).
How is this accomplished? Is there an equivalent construct in PHP?

This is not a feature of a specific language, but a property of
the HTTP protocol. Every cookie has several parameters you can
set, read carefully the description of the function setcookie()
www.php.net/manual/en/function.setcookie.php

Between these parameters there are expire, path, domain and secure, so
that the cookies can be sent from the client to the server only on SLL,
or only on a well defined domain/path where the secure pages are located.

About the expire time: zero means "expire when the browser closes", 24*60*60
means "expire after a day". The check box you found just tell to the server
which value it will use.

Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

[Tom]

On Mar 12, 7:46 pm, Umberto Salsi <s...@icosaedro .italiawrote:

"dino d." <dinodorr...@ya hoo.comwrote:

I was reading a few posts about sessions and security, and it seems
that the best way to address sessions security is to require
authentication every time the user needs to get to sensitive data (or
protect the session data with SSL). In other words, assume that the
world can see your session data stored in cookies if you're not using
SSL. So, I started looking for exceptions to this rule of thumb
(requiring authentication for sensitive data, even if the user has
already logged in and has session data in a cookie), and I found one
on ebay. If you log on to ebay, and then go to your personal
information, and then try to edit, say, your credit card information,
you are asked to log in. However, if you check the check box that
says "keep me logged in for 1 day unless I log out" (or whatever), you
no longer have to log in to get to your credit card information. So
obviously, they have secured the session data without SSL (or https).
How is this accomplished? Is there an equivalent construct in PHP?

This is not a feature of a specific language, but a property of
the HTTP protocol. Every cookie has several parameters you can
set, read carefully the description of the function setcookie()www.php.net/manual/en/function.setcookie.php

Between these parameters there are expire, path, domain and secure, so
that the cookies can be sent from the client to the server only on SLL,
or only on a well defined domain/path where the secure pages are located.

About the expire time: zero means "expire when the browser closes", 24*60*60
means "expire after a day". The check box you found just tell to the server
which value it will use.

Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

The eBay example you gave isn't necessarily a security flaw, because
we have no idea what other methods they use to authenticate on top of
the data stored in the cookie(s). They might be tracking your IP
address or even the port number on your machine that's accessing
eBay's server -- data which you don't store remotely. If these don't
match they might ask you to re-authenticate.

[Gordon Burditt]

>I was reading a few posts about sessions and security, and it seems

>that the best way to address sessions security is to require
authenticati on every time the user needs to get to sensitive data (or
protect the session data with SSL). In other words, assume that the

Having to put a password on every page view gets tedious, fast.

>world can see your session data stored in cookies if you're not using

Session data is not stored in cookies or anywhere on the browser.
Session identifiers are often stored in cookies. A session identifier
is sensitive while the session exists (due to possibility of sesson
hijacking) but it does not contain credit card numbers, etc. itself.
An expired session identifier is (on a properly designed site)
worthless.

>SSL. So, I started looking for exceptions to this rule of thumb
(requiring authentication for sensitive data, even if the user has
already logged in and has session data in a cookie), and I found one
on ebay. If you log on to ebay, and then go to your personal
information, and then try to edit, say, your credit card information,
you are asked to log in. However, if you check the check box that
says "keep me logged in for 1 day unless I log out" (or whatever), you
no longer have to log in to get to your credit card information. So
obviously, they have secured the session data without SSL (or https).
How is this accomplished? Is there an equivalent construct in PHP?

If you have an unexpired session, that session ID can be used to
access whatever information the site will let you do with it (for
example, order something and charge it to your saved credit card).
That's effectively what Ebay is letting you do by extending how
long your session lasts. Session expiration doesn't have to be a
fixed time.

Note: some sites have special rules for security:

1. If you change your password, you have to supply the old password
EVEN IF YOU ARE LOGGED IN. It's just too easy for someone to spot an
unattended computer, change the password, and own the account forever.
2. You cannot *EVER* look at the full credit card number being used,
(last 4 digits, maybe) although you can change it.
3. You may have to enter your password to view stored personal data,
if that's possible at all, EVEN IF YOU ARE LOGGED IN. Changing
personal data may be less sensitive than reading it.

[dino d.]

address or even the port number on your machine that's accessing
eBay's server -- data which you don't store remotely. If these don't
match they might ask you to re-authenticate.

thanks for all the replies. let me ask a specific follow up- the
sequence of events goes like this:

a) user types their username and password into a browser, and clicks
submit over an SSL connection
b) user then is brought to a non-ssl connection, where they click
something like "edit password"
c) user is brought to a "change password" page, which is an SSL
connection

it seems to me that in step b, a hacker could catch the session,
correct? so are we to assume that ebay is doing something in addition
to sessions, such as IP recording, etc.?

thanks again,
dino

[Gordon Burditt]

>a) user types their username and password into a browser, and clicks

>submit over an SSL connection

This protects the username and password. And, at this stage, the
session cookie.

>b) user then is brought to a non-ssl connection, where they click
something like "edit password"

The session cookie is exposed here, unless the cookie was a https-only
cookie. But as I recall, Ebay uses your session info for lots of
stuff (like "My Ebay") on non-secure pages, so I don't think it was
a https-only cookie.

>c) user is brought to a "change password" page, which is an SSL
connection

it seems to me that in step b, a hacker could catch the session,
correct?

Only if he is in a position to sniff your traffic, which isn't real
easy to do unless he's an employee of some company along the way:
your ISP, Ebay, a phone company, etc.

>so are we to assume that ebay is doing something in addition
to sessions, such as IP recording, etc.?

Not necessarily. They may simply *NOT CARE*. Why, for example,
do banks not require DNA tests to use a credit card? How about a
photo id? Why do they not require a PIN to use a credit card? How
about a signature even if the transaction is under $25? Because
the losses stopped don't make up for the costs and lost business
due to the hassle.

[dino d.]

address or even the port number on your machine that's accessing
eBay's server -- data which you don't store remotely. If these don't
match they might ask you to re-authenticate.

thanks for all the replies. let me ask a specific follow up- the
sequence of events goes like this:

a) user types their username and password into a browser, and clicks
submit over an SSL connection
b) user then is brought to a non-ssl connection, where they click
something like "edit password"
c) user is brought to a "change password" page, which is an SSL
connection

it seems to me that in step b, a hacker could catch the session,
correct? so are we to assume that ebay is doing something in addition
to sessions, such as IP recording, etc.?

thanks again,
dino

[Jerry Stuckle]

dino d. wrote:

>address or even the port number on your machine that's accessing
eBay's server -- data which you don't store remotely. If these don't
match they might ask you to re-authenticate.

thanks for all the replies. let me ask a specific follow up- the
sequence of events goes like this:

a) user types their username and password into a browser, and clicks
submit over an SSL connection
b) user then is brought to a non-ssl connection, where they click
something like "edit password"
c) user is brought to a "change password" page, which is an SSL
connection

it seems to me that in step b, a hacker could catch the session,
correct? so are we to assume that ebay is doing something in addition
to sessions, such as IP recording, etc.?

thanks again,
dino

Who knows? I doubt anyone on this list is familiar with EBay's code.
So why not ask them?

But this also has nothing to do with PHP. It could be any language.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[dino d.]

But this also has nothing to do with PHP. It could be any language.

>

Fair enough, thanks for all the replies. Let me just post a generic,
though I hope, still PHP-relevant conclusion. Session handlers stored
in cookies are always vulnerable to packet sniffing attacks and there
is no PHP construct to do anything about this vulnerability. In other
words, if you want to tack on additional IP tracking or something,
you're on your own. Is this a fair conclusion? Thanks again for all
the replies.

Dino