On Thu, Jun 7, 2012 at 11:15 AM, Tedd Sperling t...@sperling.com wrote:
3. Looking for an explanation, I came across Daniel's post to the PHP manual,
which follows:
http://www.webbytedd.com/b/sessions3
Now I am totally bonkers.
What am I not getting?
Anything. Because that page
On Thu, Jun 7, 2012 at 11:20 AM, Daniel P. Brown
daniel.br...@parasane.net wrote:
On Thu, Jun 7, 2012 at 11:15 AM, Tedd Sperling t...@sperling.com wrote:
3. Looking for an explanation, I came across Daniel's post to the PHP
manual, which follows:
http://www.webbytedd.com/b/sessions3
I
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
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 without
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 only
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
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 headers,
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
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
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
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'm
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:
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
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
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
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,
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
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,
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
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.
20 matches
Mail list logo
