security of sessions

[chris]

im just starting to learn how sessions work and how to use them

my question is if im geting a username and password from a visitor is it
secure to store that information in a session variable or is it better to
store that information in a database and retrieve it when needed or wouldnt
it make any difference??

thanks
chris

[Tony Marston]

Re: security of sessions

Usernames and passwords should really be stored in a database, with the
password encrypted. You do NOT want such information sitting around in a
file that every Tom, Dick and Harry can read.

--
Tony Marston

http://www.tonymarston.net

"chris" <someone@here.c om> wrote in message
news:41814e5b$1 @funnel.arach.n et.au...[color=blue]
> im just starting to learn how sessions work and how to use them
>
> my question is if im geting a username and password from a visitor is it
> secure to store that information in a session variable or is it better to
> store that information in a database and retrieve it when needed or
> wouldnt it make any difference??
>
> thanks
> chris
>[/color]

[chris]

Re: security of sessions

yeh thats what i thought

thanks

"Tony Marston" <tony@NOSPAM.de mon.co.uk> wrote in message
news:clrma8$jcg $1$8302bc10@new s.demon.co.uk.. .[color=blue]
> Usernames and passwords should really be stored in a database, with the
> password encrypted. You do NOT want such information sitting around in a
> file that every Tom, Dick and Harry can read.
>
> --
> Tony Marston
>
> http://www.tonymarston.net
>
>
>
> "chris" <someone@here.c om> wrote in message
> news:41814e5b$1 @funnel.arach.n et.au...[color=green]
>> im just starting to learn how sessions work and how to use them
>>
>> my question is if im geting a username and password from a visitor is it
>> secure to store that information in a session variable or is it better to
>> store that information in a database and retrieve it when needed or
>> wouldnt it make any difference??
>>
>> thanks
>> chris
>>[/color]
>
>[/color]

[Gordon Burditt]

Re: security of sessions

>Usernames and passwords should really be stored in a database, with the[color=blue]
>password encrypted. You do NOT want such information sitting around in a
>file that every Tom, Dick and Harry can read.[/color]

Yes, the data is sitting around *ON THE SERVER*. That shouldn't
be a problem if you have your own server all to yourself, where all
the Dicks that can read the data should be your employees.

Even if you are on shared web hosting, it's only a small percentage
of the world that can read those files (but that's BAD enough). If
you are on shared hosting, though, this is a BIG issue.

I don't particularly like PHP's default session handling of sticking
everything in little files. I'd rather it put this stuff in a
database. And since PHP provides for session handlers, it's not
at all hard to do just that. Arrange for the session handlers to be
set in a file included by every page (if you've got access to php.ini
or Apache config files, there may be easier ways), and you shouldn't
have to touch any of the code that actually manipulates $_SESSION.

If you are sharing a server with other customers of the web host,
you have to worry about the security of your database also. How
do you store the password so YOUR scripts can use it and some other
customer using the same server can't?

You probably shouldn't be storing passwords in session data anyway.
$_SESSION is stored on the server and can't be faked by the browser.
So once you validate the password, simply recording that he
successfully logged in the session (and when) against your user
database is enough if you trust that session hijacking is difficult
enough to not be a problem.

Gordon L. Burditt

[Michael Fesser]

Re: security of sessions

.oO(Tony Marston)
[color=blue]
>Usernames and passwords should really be stored in a database, with the
>password encrypted. You do NOT want such information sitting around in a
>file that every Tom, Dick and Harry can read.[/color]

True, but: If someone is able to read your session files then you should
also be concerned about your database security.

Micha

[Michael Vilain]

Re: security of sessions

In article <clrpfo$e4p@lib rary2.airnews.n et>,
gordonb.uhxj7@b urditt.org (Gordon Burditt) wrote:
[color=blue][color=green]
> >Usernames and passwords should really be stored in a database, with the
> >password encrypted. You do NOT want such information sitting around in a
> >file that every Tom, Dick and Harry can read.[/color]
>
> Yes, the data is sitting around *ON THE SERVER*. That shouldn't
> be a problem if you have your own server all to yourself, where all
> the Dicks that can read the data should be your employees.
>
> Even if you are on shared web hosting, it's only a small percentage
> of the world that can read those files (but that's BAD enough). If
> you are on shared hosting, though, this is a BIG issue.
>
> I don't particularly like PHP's default session handling of sticking
> everything in little files. I'd rather it put this stuff in a
> database. And since PHP provides for session handlers, it's not
> at all hard to do just that. Arrange for the session handlers to be
> set in a file included by every page (if you've got access to php.ini
> or Apache config files, there may be easier ways), and you shouldn't
> have to touch any of the code that actually manipulates $_SESSION.
>
> If you are sharing a server with other customers of the web host,
> you have to worry about the security of your database also. How
> do you store the password so YOUR scripts can use it and some other
> customer using the same server can't?
>
> You probably shouldn't be storing passwords in session data anyway.
> $_SESSION is stored on the server and can't be faked by the browser.
> So once you validate the password, simply recording that he
> successfully logged in the session (and when) against your user
> database is enough if you trust that session hijacking is difficult
> enough to not be a problem.
>
> Gordon L. Burditt[/color]

Read

http://shiflett.org/articles/security-corner-mar2004

Chris' article provides a great hack to hide database creditentials and
talks about the problems with security and shared hosting. I'd gotten
around the "server must be able to read the files" problem by coding
stuff with passwords in protected CGI scripts and using CGIwrap

http://cgiwrap.sourceforge.net/

but the URLs become really long.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

[Chung Leong]

Re: security of sessions

"Tony Marston" <tony@NOSPAM.de mon.co.uk> wrote in message
news:clrma8$jcg $1$8302bc10@new s.demon.co.uk.. .[color=blue]
> Usernames and passwords should really be stored in a database, with the
> password encrypted. You do NOT want such information sitting around in a
> file that every Tom, Dick and Harry can read.[/color]

Shared hosting is inherently insecured. Keeping the personal info in the
database doesn't buy you much, since people on the same server can not only
read your session files, they can also write to them. So an attack can gain
access to the info through the frontend by tinkering with the login/user id
inside his session file.

[Chung Leong]

Re: security of sessions

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:PKKdnXOmMZ 0lFRzcRVn-tg@comcast.com. ..[color=blue]
> "Tony Marston" <tony@NOSPAM.de mon.co.uk> wrote in message
> news:clrma8$jcg $1$8302bc10@new s.demon.co.uk.. .[color=green]
> > Usernames and passwords should really be stored in a database, with the
> > password encrypted. You do NOT want such information sitting around in a
> > file that every Tom, Dick and Harry can read.[/color]
>
> Shared hosting is inherently insecured. Keeping the personal info in the
> database doesn't buy you much, since people on the same server can not[/color]
only[color=blue]
> read your session files, they can also write to them. So an attack can[/color]
gain[color=blue]
> access to the info through the frontend by tinkering with the login/user[/color]
id[color=blue]
> inside his session file.
>[/color]

On a second thought, maybe you shouldn't keep the personal info in a session
precisely because others can write the session files. You wouldn't keep it
there, after all, if you're not going to use it. Say you have something like

echo "<h1>Welcom e {$_SESSION['username']}</h1>";

If someone can go in there and modify the session, he can inject arbituary
contents into the page that the user sees. As there's no limit to how long a
session string can be, the attacker could stuff an entire HTML page in
there--a fake login page that steals the user's password for example.

[Gordon Burditt]

Re: security of sessions

>> >Usernames and passwords should really be stored in a database, with the[color=blue][color=green][color=darkred]
>> >password encrypted. You do NOT want such information sitting around in a
>> >file that every Tom, Dick and Harry can read.[/color]
>>
>> Yes, the data is sitting around *ON THE SERVER*. That shouldn't
>> be a problem if you have your own server all to yourself, where all
>> the Dicks that can read the data should be your employees.
>>
>> Even if you are on shared web hosting, it's only a small percentage
>> of the world that can read those files (but that's BAD enough). If
>> you are on shared hosting, though, this is a BIG issue.
>>
>> I don't particularly like PHP's default session handling of sticking
>> everything in little files. I'd rather it put this stuff in a
>> database. And since PHP provides for session handlers, it's not
>> at all hard to do just that. Arrange for the session handlers to be
>> set in a file included by every page (if you've got access to php.ini
>> or Apache config files, there may be easier ways), and you shouldn't
>> have to touch any of the code that actually manipulates $_SESSION.
>>
>> If you are sharing a server with other customers of the web host,
>> you have to worry about the security of your database also. How
>> do you store the password so YOUR scripts can use it and some other
>> customer using the same server can't?
>>
>> You probably shouldn't be storing passwords in session data anyway.
>> $_SESSION is stored on the server and can't be faked by the browser.
>> So once you validate the password, simply recording that he
>> successfully logged in the session (and when) against your user
>> database is enough if you trust that session hijacking is difficult
>> enough to not be a problem.
>>
>> Gordon L. Burditt[/color]
>
>Read
>
>http://shiflett.org/articles/security-corner-mar2004[/color]

This is an interesting hack, but your typical shared-host webhosting
customer does not have access to their own <Virtualhost> section
in httpd.conf, nor is it likely that an ISP will let that customer
put in an Include directive which may act as a denial-of-service
attack on the server.

Bugs in provisioning code that auto-generates <VirtualHost> directives
included by an Apache config file have been known to prevent the
web server from starting, due to such mistakes (yep, mine) such as
assuming the sales staff will never enter a domain name with an
embedded single quote into the database, or that MIS would not allow
such a name to get into the database when they said this was locked
out when they were asked. Similar problems could occur with syntax
errors in SetEnv directives in an include file. For that matter,
so would deleting the file. Note: another interesting denial-of-service
attack against Apache starting up on very, very old versions was
not paying your domain name renewal to Network Solutions. If it
dropped out of DNS and appeared in certain Apache directives, the
server wouldn't start.
[color=blue]
>Chris' article provides a great hack to hide database creditentials and
>talks about the problems with security and shared hosting. I'd gotten
>around the "server must be able to read the files" problem by coding
>stuff with passwords in protected CGI scripts and using CGIwrap
>
>http://cgiwrap.sourceforge.net/
>
>but the URLs become really long.[/color]

This is interesting but I'm not sure I'd want to lose the advantages
of PHP as an Apache module. Chances are my hosting provider wouldn't
go for it either.

I keep database passwords in a PHP include file *OUTSIDE* the
document tree. This is my own server on my own property so shared
use isn't an issue. If PHP breaks (it's been known to happen briefly
while upgrading it and Apache, sometimes longer if the build didn't
work right), you can't get to the include file (although PHP files
are served as text files) and if PHP is working, the include file
is accessible but not exposed.

Gordon L. Burditt

[Shawn Wilson]

Re: security of sessions

chris wrote:[color=blue]
>
> my question is if im geting a username and password from a visitor is it
> secure to store that information in a session variable or is it better to
> store that information in a database and retrieve it when needed or wouldnt
> it make any difference??[/color]

Usually, you'd validate username and password, then store the username in a
session variable, along with a session variable indicating whether they'd been
authenticated or not. As long as the authentication variable is true, you can
assume they really are the username. It's generally considered bad practice to
keep passwords anywhere unnecessarily.

Regards,
Shawn
--
Shawn Wilson
shawn@glassgian t.com

http://www.glassgiant.com