Authentication with sessions...

[Mark H]

Hey all--

I'm building a database and I basically need to keep out people who
aren't authorized, but it's not like I need top security here. I'm just
doing basic user/pass of a SQL database, and when a user authenticates
I start a session for him.

My question is, is there any way for a hacker to easily start a session
without having logged in? For instance, if I save the user name and IP
address in the session will it be relatively tough to fake a session?

Sorry if this is a dumb question, I really don't know much about this
yet.

[Mark H]

After reading this it occurred to me that I need to clarify:

I read a few examples where the SQL database is accessed on every
protected page to re-verify the user/pass information. I was just
wondering if its safe to verify it once and then pass a flag around
that says, "yes this user has been verified."

thanks again

[DJ Craig]

IP addresses shouldnt be used for identifying people. Often multiple
people use the same IP address, or one person may change IP addresses
often. If they have an old telephone modem, they will have a different
IP everytime they connect. Those old modems often disconnect randomly.
If you use IP addresses to identify people, when that person
reconnects, your site will say they are unauthorized. Sessions alone
(without IP logging) should be sufficient. If you have a really high
number of users, or need more security, you may want to increase the
length of the session ID. I think this is done in the php.ini file
somewhere. That would make it less likely that a hacker could type in
a random session ID and get in, especially if there are a lot of users.
But this should only be necessary if there a really high number of
users or you need really high security.
And verifying them once then having a session variable flag that says
they have been verified should work fine.

[Gordon Burditt]

>I'm building a database and I basically need to keep out people who

aren't authorized, but it's not like I need top security here. I'm just
doing basic user/pass of a SQL database, and when a user authenticates
I start a session for him.
PHP typically starts a session for *ANYONE*. Sessions are also
used in user tracking with no need for logins or authentication.
If by this you mean "when a user authenticates I mark the session
as logged in", fine.
My question is, is there any way for a hacker to easily start a session
without having logged in?
PHP will typically start as session for anyone who goes to the login
page, BEFORE they log in. That session won't be marked as logged in,
though.

Is it easy to GUESS an existing session of another user? In general,
no, unless the hacker is not guessing but gets the session from the
user's computer (say, by using the user's computer to look at stored
cookies), or he uses a packet sniffer to watch the user's traffic,
or he simply uses the user's computer (while user is at lunch) to
go back to your site.
For instance, if I save the user name and IP
address in the session will it be relatively tough to fake a session?

If you check the session for being logged in on every page (e.g.
you check that $_SESSION['logged_in_user'] is set to *SOMETHING*,
which you won't do unless they logged in), and you validate that
the IP still matches, that's fairly secure, as long as you're not
protecting things like actual money, medical records, nuclear launch
codes, or SSNs. You don't need to re-check the password every time.
And if you carry the password from one page to the next in a hidden
field (so the user doesn't have to type it in on every page), that's
even LESS secure as there are more copies of it going over the net
and into the user's cache.

I recommend using a session timeout, as short as you can without
inconveniencing users, consistent with the security risk. It does
help with the "unattended computer" problem. My bank uses a timeout
of 10 minutes. "Where's George" (a site where you can track where
dollar bills in your wallet have been and where they go after you
spend them) uses 1 week by default (but who CARES if hackers or the
government can enter bills on my account or see serial numbers of
bills I've had in the past? If I was nervous about that, I wouldn't
use Where's George at all. I would prefer that nobody post death
threats on the forum in my name, but that's unlikely.)

Beware that validating the IP can cause problems: some users (AOL
users seem to be the example for this, but it's not only them) go
through load-balanced proxies, so just about every page, or piece
of a page, they come through may appear to be from a different IP.
If you reject them for that, they won't be able to use your site
usefully.

Incidentally, sometimes Apache .htaccess is a very nice fit to access
control rather than using sessions. It's nice primarily because
browsers are prepared to keep the info in memory so the user doesn't
have to enter it all the time, but it's not stored on disk. However,
..htaccess doesn't do timeouts, which is often a problem.

Gordon L. Burditt

[DJ Craig]

I hate sites with really short session timeout.

[Gordon Burditt]

>I hate sites with really short session timeout.

So what do you consider "really short"? I think 10 minutes is not
unreasonable for a BANK, where a security breach could let the
intruder empty my checking account. (Remember, the timeout gets
reset every time you load a new page.) It is, however, very
unreasonable for, say, an online newspaper, where all I can do is
read newspaper articles, and it might well take more than 10 minutes
to read and think about one article.

What do you consider reasonable? 8 hours for a forum site where a
hacker could post death threats in your name, but not spend any of
your money? How about a site where the hacker (possibly your kids
or soon-to-be-ex- wife or her boyfriend) could order football
memorabilia to be sent to *YOUR* address on your credit card, but
not get it shipped anywhere else?

Gordon L. Burditt

[Mark H]

Hey,

Thanks for the tips guys. I got my system working and sort of wrapped
my head around the idea of session-based authentication.

I decided to use IP based tracking. You and the following poster warn
against this, but those problems shouldn't apply to my application.
This application is being used on our intranet, so I'm not worried
about dial-up users or users behind a proxy. Having said that, I don't
know if it adds much -- I'm not expecting anybody to sniff SIDs on our
local network, but I guess anything is possible?

To respond to Gordon, I'm not passing plaintext passwords around, only
an MD5 hashed password. But your comment I found a little unsettling:
are you implying that session variables (besides the session id) are
transmitted over the network? I assumed that they were only resident in
the server's memory, and the SID was the only data that was carried
back and forth.

What I am *now* concerned about is this: I'm not the only user with
write access on our web server. So if my authentication simply consists
of placing an authentication flag in the session variables, somebody
could write a PHP script in another directory on the server which
starts a new session, fills out that flag, and then redirects the
browser to my supposedly "protected" page. The only thing preventing
this is not knowing the name of that flag, but if I ever released my
code to anybody else then my site would be compromised.

So right now I'm sticking with checking the database on each page. My
app doesn't have a lot of simultaneous users (not many users totally
actually, its a backend tool for the IT dept.), and the intranet web
server in general runs at no load, so this overhead isn't a problem.

Really, the application isn't even so important that I expect people to
go to these lengths to crack it. My real goal here is to learn
something, so that if on a future project I really do need to "do it
right", I'll know what that takes.

How does a timeout work? Does PHP do it automatically or do I need to
compare timestamps to decide when the timeout period has elapsed?

Thanks again for all the help

[Gordon Burditt]

>Thanks for the tips guys. I got my system working and sort of wrapped

my head around the idea of session-based authentication.

I decided to use IP based tracking. You and the following poster warn
against this, but those problems shouldn't apply to my application.
This application is being used on our intranet, so I'm not worried
about dial-up users or users behind a proxy. Having said that, I don't
know if it adds much -- I'm not expecting anybody to sniff SIDs on our
local network, but I guess anything is possible?
Sniffing SIDs is much easier on a LAN than doing it from a different
country.
To respond to Gordon, I'm not passing plaintext passwords around, only
an MD5 hashed password. But your comment I found a little unsettling:
are you implying that session variables (besides the session id) are
transmitted over the network? I assumed that they were only resident in
the server's memory, and the SID was the only data that was carried
back and forth.
One (BAD!!) alternative to depending on sessions and having the
user enter a password on each page is to hide the password in a
hidden field on the next page, so it can be used again. This
involves sending the password in plaintext TO the user, and again
when the user submits the page, which makes it a really BAD idea.

However, if someone refuses to trust the secrecy of session IDs,
and they don't want the user to enter the password every page,
they're pretty much stuck with it. But since they don't trust the
secrecy of session IDs, I guess they don't trust the secrecy of
passwords either. Now they are REALLY stuck.

This is *NOT* what session variables do, unless you also include
the values of session variables in the output. Session variables
stay on the server unless your scripts do something with them. Now,
some session variables can be safely output to the page: "You now
have 3 items in your shopping cart, which are ...". Passwords
aren't one of these.
What I am *now* concerned about is this: I'm not the only user with
write access on our web server. So if my authentication simply consists
of placing an authentication flag in the session variables, somebody
could write a PHP script in another directory on the server which
starts a new session, fills out that flag, and then redirects the
browser to my supposedly "protected" page. The only thing preventing
this is not knowing the name of that flag, but if I ever released my
code to anybody else then my site would be compromised.
Session IDs are normally stored in cookies. A cookie in the XYZ
domain shouldn't be passed to you in the DEF domain. However, you
can't count on users not manually inserting cookies into their
browsers.

You can make the name of the "authenticated" flag configurable.
That's not a very good or secure solution.

This is a problem. It is possible to write a session handler which
stores session variables in your database rather than in a common
directory of files. Now, how do you keep your DB password secret
in such an environment, such that YOUR scripts can use it, but the
other guy's scripts can't, both running on the same instance of
Apache and PHP? The DB password issue is relevant even if you
don't use sessions or don't put sessions in the DB - anyone who
can write to your DB can add themselves to the user list.

If you were concerned before, you should be really frightened now.

About the only semi-good answer I've heard for multiple potentially
mutually-hostile customers on the same box involves (a) you have
to trust the admin of the box to set this up, and (b) the admin
puts the parameters for your DB in the Apache config file inside a
<Virtualhost> directive, so each site only sees its own password,
(c) use the default setup to connect to the DB, and (d) I think
safe mode has to be on and no site is allowed to access the Apache
config file and preferably no site is allowed to open files in
another user's tree. Some of this may go out the window if any
user is allowed to write and install his own CGIs not subject
to PHP safe mode.
So right now I'm sticking with checking the database on each page. My
app doesn't have a lot of simultaneous users (not many users totally
actually, its a backend tool for the IT dept.), and the intranet web
server in general runs at no load, so this overhead isn't a problem. Really, the application isn't even so important that I expect people to
go to these lengths to crack it. My real goal here is to learn
something, so that if on a future project I really do need to "do it
right", I'll know what that takes. How does a timeout work? Does PHP do it automatically or do I need to
compare timestamps to decide when the timeout period has elapsed?

php.ini has some parameters for automatic session cleanup, primarily
for getting rid of long-abandoned sessions so your disk doesn't
fill up or the number of files in a single directory doesn't make
the system slow to a crawl. You can also put a timestamp (probably
updated on each page hit) in the session and compare yourself, if
you want to be sure of on-time expiration.

Gordon L. Burditt

[Mark Haase]

In article <11*************@corp.supernews.com>,
go***********@burditt.org (Gordon Burditt) wrote:

Session IDs are normally stored in cookies. A cookie in the XYZ
domain shouldn't be passed to you in the DEF domain. However, you
can't count on users not manually inserting cookies into their
browsers.
I didn't make it clear: other users are able to post websites on our
intranet server (in other directories, of course). Thus they would be
writing cookies on the same domain.
You can make the name of the "authenticated" flag configurable.
That's not a very good or secure solution.

This is a problem. It is possible to write a session handler which
stores session variables in your database rather than in a common
directory of files. Now, how do you keep your DB password secret
in such an environment, such that YOUR scripts can use it, but the
other guy's scripts can't, both running on the same instance of
Apache and PHP? The DB password issue is relevant even if you
don't use sessions or don't put sessions in the DB - anyone who
can write to your DB can add themselves to the user list.
Youch, sounds rough. I guess the real answer is that one must administer
one's own server if they want airtight security? Although this isn't
possible for the project I'm working on I think the level of security I
have reached already is good enough.
If you were concerned before, you should be really frightened now.

About the only semi-good answer I've heard for multiple potentially
mutually-hostile customers on the same box involves (a) you have

Hopefully nobody in our IT department will be hostile towards me!

Thanks for the advice, Gordon.

--
|\/| /| |2 |<
mehaase(at)sas(dot)upenn(dot)edu

[Jerry Stuckle]

Mark H wrote:

Hey all--

I'm building a database and I basically need to keep out people who
aren't authorized, but it's not like I need top security here. I'm just
doing basic user/pass of a SQL database, and when a user authenticates
I start a session for him.

My question is, is there any way for a hacker to easily start a session
without having logged in? For instance, if I save the user name and IP
address in the session will it be relatively tough to fake a session?

Sorry if this is a dumb question, I really don't know much about this
yet.

If you're using Apache, you could also use mod_auth_mysql (on
sourceforge) to do the authorization/authentication for you.

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

[Gordon Burditt]

>> Session IDs are normally stored in cookies. A cookie in the XYZ

domain shouldn't be passed to you in the DEF domain. However, you
can't count on users not manually inserting cookies into their
browsers.

I didn't make it clear: other users are able to post websites on our
intranet server (in other directories, of course). Thus they would be
writing cookies on the same domain.

So maybe you should get your own domain for this purpose. A subdomain
of your current domain might work (e.g. www2.mydomain.com). Since
you've only got one webserver, you're stuck with that, but Apache
does virtualhosting nicely. I don't recall the rules about passing
cookies between parent domains and subdomains.

Gordon L. Burditt