> 1. script for login process is located on a SSL-enabled server, so
> usernames and p***words are encrypted.
https:// is an envelope encryption, so POST data, which is a part of the
packet data, not packet headers, is encrypted. As long as you POST or COOKIE
data that needs encryption, you're fine. GET is not secure.

> 2. upon successful login, user is relocated to a non-SSL-enabled server
> which hosts the scripts that contain the authenticated-user-only features.
If this is what you're doing (header() or a meta-refresh html tag).

> So, while usernames and p***words are protected by SSL, the PHPSESSID is
> not. In other words, anyone who captures that HTTP GET packet can get
> the session ID. Is that true?
There are a few different attack vectors with SESSION data. Needless to say,
never store or authenticate by a PHP SESSION id only; use cookies or encrypt
a page with script and include() the content per page, and force users to
login every page change.

> Another question is while that session ID is valid only before an
> unset() and a session_destroy(). So the attacker who has the session ID
> must fake the session before the real user logout. Is that true?
Before the session is destroyed and the temp file where it is stored is
deleted from the harddrive. Do not store sensitive information or use a
SESSION id to authenticate a user.


--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

Jared Farrish wrote:
>> 1. script for login process is located on a SSL-enabled server, so
>> usernames and p***words are encrypted.
> https:// is an envelope encryption, so POST data, which is a part of the
> packet data, not packet headers, is encrypted. As long as you POST or
> COOKIE
> data that needs encryption, you're fine. GET is not secure.

What utter crud. An SSL connection encrypts the whole HTTP conversation,
including headers and even the URL you are requesting. The response is
also encrypted. It doesn't matter whether you're doing a POST or a GET
request, it's all encrypted.

>> 2. upon successful login, user is relocated to a non-SSL-enabled server
>> which hosts the scripts that contain the authenticated-user-only
>> features.
> If this is what you're doing (header() or a meta-refresh html tag).
>
>> So, while usernames and p***words are protected by SSL, the PHPSESSID is
>> not. In other words, anyone who captures that HTTP GET packet can get
>> the session ID. Is that true?
> There are a few different attack vectors with SESSION data. Needless to
> say,
> never store or authenticate by a PHP SESSION id only; use cookies or
> encrypt
> a page with script and include() the content per page, and force users to
> login every page change.

Cookies are no more secure than the session ID. The general conclusion
from many years of discussion in the web community is that the user
experience is diminished so much by not trusting a session ID that the
security improvements are not justified.

If you're really concerned then your best bet is to reduce the session
lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
store the user agent in the session and expire it if a request tries to
use an existing session with a different user agent. Unfortunately you
cannot rely on the IP address remaining the same throughout a session,
so don't build that into your session validation.

>> Another question is while that session ID is valid only before an
>> unset() and a session_destroy(). So the attacker who has the session ID
>> must fake the session before the real user logout. Is that true?
> Before the session is destroyed and the temp file where it is stored is
> deleted from the harddrive. Do not store sensitive information or use a
> SESSION id to authenticate a user.

The session ID should be used for exactly what it says on the tin -
identifying a session. PHP takes care of this for you by looking at the
sessions it is maintaining for one matching the ID it's given. You can
and should authenticate the continuation of a session based on the
session ID (otherwise there's not much point having the session because
the user will need to login for each page request), but you should not
be storing the session ID anywhere because it's not a permanent value.

To invalidate a session ID you just need to call session_destroy. There
are people who do the following just to be sure that the data in a
session is destroyed, but AFAIK it's not necessary...

foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);

-Stut

2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt ÃÂ*rta:
> Jared Farrish wrote:
> >> 1. script for login process is located on a SSL-enabled server, so
> >> usernames and p***words are encrypted.
> > https:// is an envelope encryption, so POST data, which is a part of the
> > packet data, not packet headers, is encrypted. As long as you POST or
> > COOKIE
> > data that needs encryption, you're fine. GET is not secure.
>
> What utter crud. An SSL connection encrypts the whole HTTP conversation,
> including headers and even the URL you are requesting. The response is
> also encrypted. It doesn't matter whether you're doing a POST or a GET
> request, it's all encrypted.
>
> >> 2. upon successful login, user is relocated to a non-SSL-enabled server
> >> which hosts the scripts that contain the authenticated-user-only
> >> features.
> > If this is what you're doing (header() or a meta-refresh html tag).
> >
> >> So, while usernames and p***words are protected by SSL, the PHPSESSID is
> >> not. In other words, anyone who captures that HTTP GET packet can get
> >> the session ID. Is that true?
> > There are a few different attack vectors with SESSION data. Needless to
> > say,
> > never store or authenticate by a PHP SESSION id only; use cookies or
> > encrypt
> > a page with script and include() the content per page, and force users to
> > login every page change.
>
> Cookies are no more secure than the session ID. The general conclusion
> from many years of discussion in the web community is that the user
> experience is diminished so much by not trusting a session ID that the
> security improvements are not justified.
>
> If you're really concerned then your best bet is to reduce the session
> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
> store the user agent in the session and expire it if a request tries to
> use an existing session with a different user agent. Unfortunately you
> cannot rely on the IP address remaining the same throughout a session,
> so don't build that into your session validation.
>
> >> Another question is while that session ID is valid only before an
> >> unset() and a session_destroy(). So the attacker who has the session ID
> >> must fake the session before the real user logout. Is that true?
> > Before the session is destroyed and the temp file where it is stored is
> > deleted from the harddrive. Do not store sensitive information or use a
> > SESSION id to authenticate a user.
>
> The session ID should be used for exactly what it says on the tin -
> identifying a session. PHP takes care of this for you by looking at the
> sessions it is maintaining for one matching the ID it's given. You can
> and should authenticate the continuation of a session based on the
> session ID (otherwise there's not much point having the session because
> the user will need to login for each page request), but you should not
> be storing the session ID anywhere because it's not a permanent value.
>
> To invalidate a session ID you just need to call session_destroy. There
> are people who do the following just to be sure that the data in a
> session is destroyed, but AFAIK it's not necessary...
>
> foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);

or just simply
$_SESSION = array();

greets
Zoltán Németh

>
> -Stut
>

Zoltán Németh wrote:
> 2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt ÃÂ*rta:
>> Jared Farrish wrote:
>>>> 1. script for login process is located on a SSL-enabled server, so
>>>> usernames and p***words are encrypted.
>>> https:// is an envelope encryption, so POST data, which is a part of the
>>> packet data, not packet headers, is encrypted. As long as you POST or
>>> COOKIE
>>> data that needs encryption, you're fine. GET is not secure.
>> What utter crud. An SSL connection encrypts the whole HTTP conversation,
>> including headers and even the URL you are requesting. The response is
>> also encrypted. It doesn't matter whether you're doing a POST or a GET
>> request, it's all encrypted.
>>
>>>> 2. upon successful login, user is relocated to a non-SSL-enabled server
>>>> which hosts the scripts that contain the authenticated-user-only
>>>> features.
>>> If this is what you're doing (header() or a meta-refresh html tag).
>>>
>>>> So, while usernames and p***words are protected by SSL, the PHPSESSID is
>>>> not. In other words, anyone who captures that HTTP GET packet can get
>>>> the session ID. Is that true?
>>> There are a few different attack vectors with SESSION data. Needless to
>>> say,
>>> never store or authenticate by a PHP SESSION id only; use cookies or
>>> encrypt
>>> a page with script and include() the content per page, and force users to
>>> login every page change.
>> Cookies are no more secure than the session ID. The general conclusion
>> from many years of discussion in the web community is that the user
>> experience is diminished so much by not trusting a session ID that the
>> security improvements are not justified.
>>
>> If you're really concerned then your best bet is to reduce the session
>> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
>> store the user agent in the session and expire it if a request tries to
>> use an existing session with a different user agent. Unfortunately you
>> cannot rely on the IP address remaining the same throughout a session,
>> so don't build that into your session validation.
>>
>>>> Another question is while that session ID is valid only before an
>>>> unset() and a session_destroy(). So the attacker who has the session ID
>>>> must fake the session before the real user logout. Is that true?
>>> Before the session is destroyed and the temp file where it is stored is
>>> deleted from the harddrive. Do not store sensitive information or use a
>>> SESSION id to authenticate a user.
>> The session ID should be used for exactly what it says on the tin -
>> identifying a session. PHP takes care of this for you by looking at the
>> sessions it is maintaining for one matching the ID it's given. You can
>> and should authenticate the continuation of a session based on the
>> session ID (otherwise there's not much point having the session because
>> the user will need to login for each page request), but you should not
>> be storing the session ID anywhere because it's not a permanent value.
>>
>> To invalidate a session ID you just need to call session_destroy. There
>> are people who do the following just to be sure that the data in a
>> session is destroyed, but AFAIK it's not necessary...
>>
>> foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);
>
> or just simply
> $_SESSION = array();

I consider this is very bad practice, but I've just checked the manual
page for session_destory and it recommends the following to completely
destroy a session...

<?php
// Initialize the session.
// If you are using session_name("something"), don't forget it now!
session_start();

// Unset all of the session variables.
$_SESSION = array();

// If it's desired to kill the session, also delete the session cookie.
// Note: This will destroy the session, and not just the session data!
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}

// Finally, destroy the session.
session_destroy();
?>

-Stut

On 5/29/07, Stut <EMAIL REMOVED> wrote:
>
> What utter crud. An SSL connection encrypts the whole HTTP conversation,
> including headers and even the URL you are requesting. The response is
> also encrypted. It doesn't matter whether you're doing a POST or a GET
> request, it's all encrypted.


The URL string is encrypted in HTTPS? Well, I was certainly under a
different impression (same with headers). Since I can't say I know any
better beyond a shadow of a doubt, I'll take your word for it. : )

Cookies are no more secure than the session ID. The general conclusion
> from many years of discussion in the web community is that the user
> experience is diminished so much by not trusting a session ID that the
> security improvements are not justified.


So by storing sensitive information in a SESSION, you're safer? Only if the
session doesn't get read... I don't know, I guess in the security sense, it
should be seen as a part of the "conversation" as you put it, so if you
can't trust SESSION, you probably shouldn't use it at all for secure
applications. I still don't see the sense in storing sensitive information
in a session, at least one that persists; if it is p***ed to a temp table in
a database and destroyed across calls, I can see that as a better solution,
as long as you have a strong database security configuration.

If you're really concerned then your best bet is to reduce the session
> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
> store the user agent in the session and expire it if a request tries to
> use an existing session with a different user agent. Unfortunately you
> cannot rely on the IP address remaining the same throughout a session,
> so don't build that into your session validation.


Well, if you use COOKIES, you can p*** a secondary hash key that can be used
to validate the actual key against a footprint for a visitor (from
$_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like
that's a pretty good way to check against a visitor. I just think it feels
flimsy to validate a user on a SESSION key only.

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$


--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

On 5/29/07, Stut <EMAIL REMOVED> wrote:
>
> Don't get me wrong, I don't want to discourage anyone from thinking
> about ways to improve it, but personally I consider this issue done to
> death.
>

Well, I think the difference is that you send one key (a session identifier)
and hash on user agent report, while I send an authentication key and a
secondary hash key stored in cookies. I'm sending only nominally more
information than you are, so I don't think there's THAT much difference
between what we're saying here. As a lot of users would store session id's
as cookies, and fall back to a query string id, like I said, I don't see
much of a difference in our approaches, except you don't seem to think mine
is acceptable since it's not a "session" id.

If you supply the salt (instead of relying on it being provided, vis a vis,
user agent report), and store that in a cookie on the client, and then that
client can't reproduce an accurate, unchanged version of that cookie, what
change in either the salt and/or the auth id would make this approach
unacceptable (and not break the authentication)? I see major web firms use
cookies all the time, so I'm not sure why there is a bias against cookies,
besides a user that doesn't support cookies in the first place (which is a
real concern, I admit).

I remember a poster on a wall of a tech dept my friend worked for that had a
faux-advert for a "security dongle" for a computer. Essentially, it was a
rubber stopper that was put on a power cable that provided a "100% secure
air gap."

Whether it's been settled or not, I'm not nearly as played out on discussing
it (especially if I'm not getting aspects correct) as I am about browser
bickering, OS wars, and all the other "disp***ionate" discourse currently
"enlightening" the internet. At least with security, there's some known
benefit to discussing it!
--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$


--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

Jared Farrish wrote:
> On 5/29/07, Stut <EMAIL REMOVED> wrote:
>>
>> Don't get me wrong, I don't want to discourage anyone from thinking
>> about ways to improve it, but personally I consider this issue done to
>> death.
>
> Well, I think the difference is that you send one key (a session
> identifier)
> and hash on user agent report, while I send an authentication key and a
> secondary hash key stored in cookies. I'm sending only nominally more
> information than you are, so I don't think there's THAT much difference
> between what we're saying here. As a lot of users would store session id's
> as cookies, and fall back to a query string id, like I said, I don't see
> much of a difference in our approaches, except you don't seem to think mine
> is acceptable since it's not a "session" id.

That's not what I'm saying. My basic question is why send the "secondary
hash key" to the client when it doesn't need it? Use the authentication
key to identify the users data, then get the "secondary hash key" from
that data. The browser never needs to see the hash, and from a purist
security point of view it could potentially reveal more about your
security methods than you need to.

> If you supply the salt (instead of relying on it being provided, vis a vis,
> user agent report), and store that in a cookie on the client, and then that
> client can't reproduce an accurate, unchanged version of that cookie, what
> change in either the salt and/or the auth id would make this approach
> unacceptable (and not break the authentication)? I see major web firms use

But the point here is that both pieces of information required to
authenticate that client are stored on the client. If someone can get
one of them they can get the other, so it's no more secure than just
accepting the one cookie without bothering to authenticate it in any way.

> cookies all the time, so I'm not sure why there is a bias against cookies,
> besides a user that doesn't support cookies in the first place (which is a
> real concern, I admit).

I have nothing against cookies at all, but I think the line between
cookies and session data is pretty clear.

Cookies should be used to...

a) remember a user between sessions (but not authenticate them)
b) remember a session ID during a session
c) remember user preferences for anonymous users, or where there is no
such concept as users on the site

Sessions should be used for everything else. If you're finding that
you're storing huge amounts of data in cookies, switch to using
sessions. If you find that you're storing so-called "sensitive"
information in cookies, switch to sessions.

> I remember a poster on a wall of a tech dept my friend worked for that
> had a
> faux-advert for a "security dongle" for a computer. Essentially, it was a
> rubber stopper that was put on a power cable that provided a "100% secure
> air gap."
>
> Whether it's been settled or not, I'm not nearly as played out on
> discussing
> it (especially if I'm not getting aspects correct) as I am about browser
> bickering, OS wars, and all the other "disp***ionate" discourse currently
> "enlightening" the internet. At least with security, there's some known
> benefit to discussing it!

I'm more than happy to discuss it, but please tell me you got the point
about whatever extra security is possible is likely to have been added
by the majority of web application platforms, including PHP.

I'm all for talking about it and seeing if there is a better way, but I
also know that people far smarter than me have been talking about it for
over 20 years, and what we have is what they've come up with. Ignoring
the other possibilities like client certificates there's not really
anything more you can do without introducing the possibility or even
likelihood that the user experience will be shafted.

-Stut

> That's not what I'm saying. My basic question is why send the "secondary
> hash key" to the client when it doesn't need it? Use the authentication
> key to identify the users data, then get the "secondary hash key" from
> that data. The browser never needs to see the hash, and from a purist
> security point of view it could potentially reveal more about your
> security methods than you need to.

The idea is that the secondary hash key replaces the user agent sniff.

> But the point here is that both pieces of information required to
> authenticate that client are stored on the client. If someone can get
> one of them they can get the other, so it's no more secure than just
> accepting the one cookie without bothering to authenticate it in any way.

The token isn't any more secure than tokenizing a user agent and salting it
into a digest. The client still knows what their user agent string says, and
this string can also be guessed (how random can they be?), but at least you
can manipulate a secondary hash key per day/hour, week, whatever.

> I have nothing against cookies at all, but I think the line between
> cookies and session data is pretty clear.

I would just ask where? (No, really.) If it was clear, then a link to a
tutorial on PHP session security is helpful.

> Cookies should be used to...
>
> a) remember a user between sessions (but not authenticate them)
> b) remember a session ID during a session
> c) remember user preferences for anonymous users, or where there is no
> such concept as users on the site

I agree 100% on everything except the logic on authentication. How would you
finish the following:

Sessions should be use to...

a) ?
b) ?
c) ?

> Sessions should be used for everything else. If you're finding that
> you're storing huge amounts of data in cookies, switch to using
> sessions. If you find that you're storing so-called "sensitive"
> information in cookies, switch to sessions.

I don't store anything in cookies that are meant to be useful on the
server-side, save an auth string and a corresponding generated salt. This
will probably change on my next big project, but for the moment, I'm not
much of a fan of SESSIONS that persist. This is based on limited experience
and anecdotal evidence, so opinions may very.

> I'm more than happy to discuss it, but please tell me you got the point
> about whatever extra security is possible is likely to have been added
> by the majority of web application platforms, including PHP.

Of course. We're talking methodology (implementation of what is available),
so I'm not sure why you feel the above is necessary.

> I'm all for talking about it and seeing if there is a better way, but I
> also know that people far smarter than me have been talking about it for
> over 20 years, and what we have is what they've come up with. Ignoring
> the other possibilities like client certificates there's not really
> anything more you can do without introducing the possibility or even
> likelihood that the user experience will be shafted.

If it's an accepted methodology, please describe the entire methodology. If
you think it's obvious, it should be easy, and a link is beneficial.

I do think the stated best practice of SESSIONS, at this point, probably
does need to be described to be further useful as a topic of discussion.
I've been a little unclear in some things, so I get the feeling we've got
the same point of view, with one slight deviation (I think it's slight...).

On 5/29/07, Jared Farrish <EMAIL REMOVED> wrote:

> I do think the stated best practice of SESSIONS, at this point, probably
> does need to be described to be further useful as a topic of discussion.
> I've been a little unclear in some things, so I get the feeling we've got
> the same point of view, with one slight deviation (I think it's slight...).
>

Just thought I'd post this:

Primer on PHP session security:
http://www.php-mag.net/itr/online_ar...odeid,114.html

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

Jared Farrish wrote:
>> That's not what I'm saying. My basic question is why send the "secondary
>> hash key" to the client when it doesn't need it? Use the authentication
>> key to identify the users data, then get the "secondary hash key" from
>> that data. The browser never needs to see the hash, and from a purist
>> security point of view it could potentially reveal more about your
>> security methods than you need to.
>
> The idea is that the secondary hash key replaces the user agent sniff.

But by doing that you're exposing how your app validates the
authentication key, leaving it open to being transferred to another machine.

>> But the point here is that both pieces of information required to
>> authenticate that client are stored on the client. If someone can get
>> one of them they can get the other, so it's no more secure than just
>> accepting the one cookie without bothering to authenticate it in any way.
>
> The token isn't any more secure than tokenizing a user agent and salting it
> into a digest. The client still knows what their user agent string says,
> and
> this string can also be guessed (how random can they be?), but at least you
> can manipulate a secondary hash key per day/hour, week, whatever.

It's actually less secure than using the user agent because someone
looking at the cookies on the client gets no indication that you're
using the user agent to verify that it's the same client making the request.

>> I have nothing against cookies at all, but I think the line between
>> cookies and session data is pretty clear.
>
> I would just ask where? (No, really.) If it was clear, then a link to a
> tutorial on PHP session security is helpful.

I've asked the internals list why PHP doesn't natively validate the
session ID by using the user agent or other variables because I actually
don't know the reasoning behind it. I'll let you know what they say.

>> Cookies should be used to...
>>
>> a) remember a user between sessions (but not authenticate them)
>> b) remember a session ID during a session
>> c) remember user preferences for anonymous users, or where there is no
>> such concept as users on the site
>
> I agree 100% on everything except the logic on authentication. How would
> you
> finish the following:
>
> Sessions should be use to...
>
> a) ?
> b) ?
> c) ?

a) Store data between requests
b) There is no B

That's the definition of a session. It's a server-side store of data
related to a single user of a web application.

>> Sessions should be used for everything else. If you're finding that
>> you're storing huge amounts of data in cookies, switch to using
>> sessions. If you find that you're storing so-called "sensitive"
>> information in cookies, switch to sessions.
>
> I don't store anything in cookies that are meant to be useful on the
> server-side, save an auth string and a corresponding generated salt. This
> will probably change on my next big project, but for the moment, I'm not
> much of a fan of SESSIONS that persist. This is based on limited experience
> and anecdotal evidence, so opinions may very.

By "sessions that persist" do you mean sessions that live on between
visits by a user? If so then that's a totally different kettle of fish
and IMHO should be avoided at all costs.

>> I'm more than happy to discuss it, but please tell me you got the point
>> about whatever extra security is possible is likely to have been added
>> by the majority of web application platforms, including PHP.
>
> Of course. We're talking methodology (implementation of what is available),
> so I'm not sure why you feel the above is necessary.

Look at the session facilities provided by any web development platform.
They all work the same was as PHP sessions, that is to say storing a
session ID in a cookie or p***ing it in URLs. I'm not aware of any
system that uses extra validation, and the reason for that is that there
is no guaranteed method.

But you're right, the everybody-else-does-it-that-way argument is never
very strong, but I think it's worth noting. As mentioned earlier, I have
asked the internals list to give a reason why the session extension does
no additional validation.

>> I'm all for talking about it and seeing if there is a better way, but I
>> also know that people far smarter than me have been talking about it for
>> over 20 years, and what we have is what they've come up with. Ignoring
>> the other possibilities like client certificates there's not really
>> anything more you can do without introducing the possibility or even
>> likelihood that the user experience will be shafted.
>
> If it's an accepted methodology, please describe the entire methodology. If
> you think it's obvious, it should be easy, and a link is beneficial.

20 years was an exaggeration given the age of the web, but the need to
persist data related to any given user of a website between requests has
been an issue for well over 10 years.

The first "solution" was cookies. The problem with cookies is that
they're very inefficient and insecure. Inefficient because they get
transferred with every request, and insecure because they get
transferred in the HTTP headers and get stored on the client over which
the web developer has no control.

The natural progression of this was to store the minimum required in a
cookie, and tie that cookie value to a chunk of data on the server. This
is what we now understand as a session.

Client certificates were created to allow a client to prove its identity
to a server in the same way that an SSL certificate can prove the
identity of a server. Unfortunately the management of client
certificates makes them uneconomical for most applications. I know of a
few banks that use them, but not many at all. In fact, the only place
I've used them lately was in a forex trading system where each terminal
cost over $12k which included the hardware and the software license. In
effect the client was as much in our control as the servers were.

Anyhoo, I digress. Sessions are the answer to storing data related to a
users visit to a website / web application between page requests in an
efficient and relatively secure manner. Through the use of SSL you can
add to the security my making it very very hard (but not impossible) to
read the session ID at any point during its transmission. However, you
are still left wide open at the client end, and this I think is where we
differ.

> I do think the stated best practice of SESSIONS, at this point,
> probably does need to be described to be further useful as a topic of
> discussion. I've been a little unclear in some things, so I get the
> feeling we've got the same point of view, with one slight deviation (I
> think it's slight...).

You want to store 2 pieces of information in the browser which, when put
together, will allow a user to continue their visit in an authenticated
state.

I want to put 1 piece of information in the browser, and store the other
in the session. The bit stored in the browser will identify a particular
session on the server from which I will get the second bit.

It doesn't really matter whether that second bit comes from the user
agent, or is randomly generated on login. Storing the validation key in
the same place as the key is like writing your PIN code on the back of
your credit card.

Do you now see why my way is more secure than yours?

-Stut