On 5/30/07, Richard Lynch <[EMAIL PROTECTED]> wrote:> If they can get the first
cookie, they can get the second just as easily.
I thought this said "just as weasily" at first, and I thought, "Ain't that
the truth..."
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the
On Tue, May 29, 2007 10:36 am, Jared Farrish wrote:
>> 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 wi
On Tue, May 29, 2007 7:42 am, Stut wrote:
> Here one final thought... if there was a reliable way to add security
> to
> sessions don't you think that one of the multitude of web development
> languages out there would have done it, including PHP?
Several reliable security additions have been disc
Jared Farrish wrote:
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.
I would think it's because browsers are flaky and you can't real
But by doing that you're exposing how your app validates the
authentication key, leaving it open to being transferred to another
machine.
True. Although I'm only exposing a part of the auth chain, not *how* that is
constructed to produce the actual authentication token.
It does not, however, ti
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
On 5/29/07, Jared Farrish <[EMAIL PROTECTED]> 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,
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 poi
Jared Farrish wrote:
On 5/29/07, Stut <[EMAIL PROTECTED]> 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
On 5/29/07, Stut <[EMAIL PROTECTED]> 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 rep
Jared Farrish wrote:
On 5/29/07, Stut <[EMAIL PROTECTED]> wrote:
The only part of an SSL connection that's not encrypted is the
handshaking that goes on to set it up in the first place. Everything
after that, the GET/POST line, headers and the body as well as the
entire response is encrypted.
On 5/29/07, Stut <[EMAIL PROTECTED]> wrote:
The only part of an SSL connection that's not encrypted is the
handshaking that goes on to set it up in the first place. Everything
after that, the GET/POST line, headers and the body as well as the
entire response is encrypted.
One of these days I'
Jared Farrish wrote:
On 5/29/07, Stut <[EMAIL PROTECTED]> 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 a
On 5/29/07, Stut <[EMAIL PROTECTED]> 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 U
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 passwords are encrypted.
https:// is an envelope encryption, so POST data, which is a part of the
packet data, not
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 passwords are encrypted.
> > https:// is an envelope encryption, so POST data, which is a part of the
> > packet data, not packet
Jared Farrish wrote:
1. script for login process is located on a SSL-enabled server, so
usernames and passwords 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 e
1. script for login process is located on a SSL-enabled server, so
usernames and passwords 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.
18 matches
Mail list logo
