[Sessions] Why are they more secure?

Hi

If I'm correct, a session is a unique ID that's generated for each new
session and saved as a cookie, as a way to identify a user, and keep
data on the server, either in RAM or in a database.

However, unless HTTPS is used the whole time, someone can see the
session ID being sent back and forth between the client and the
server, and bypass the login/password step by simply creating a cookie
with the same name and value in his browser.

Did I miss something in the way session ID's work?

Thank you.

*** Gilles Ganault escribió/wrote (Mon, 10 Mar 2008 22:31:06 +0100):
> If I'm correct, a session is a unique ID that's generated for each new
> session and saved as a cookie, as a way to identify a user, and keep
> data on the server, either in RAM or in a database.

HTTP is a staless protocol. That means that, unlike IRC or FTP, the
webserver has no means to know whether you are the same person who asked
for a another page 10 seconds ago. PHP sessions are a "trick" to identify
yourself across different HTTP request and allow the server to temporarily
store information and relate it to your browsing session.

The sesssion ID is the session identifier, not the session. And session is
not a synomim for "login". It's just a tool to pass information along the
pages your visit.


> However, unless HTTPS is used the whole time, someone can see the
> session ID being sent back and forth between the client and the
> server, and bypass the login/password step by simply creating a cookie
> with the same name and value in his browser.
>
> Did I miss something in the way session ID's work?

You are right, that's basically how PHP sessions work. Unless HTTPS is used
the whole time, a sniffer could eventually scrap your session ID... and
your home address, your cell phone number, your credit card... everything
your transmit over an non-encrypted channel is, by default, unsecure.

But I don't understand the subject of your message. Sessions are more
secure than... what?




--
-+ http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
++ Mi sitio sobre programación web: http://bits.demogracia.com
+- Mi web de humor austrohúngaro: http://www.demogracia.com
--

Gilles Ganault <nospam@nospam.com> wrote:
>
>If I'm correct, a session is a unique ID that's generated for each new
>session and saved as a cookie, as a way to identify a user, and keep
>data on the server, either in RAM or in a database.
>
>However, unless HTTPS is used the whole time, someone can see the
>session ID being sent back and forth between the client and the
>server, and bypass the login/password step by simply creating a cookie
>with the same name and value in his browser.
>
>Did I miss something in the way session ID's work?

This is why sessions expire.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

On Mon, 10 Mar 2008 23:05:41 +0100, Álvaro G. <Vicario"
<webmasterNOSPAMTHANKS@demogracia.com>> wrote:

> *** Gilles Ganault escribió/wrote (Mon, 10 Mar 2008 22:31:06 +0100): 
>
> HTTP is a staless protocol. That means that, unlike IRC or FTP, the
> webserver has no means to know whether you are the same person who asked
> for a another page 10 seconds ago. PHP sessions are a "trick" to identify
> yourself across different HTTP request and allow the server to
> temporarily
> store information and relate it to your browsing session.
>
> The sesssion ID is the session identifier, not the session. And session
> is
> not a synomim for "login". It's just a tool to pass information along the
> pages your visit.
>
> 
>
> You are right, that's basically how PHP sessions work. Unless HTTPS is
> used
> the whole time, a sniffer could eventually scrap your session ID... and
> your home address, your cell phone number, your credit card... everything
> your transmit over an non-encrypted channel is, by default, unsecure.
>
> But I don't understand the subject of your message. Sessions are more
> secure than... what?

Indeed, for any sense of security, HTTPS is a must. The reason Sessions
are mentioned as 'more secure' is that the session-id has _nothing_ to do
with the actual data, and is sufficiently long to make 'guessing' an
active sessions id not an easy/quick task. Also, the data they carry
doesn't live very long: a valid session-id now could be an invalid
session-id in half en hour. Any data belonging to it resides on the server
and can't be inspected by anything else then the server itself.

It's more secure then some newbee errors making a login system: storing
the user-id as a cookie (simply guessable), storing username & password in
a cookie even, or the most hilarious f*ck up of all: having a 'logged_in'
cookie set to 0 or 1 (believe you me, there are sites that operate in that
fashion...).

So, sessions are more secure because:
- they're (almost) not guessable (force attacks are harder).
- their value has no relation with the data they represent.
- their lifespan is limited.

To make them really secure for log-in systems, certainly not the only
reason for using sessions, as they could be employed for a lot less
'sensitive' data like just ordering preferences etc.:
- they should only be employed through the HTTPS protocol (avoid sniffing).
- trans_id should be disabled (people can accidentally log other people in
when sharing an URL with the id in the GET string, or some site links to
your page using a 'set' session-id, making it possible to 'share' sessions
and/or check wether someone has logged in through your site, stealing
their logged in state..)
- one should always provide a method of logging out, destroying the data
related to the sessions, terminating it a lot earlier then the default
garbage handler.
- a 'keep me logged in' feature should not be employed, unless the data
your trying to protect isn't worth protecting at all. People should be
able to remember passwords, or let their browser do that if they choose to.
- an application should still ask for a password when performing 'major'
operations (it's up to the developer to define 'major', I'd usually say
altering of emailaddress, username and/or password fall into that
category, the rest depends on the application)

--
Rik Wasmus

Tim Roberts wrote:
> Gilles Ganault <nospam@nospam.com> wrote: 
>
> This is why sessions expire.

Sessions tend not to expire while they are being actively used, which
makes the expiration is sessions of little value in a security context.

If I steal a session cookie from someone, in seconds I can set up a quick
script to perform a HEAD request to the server with the session cookie
every 5 minutes. That will keep the session alive for as long as I need it.

--
Toby A Inkster BSc (Hons) ARCS
[G of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 41 days, 16:35.]

The Semantic Web
http://tobyinkster.co.uk/blog/2008/03/09/sw/

On Tue, 11 Mar 2008 10:19:51 +0000, Toby A Inkster
<usenet200801@tobyinkster.co.uk> wrote:
>Sessions tend not to expire while they are being actively used, which
>makes the expiration is sessions of little value in a security context.

Thanks guys for the input. One site I know of uses sessions with
HTTPS, and takes a very long time to check that a user is still
active, so a session ID can remain accessible for a good 30mn :-/

Greetings, Gilles Ganault.
In reply to Your message dated Tuesday, March 11, 2008, 01:31:06,

> If I'm correct, a session is a unique ID that's generated for each new
> session and saved as a cookie, as a way to identify a user, and keep
> data on the server, either in RAM or in a database.

> However, unless HTTPS is used the whole time, someone can see the
> session ID being sent back and forth between the client and the
> server, and bypass the login/password step by simply creating a cookie
> with the same name and value in his browser.

> Did I miss something in the way session ID's work?

You've missed the point that every sane developer does not believe in sessio
n
ID itself, but insted he/she use the SessionID+$_SERVER['REMOTE_ADDRESS']
combination.
And whenever the second one changed, either reset session or discard cookie
sent.


--
Sincerely Yours, AnrDaemon <anrdaemon@freemail.ru>

AnrDaemon wrote:
> Greetings, Gilles Ganault.
> In reply to Your message dated Tuesday, March 11, 2008, 01:31:06,
> 
> 
> 
>
> You've missed the point that every sane developer does not believe in sess
ion
> ID itself, but insted he/she use the SessionID+$_SERVER['REMOTE_ADDRESS']
> combination.
> And whenever the second one changed, either reset session or discard cooki
e
> sent.
>
>

Wrong!  $_SERVER['REMOTE_ADDRESS'] is completely insecure.  Many
companies have proxies, and anyone going through their proxy will have
the same remote address.

Also, large companies (like AOL) have multiple proxies, and every
request may come from a different IP address.

This is not only insecure, it locks out people who should be able to
access your site.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Greetings, Jerry Stuckle.
In reply to Your message dated Monday, March 31, 2008, 21:28:52,

> AnrDaemon wrote: 

> Wrong!  $_SERVER['REMOTE_ADDRESS'] is completely insecure.  Many
> companies have proxies, and anyone going through their proxy will have
> the same remote address.

That's the matter of inner security of their networks. Not Your (as develope
r)
problem. In fact, You can't uncover the truth in such case.
If Your data so sensitive, then You must use HTTPS transport. No way.

> Also, large companies (like AOL) have multiple proxies, and every
> request may come from a different IP address.

Never saw such case and I think in real world it will not happens. Once You
start Your sesion, You're stuck to one given proxy, and until You reboot You
r
PC or in other way disconnect from network, You're working through one same
proxy.

> This is not only insecure, it locks out people who should be able to
> access your site.

As I said, I have never saw such occasion in real practice (excluding some
hacking attempts which I have uncovered yesterday by looking at the some ver
y
old logs... hehe).
If You can provide me a testcase or other real-world example, I want to see
it.


--
Sincerely Yours, AnrDaemon <anrdaemon@freemail.ru>

AnrDaemon wrote:
> Greetings, Jerry Stuckle.
> In reply to Your message dated Monday, March 31, 2008, 21:28:52,
> 
> 
>
> That's the matter of inner security of their networks. Not Your (as develo
per)
> problem. In fact, You can't uncover the truth in such case.
> If Your data so sensitive, then You must use HTTPS transport. No way.
>

Nope.  It's how life works.  I'm just pointing out the fallacies in your
"suggestion".  It doesn't work.
 
>
> Never saw such case and I think in real world it will not happens. Once Yo
u
> start Your sesion, You're stuck to one given proxy, and until You reboot Y
our
> PC or in other way disconnect from network, You're working through one sam
e
> proxy.
>

It does happen.  I can name a few - AOL, Intel, IBM, Microsoft... shall
I continue?

You really need to learn how round-robin proxies work.
 
>
> As I said, I have never saw such occasion in real practice (excluding some
> hacking attempts which I have uncovered yesterday by looking at the some v
ery
> old logs... hehe).
> If You can provide me a testcase or other real-world example, I want to se
e
> it.
>
>

I have.  Get someone on one of those round-robin proxies to hit your
website multiple times and watch the IP address.  You will see it can
change at any time.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================