Security - Maybe a silly question

[Sed]

When I use sessions in PHP or just plain login/password in $_POST, can
3rd parties or hackers monitor the transmission, between me and user,
and somehow decode the transmission and use the variables to login other
time or overtake the current session?

If so, how likely is for someone to manage it (get the
username/password)?

Regards,
Sumarlidi E. Dadason

SED - Graphic Design
_________________________________
Tel: +354-896-0376, +354-461-5501
E-mail: s...@sed.is
website: www.sed.is

[Rija]

Yes,
Between user and server, everydata pass through DNS, routeur, etc...
So if you don't want someone (hackers or FBI of CIA) to decode your data,
use SSL server (https://) with certificate-

> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[Sed]

I'm not very familiar to this stuff, but if I wanna use https:// do
don't I need a key from Verisign (or similar) to make it work? If so,
who control who is what on the internet?

Regards,
Sumarlidi E. Dadason

SED - Graphic Design
_________________________________

Tel: 896-0376, 461-5501
E-mail: s...@sed.is
website: www.sed.is

[@ Edwin]

"SED" <s...@sed.is> wrote:
> I'm not very familiar to this stuff, but if I wanna use https:// do
> don't I need a key from Verisign (or similar) to make it work?

Yes and no. If you're going to use it on a production server, yes.
If it's on a test server but you still want to be somehow "protected",
then, no--no you don't need a key from Verisign or others.

> If so, who control who is what on the internet?

That's a tricky question. Perhaps, you need to be more specific. But,
I'm afraid the question would be a bit OT...

- E

[Chris Shiflett]

SED wrote:

>When I use sessions in PHP or just plain login/password in $_POST, can
>3rd parties or hackers monitor the transmission, between me and user,
>and somehow decode the transmission and use the variables to login other
>time or overtake the current session?
>
>If so, how likely is for someone to manage it (get the
>username/password)?
>

I've read some of the responses to your question, and I think I can
possibly help to clarify some things ...

To answer your question directly, yes it is possible for people (hacker
!= computer criminal, by the way) to observe the transmission, but it is
not very likely. Also, if someone successfully observes a user's HTTP
request, they will have access to the user's data whether it is being
sent via get, post, or cookies. There is no "decoding" necessary.
However, though this is not too terribly difficult to accomplish, it is
a lot harder than some people will lead you to believe. If you are
worried about the security of your users, here are some things to
consider in that regard:

1. For anyone to observe a specific transaction, they must have access
to a machine that is between you (the Web server) and them (the Web
client). For someone to reliably do this, they would need to have access
to a machine along the path that is either very near the Web client (for
targetting a specific user) or very near your Web site (for targetting a
specific site, yours). Anything in between would likely have too much
traffic. Needless to say, this scenario is unlikely. An example of such
a thing would be perhaps if a curious systems administrator were
observing outgoing traffic on a gateway that served a small office. If
someone who worked in that office interacted with your Web site, it
would be quite easy for the administrator to observe the transaction.

2. There are much easier ways to impersonate a user. PHP, by default,
uses a single cookie to identify the Web client. Imagine if someone were
to steal a cookie belonging to one of your users and then visit your
site presenting the same cookie. You would mistake them for your user,
right? Most attacks focus on the application itself, just like this
example, because this is the usually the easiest thing to do. All
versions of Internet Explorer from 4.0 to 6.0 have cookie
vulnerabilities that allow any Web site to view any other Web site's
cookies. So, if some of your users are IE users (very likely) and have
not patched their browsers (also very likely), that cookie you use to
identify them is in danger.

In general, security is a balance. There is always going to be a risk.
The harder you make it for the bad guys, the less risk you have, but
also (usually) the less accomodating you are to your legitimate users -
shorter timeouts, requiring frequent reauthentication, extra data
validation, etc. The easier it is for the bad guys, the higher the risk,
but the more accomodating you can be to your users - longer timeouts,
automatic features, storing payment information for easier checkouts,
etc. The appropriate balance here is really best decided by you, but
this can be difficult when you first get started.

Also, as others have said, SSL is the only way to reliably protect the
communication from observation (it also verifies the identify of you and
the user, which can be crucial), but if this is not an option, you can
provide some decent security by observing the golden rule of Web
development:

NTDFTC - Never trust data from the client.

This doesn't mean that you can't believe anything; it just means that
your logic should be suspicious of everything you receive from the
client (in PHP, this means $_REQUEST[] or all get, post, and cookie
data) and validate it. Unfortunately, many people do not follow this
rule (or even know about it), and this lead to many of the perceived
security problems of register_globals.

Anyway, let me know if you have any other questions or would like to see
some specific examples.

Chris