Posted by Richard Lynch on 04/12/05 00:53

On Mon, April 11, 2005 9:13 am, Chris Boget said:
>> Please refrain from such speculation, because it does nothing to improve
>> the state of security within our community. This idea of storing
>> passwords in cookies is absurd.
>
> Is the above sentiment true even if you store the password as some sort
> of hash (md5 or otherwise)?

YES!

If you have to maintain a "login" over time, your first pass should be to
use the built-in session handling functions.
http://php.net/session_start

Those have been proofed by professionals, and are subject to massive peer
review that you can't hope to duplicate.

Simply tie the session_id() to the user's record TEMPORARILY, and remove
the association after X minutes of inactivity.

In addition, if the content or identity of your user is worth *ANYTHING*
at all to you, if you care at *ALL* about any kind of security or privacy,
you should add additional controls.

#1.
Set the time-out on PHP's session to the shortest value you can live with,
and not have your visitors/boss angry.

This is a no-brainer and easy to implement. You have no excuse for NOT
doing this.

This time-out should be somewhat longer than X (above) but still as short
as you can make it.

#2.
Add an ever-changing random token to their Cookie data on each HTTP exchange.

If they don't send back the right token from their previous "click",
challenge them to identify themselves with a password, then take them on
to what they asked for.

This takes a little bit of work, and you have to be careful that not even
the sharpest Bad Guys can predict your token, not even if they already
have the previous token[s].

It also makes their "Back" button not work, which is a bit of a pain, but
less so if you warn them from the login page it won't work. Also be sure
to include that same warning in the fine print at top/bottom of all
protected pages.

If your challenge for a password succeeds, they should end up exactly
where they wanted to be when they "clicked" on your site. This is
minimally intrusive to legitimate users.

A really sharp Bad Guy can still stage a man-in-the-middle attack and pass
data back-and-forth, merely observing the interchange, or subtly changing
only content that will go un-noticed (they hope) while preserving the
tokens and not completely hijacking the session. *BUT* that requires
*WAY* more skill/time/resources than "average" Bad Guy.

#3
Minimize the number of pages that are password-protected.

Or, rather, SEPARATE the content that matters from the "open to all"

There is NO POINT to protecting your "about" page or your "FAQ" page etc.

By focussing your efforts on the data that matters, you have a lot less
scope to worry about for buglets that leak security.

Your delineation between "public" and "private" areas should be OBVIOUS to
all users, to all programmers, to all DBAs, to *anybody* remotely
connected to the project, whether they read documentation or not. This
will minimize the odds of a Technical Blunder that exposes data.

This is easy for a NEW project if you Design it from the get-go. It can
be "challenging" for an existing project, but it's worth it.

#4.
Track independent corraborating information about the user such as IP
address, browser characteristics, and even their average time between HTTP
connections.

IP addresses change, but in predictable ways for a given session.
Some browser characteristics change over time/request, some do not.
Human users have typical speeds at which they work.

So you can't use any one clear-cut setting here, but rather can produce a
percentage "indicator" that this person is still this person, for sure.

If you're not sure, challenge them for the password again, but then take
them to where they were going in the first place. This will be minimally
intrusive, but ensure that they are who they say they are.

This is the most complex to implement, and isn't that much of a barrier --
But may be worth considering.

I'm sure there are more Good Ideas out there.
http://phpsec.org
is your first resource for them.

"Security is not ON/OFF. It's a gradient." -- me :-)

--
Like Music?
http://l-i-e.com/artists.htm

[Back to original message]