Password Security

[Chris Kelleher]

I'm wondering how other people are handling password-type security for their
internet apps. Are you passing in the password as an url parameter or
setting a cookie? If it's a url parameter, it shows up in the browser
history which then could be run by anyone using the link in the browser
history. If it's a cookie, I know setting the date/time parameter of ?,?
will cause the cookie to be stale when the browser is closed. But if a
person simply shuts off their computer, how does this affect the cookie?
Could someone log back on and then use the history and the cookie to get
back in to the application?

As well, since all web objects are on the propath how do you prevent people
from typing in any object without first going through your logon routine?

Thanks

-Todd

 

[Chris Kelleher]

Todd Cocks wrote:
>
> I'm wondering how other people are handling password-type security for their
> internet apps. Are you passing in the password as an url parameter or
> setting a cookie? If it's a url parameter, it shows up in the browser


It should be neither. When you enter your username/password,
you should "post" the HTML Form. This will NOT pass the values
along the query string. Instead, the HTML fields will be encoded
by the browser and sent as environment variables to the webserver
within the HTTP conversation.

Once your logic is able to determine which user is attempting
access, a unique, encrypted value should be passed from page to
page to identify that user (don't pass username/password values).


> history which then could be run by anyone using the link in the browser
> history. If it's a cookie, I know setting the date/time parameter of ?,?
> will cause the cookie to be stale when the browser is closed. But if a
> person simply shuts off their computer, how does this affect the cookie?


Regardless of the expiration date of the cookie, if the
browser is abnormally terminated (i.e. the user shuts off
the computer or the browser simply crashes), cookies for
any open sessions will not be written to disk. I've done
testing. This seems to be true with NS4 and IE4. I don't
know about other browsers and/or versions.


> Could someone log back on and then use the history and the cookie to get
> back in to the application?
>


Probably. It depends how you handled this within your
coding logic. If you're simply relying on a cookie
to exist, it sounds like you're not doing much defensive
programming to handle this.


> As well, since all web objects are on the propath how do you prevent people
> from typing in any object without first going through your logon routine?
>


If your app relies on a certain path to be taken,
then you'll have to handle that programmatically
too.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R o b e r t J. M i r r o
rmirro@microserve.net http://www.microserve.net/~rmirro/

I can't sleep beneath the trees of wisdom
When your ax has cut the roots that feed them
Forked tongues in bitter mouths
Can drive a man to bleed from inside out
- Creed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Chris Kelleher]

We usually use a cookie that lasts as long as the browser is available. The
contents of the cookie is a random string that is stored in a table in the
database to id the user. We dont use rowid's or the like cuz one can still
change a cookie within a javascript function in a web page loaded from disk
(with some browsers). Anyhow, it is a bit harder to guess at someone elses 30
character random string than to merely increment a rowid by one and wha-la -
your someone else.

Once the computer is turned off, the browser is shutoff too, and so the cookie
is gone - did I understand you correctly?

The URL problem is a bit more complex.

Some URLs we email out to people - such as a status screen based on an
escalation process or the like. These of course we want people to reach
directly if they are already logged in. Sometimes one may want non-logged in
people to see the URL.

That said, the method I have come up with is giving each screen a name (usually
the file name, but one could use a number or the like) and hitting against a
database in the output-headers section to determine if the user has access to
the URL.

You will probably find that you can group URLs together into some forms of
functionallity, and will want to give the user access to that functionallity.
Then there will be suites of programs -- etc. It will be a bit recursive.

There is more information available at www.sauge.com/progress under the tips and
tricks. It doesnt have code per se, but it does have some ideas on things.

I am thinking of releasing the code as an SDK or the like for purchase. Don't
know yet.


--
Scott Auge http://www.resourcestop.com http://www.sauge.com

 

[Chris Kelleher]

You'll probably get several different ways to handle this, here's one.

Submit the form that the password field is in to your validation program, that
way it does not show up in the cookies or URL.

If the user passes validation, create a unique session ID and set it in a
session cookie (no expiration).

Either create a session record in your database or set the session ID in the
users db record along with a time stamp.

At the top of each WS page on your site check for the session ID cookie, if it
doesn't exist the user did not log in properly, send them to the login page. If
the cookie exists, find the session record or the user record with the
appropriate session ID and optionally check the time stamp.

If you can't find the matching session record or field, or if the time stamp
shows that the session ID is stale (according to whatever parameters you decide
on), expire the session ID cookie and send them to the login page.

__________________________________
Tony Auerbach
Application Solutions Specialist
SCS
(972) 550-7666 Ext. 2132
auerbaa@ccgate.dl.nec.com http://www.scsglobal.com