php-general Digest 5 Mar 2007 14:14:54 -0000 Issue 4660
Topics (messages 249841 through 249855):
PHP Site Hacking Tools Revealed
249841 by: Wolf
249844 by: Tijnema !
Re: PHP running as CGI? How to set x.php as index page?
249842 by: Micky Hulse
249843 by: Micky Hulse
Re: Password Protect Directory
249845 by: Tijnema !
advise on data encryption security.
249846 by: Gregory Machin
Re: file open dialog box
249847 by: Alain Roger
Re: how to display images stored in DB
249848 by: Martin Marques
Problem with spam
249849 by: Bc. Radek Krejca
Re: [PHP-DB] array field type
249850 by: Bastien Koert
249851 by: Sancar Saran
problem generating a file link
249852 by: George Pitcher
Re: module and access rights
249853 by: Alain Roger
249854 by: Alain Roger
249855 by: Németh Zoltán
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Folks,
I have been busy with life over the last number of months and have
finally been able to sit down and take the time to construct a site to
house the scripts that people have used to try to take down my server.
The following URL links to the majority of the hack tools that have been
tried. They are set to display their source only, a couple of them do
not display their Source, but I am sure that if you look on the web for
them as they are named on the link, that you will find what you seek.
http://ambiguous.dnsalias.net/
Wolf
--- End Message ---
--- Begin Message ---
Hi,
I'm not able to open any of these files, because my NAV detects them as PHP
Backdoor Trojans. So they look nice, but they are detected by my AV (and
probably other AV programs too)
I'm not going to test these scripts, but i think it does show how many harm
a PHP script can do.
Do these scripts work on Linux & Windows?
On 3/5/07, Wolf <[EMAIL PROTECTED]> wrote:
Folks,
I have been busy with life over the last number of months and have
finally been able to sit down and take the time to construct a site to
house the scripts that people have used to try to take down my server.
The following URL links to the majority of the hack tools that have been
tried. They are set to display their source only, a couple of them do
not display their Source, but I am sure that if you look on the web for
them as they are named on the link, that you will find what you seek.
http://ambiguous.dnsalias.net/
Wolf
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Joker7 wrote:
I would suggest you change host as this one seem very restrictive or ask
your host to edit the .htaccess file for you ;(
Hi Chris, thanks for the reply. :)
Yeah, I actually talked to client today, and they are fed-up with host
too... sounds like they want to make a switch asap. On top of being too
developmentally restrictive, they are also very expensive.
Thanks for help -- have a great day/night.
Cheers,
Micky
--
Wishlist: <http://snipurl.com/vrs9>
Switch: <http://browsehappy.com/>
BCC?: <http://snipurl.com/w6f8>
My: <http://del.icio.us/mhulse>
--- End Message ---
--- Begin Message ---
Hi Mike, thanks for the help, I really appreciate your time. :)
Michael Weaver wrote:
It's not a PHP trick, but it should work for you, even with restrictions.
Definitely a good option. Actually, that is close to what I am doing now:
<?php
#header("Refresh: 0; URL=http://www.domain.com/start.php?page=home";);
/* Old technique. */
require('http://www.domain.com/start.php?page=home'); /* Current
technique. */
?>
I chose to use require() for SEO purposes... I think Google tends to
frown upon header redirects and/or refreshes... but require() has become
slightly problematic for other reasons... I think the bottom line is
that this host sucks... need to make a switch. :D
Thanks for the tip, I greatly appreciate your help.
Cheers,
Micky
--
Wishlist: <http://snipurl.com/vrs9>
Switch: <http://browsehappy.com/>
BCC?: <http://snipurl.com/w6f8>
My: <http://del.icio.us/mhulse>
--- End Message ---
--- Begin Message ---
Well, you could try to edit each PHP file and add a piece of login code at
top, but if the directory will also contain images (which need a password to
access), it would not be possible that way.
Tijnema
On 3/4/07, Jason Karns <[EMAIL PROTECTED]> wrote:
I'm trying to find a way to password protect a directory. I currently
have
an authentication and authorization system in place for pages in my
directory. I'd prefer to use my existing system somehow (as it includes
OpenID authentication) as opposed to using htaccess and HTTP Auth. The
only
idea of found is to use mod_rewrite to have a PHP script serve up all the
files in the particular directory and have the authentication handled in
this script. This just seems a little 'hackish' to me. Is there any
other
way to password protect a directory with PHP? I'd even entertain the idea
of using HTTP Auth if I could get PHP to 'login'. For instance, the user
logs in at another page in the site, and then during the login process,
PHP
sets the HTTP Auth password so when the files in the directory are
accessed,
the user has already been logged in.
Any suggestions would be great, I can't find anything else online.
--- End Message ---
--- Begin Message ---
Hi
Can anyone point me in the direction of some good docs / howto's on
building php apps that have fully encrypted databases etc ..
Many thanks
--
Gregory Machin
[EMAIL PROTECTED]
www.linuxpro.co.za
--- End Message ---
--- Begin Message ---
Thanks for your answer Chris, but i already used this example yesterday as
base for my request.
Alain
On 3/5/07, Chris <[EMAIL PROTECTED]> wrote:
Alain Roger wrote:
> Hi,
>
> I would like to have an Open file dialog box in my PHP page like it
> exist on
> Microsoft Windows.
> This dialog box should allow user to select a file from his computer.
>
> Is there something like that in PHP ?
Showing that box isn't php related, but this page has a tutorial about
how to upload files through your browser & manipulate them in php:
http://www.tizag.com/phpT/fileupload.php
--
Postgresql & php tutorials
http://www.designmagick.com/
--
Alain
------------------------------------
Windows XP SP2
PostgreSQL 8.1.4
Apache 2.0.58
PHP 5
--- End Message ---
--- Begin Message ---
On Sat, 3 Mar 2007, steve wrote:
Also, when you hit the 1024 image limit you have to think about
directory schema to store the images, as the linux filesystem (and also
on other 32 bit systems) will start getting slow, until things like ls
will just give you an error.
We have a system (I didn't work on it, just maintaining it) that has
about 1100 images in a directory. I think we aren't seen any problems
just because it's on a 64bit system.
What filesystem has a 1024 image (file) limit?
None, but they start to decay. The real problem comes at about 10000,
which for a DB is a very small amount of data.
The real problem with these 1100 images is that the names are being put by
the user (very bad, not something I would ever do) and the are running out
of understadable names :-)
Also, on ext3 you can add the dir_index option to a volume to use a
btree index on directories (which, funny enough, is the base for some
databases). Not that ext3 is great, mind you, though it is well
tested.
It's the FS we normaly use. :-)
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
Hi,
I have problem with spam over function mail. My clients have badly
written functions and I cannot find where. Is there in php simple
way to detect which script generate mail? I mean like header (in
case of returning mail) or log every using mail function etc.
Thank you
--
Regards
Bc. Radek Krejca
ICQ: 65895541
--- End Message ---
--- Begin Message ---
another option might be to store xml snippets that match the array.
if you are using large numbers of arrays, perhaps a revamping of the db
structure to map the arrays to sub-tables might be in order
bastien
From: Micah Stevens <[EMAIL PROTECTED]>
To: Sancar Saran <[EMAIL PROTECTED]>
CC: [email protected], [email protected]
Subject: Re: [PHP-DB] array field type
Date: Sun, 04 Mar 2007 15:04:42 -0800
Not a single field, but there's several methods of storing trees of
information, which is what an array is. Here's one:
Nested Array storage table:
ArrayID (int, autonumber)
keyname (text)
parent (int)
data (bigtext or whatever would be appropriate for the data you're storing)
For an array like this:
array('one'=>1, 'two'=>array('three'=>3, 'four'=>4))
the table would store these rows:
1, 'one', 0, 1
2, 'two', 0, 2
3, 'three', 2, 3
4, 'four', 2, 4
You can use a recursive function to restore the array, unless you require
the granular functionality this type of process would give you such as
sorting and filtering and statistics gathering.
-Micah
However, I think in the long run, you'd be better off serializing the data.
-Micah
On 03/04/2007 02:15 PM, Sancar Saran wrote:
On Sunday 04 March 2007 23:04, Sancar Saran wrote:
Hi,
I want to know is there any db server around there for store php arrays
natively.
Regards
Sancar
Thanks for responses, it seems I have to give more info about situation.
In my current project, we had tons of arrays. They are very deep and
unpredictable nested arrays.
Currently we are using serialize/unserialize and it seems it comes with
own cpu cost. Xdebug shows some serializing cost blips. Sure it was not SO
BIG deal (for now of course).
My db expertise covers a bit mysql and mysql does not have any array type
field (enum just so simple).
I just want to know is there any way to keep array data type natively in a
sql field.
Regards.
Sancar
_________________________________________________________________
Win a trip for four to a concert anywhere in the world!
http://www.mobilelivetour.ca/
--- End Message ---
--- Begin Message ---
Thanks for all those replies. It seems there was no easy solution (and or
serializing was better solution) for us.
Our arrays contains lots of things.. XML may not fit because content of array
may broke xml structure.
Thanks for help.
Regards
Sancar.
> >>>Hi,
> >>>
> >>>I want to know is there any db server around there for store php arrays
> >>>natively.
> >>>
> >>>Regards
> >>>
> >>>Sancar
> >>
> >>Thanks for responses, it seems I have to give more info about situation.
> >>
> >>In my current project, we had tons of arrays. They are very deep and
> >>unpredictable nested arrays.
> >>
> >>Currently we are using serialize/unserialize and it seems it comes with
> >>own cpu cost. Xdebug shows some serializing cost blips. Sure it was not
> >> SO BIG deal (for now of course).
> >>
> >>My db expertise covers a bit mysql and mysql does not have any array type
> >>field (enum just so simple).
> >>
> >>I just want to know is there any way to keep array data type natively in
> >> a sql field.
> >>
> >>Regards.
> >>
> >>Sancar
>
> _________________________________________________________________
> Win a trip for four to a concert anywhere in the world!
> http://www.mobilelivetour.ca/
--- End Message ---
--- Begin Message ---
Hi,
I have a web page that only I see, and I want to link to a PDF file on a
mapped drive so that it will open in Acrobat.
I have tried variations on the following:
$storelink = "<a href=\"file://G:\\".$filename.".pdf\"
target=\"_blank\">PDF</a>";
and the link keeps coming out as:
file:///G:/575991.pdf
So I have 3 x '/' and a '/' where I want a '\'.
Can anyone tell me how to code this to get it right?
MTIA
Cheers
George
--- End Message ---
--- Begin Message ---
But where do you store the $server_unique_key ?
in DB ?
if yes, it should be different for each user logged-in to system.
Moreover, the $chec_string algorithm should not written in cookie as it is a
weakness from my point of view.
Alain
On 3/4/07, Tijnema ! <[EMAIL PROTECTED]> wrote:
Give your server a unique ID, and add that to your check string lets say
so you store in your cookie the username and the check string.
example
$user = "tijnema";
$server_unique_key =
"w#$#%#54dfa4vf4w5$2!@@$<w#$%23%25%2354dfa4vf4w5$2!@@$>
";
$check_string = md5($server_unique_key.$user.$server_unqie_key);
and check that each time the user does an action.
Tijnema
-----
Now to the PHP list....
On 3/4/07, Alain Roger <[EMAIL PROTECTED]> wrote:
>
> Ok, but i would be very glad to know how can i REALLY authenticate the
> user.
> for example, user is logged, so i have in the cookie his login name.
>
> how can i be sure that it's the same user and not some hacker who hacked
> the cookie and the session ?
> what should be checked and where those data should be stored ?
>
> because i can store in DB the sessionID, and check it to every DB
request
> user does...but a sessionID can be easily fake.
>
> So what should I do ?
>
> Al.
>
> On 3/4/07, Tijnema ! <[EMAIL PROTECTED]> wrote:
> >
> > On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
> > >
> > > Alain Roger wrote:
> > > > I would like to implement a module access rights in my web
> > application.
> > > > Basically after authentication and authorization. Logged user has
a
> > > > particular profile which allow him to have access to some part of
> > the
> > > web
> > > > application.
> > > >
> > > > after reading the security guide from *php*sec.org webpage, i'm
> > confused
> > > > regarding how to store user login and password.
> > > > I mean the encrypted password stored in database is compared to
> > > encrypted
> > > > password that user type.
> > > >
> > > > But where to store login and password once user is logged ?
> > > >
> > > > when i read the security guide it seems that it is not secured
> > enough to
> > > > store them in cookies or in sessions data...
> > > > both can be hacked... So what is the best solution ?
> > > >
> > > > i will use those stored data to check if logged user can have
access
> > to
> > > a
> > > > particular part of the web application.
> > > >
> > > > What is your point of view in such domain ?
> > >
> > > Ok, once the user has logged in there is no need to store the
> > password.
> > > Simply store the username or other user details (but not the
password)
> >
> > > in the session - that's as secure as it's gonna get.
> > >
> > > *Never* store a password in a cookie. *Ever*.
> > >
> > > -Stut
> >
> >
> > That's right, never store a password in a cookie or session, maybe a
> > little
> > extra security could be added by locking the cookie to a IP address,
but
> > even more secure isn't possible.
> >
> > Tijnema
> >
> > --
> > > PHP General Mailing List (http://www.php.net/ )
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
>
>
> --
> Alain
> ------------------------------------
> Windows XP SP2
> PostgreSQL 8.1.4
> Apache 2.0.58
> PHP 5
>
--
Alain
------------------------------------
Windows XP SP2
PostgreSQL 8.1.4
Apache 2.0.58
PHP 5
--- End Message ---
--- Begin Message ---
I already started to use SSL, but i do not understand how to keep it
running.
I mean after user has been authenticated and authorized to go further, all
next web pages are opened using PHP location(https://...); command.
however, it does not certify that it can not be faked by just typing into
browser address bar https://another_webpage.php
for example :
1.my login page is called "index.php" and it is accessible only by https. if
user type http://../index.php, the index.php redirect itself to
https://.../index.php.
2. user type logon and password.
3. application control it with information stored into DB and authorize user
to go further, so a session is created and user is redirected to
https://.../welcome.php
what avoid hacker to directly type https://.../welcome.php ?
how to be sure that it works correctly as in my example ?
thanks a lot,
Al.
On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
Tijnema ! wrote:
> On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
>>
>> Tijnema ! wrote:
>> > Give your server a unique ID, and add that to your check string lets
>> say
>> > so you store in your cookie the username and the check string.
>> >
>> > example
>> > $user = "tijnema";
>> > $server_unique_key =
>> > "w#$#%#54dfa4vf4w5$2!@@$<w#$%23%25%2354dfa4vf4w5$2!@@$>
>> > ";
>> > $check_string = md5($server_unique_key.$user.$server_unqie_key);
>> >
>> > and check that each time the user does an action.
>>
>> How, exactly, is that any more secure than a standard session
identifier?
>>
>> While it's good to worry about security, adding pointless activity such
>> as this to every request is not going to help. Anything you do is going
>> to involve some piece of data being transferred from client to server,
>> and can therefore be faked/shared by the client. Get over it.
>>
>> -Stut
>
> It is ofcourse possible to share it to another client, but when
combining
> this with the IP address. This means it can only be used in the same
LAN.
> To get to the point, using this means you cannot simply fake the
> username in
> the cookie, which is possible else. session identifiers can be faked
too.
As I said in another email, you *cannot* use the IP address for any
verification without causing usability issues. It is perfectly
legitimate for sequential requests from any given user to come from
different IP addresses. The biggest user of systems like this is AOL,
and that's a fairly large user base you may want to avoid annoying by
insisting that they login for every other request.
In short, this issue has been discussed to death, not only by the PHP
community but also by the web community at large. If you're really
paranoid, use SSL to secure all data transferred, but just accept that
it's possible that a session may be hijacked. However, unless you're a
bank, is anyone really going to bother?
-Stut
>> On 3/4/07, Alain Roger <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Ok, but i would be very glad to know how can i REALLY authenticate
the
>> >> user.
>> >> for example, user is logged, so i have in the cookie his login name.
>> >>
>> >> how can i be sure that it's the same user and not some hacker who
>> hacked
>> >> the cookie and the session ?
>> >> what should be checked and where those data should be stored ?
>> >>
>> >> because i can store in DB the sessionID, and check it to every DB
>> request
>> >> user does...but a sessionID can be easily fake.
>> >>
>> >> So what should I do ?
>> >>
>> >> Al.
>> >>
>> >> On 3/4/07, Tijnema ! <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> > On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
>> >> > >
>> >> > > Alain Roger wrote:
>> >> > > > I would like to implement a module access rights in my web
>> >> > application.
>> >> > > > Basically after authentication and authorization. Logged user
>> has
>> a
>> >> > > > particular profile which allow him to have access to some
>> part of
>> >> > the
>> >> > > web
>> >> > > > application.
>> >> > > >
>> >> > > > after reading the security guide from *php*sec.org webpage,
i'm
>> >> > confused
>> >> > > > regarding how to store user login and password.
>> >> > > > I mean the encrypted password stored in database is compared
to
>> >> > > encrypted
>> >> > > > password that user type.
>> >> > > >
>> >> > > > But where to store login and password once user is logged ?
>> >> > > >
>> >> > > > when i read the security guide it seems that it is not secured
>> >> > enough to
>> >> > > > store them in cookies or in sessions data...
>> >> > > > both can be hacked... So what is the best solution ?
>> >> > > >
>> >> > > > i will use those stored data to check if logged user can have
>> >> access
>> >> > to
>> >> > > a
>> >> > > > particular part of the web application.
>> >> > > >
>> >> > > > What is your point of view in such domain ?
>> >> > >
>> >> > > Ok, once the user has logged in there is no need to store the
>> >> > password.
>> >> > > Simply store the username or other user details (but not the
>> >> password)
>> >> >
>> >> > > in the session - that's as secure as it's gonna get.
>> >> > >
>> >> > > *Never* store a password in a cookie. *Ever*.
>> >> > >
>> >> > > -Stut
>> >> >
>> >> >
>> >> > That's right, never store a password in a cookie or session, maybe
a
>> >> > little
>> >> > extra security could be added by locking the cookie to a IP
address,
>> >> but
>> >> > even more secure isn't possible.
>> >> >
>> >> > Tijnema
>> >> >
>> >> > --
>> >> > > PHP General Mailing List (http://www.php.net/ )
>> >> > > To unsubscribe, visit: http://www.php.net/unsub.php
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Alain
>> >> ------------------------------------
>> >> Windows XP SP2
>> >> PostgreSQL 8.1.4
>> >> Apache 2.0.58
>> >> PHP 5
>> >>
>> >
>>
>>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Alain
------------------------------------
Windows XP SP2
PostgreSQL 8.1.4
Apache 2.0.58
PHP 5
--- End Message ---
--- Begin Message ---
2007. 03. 5, hétfő keltezéssel 15.05-kor Alain Roger ezt írta:
> I already started to use SSL, but i do not understand how to keep it
> running.
>
> I mean after user has been authenticated and authorized to go further, all
> next web pages are opened using PHP location(https://...); command.
> however, it does not certify that it can not be faked by just typing into
> browser address bar https://another_webpage.php
>
> for example :
> 1.my login page is called "index.php" and it is accessible only by https. if
> user type http://../index.php, the index.php redirect itself to
> https://.../index.php.
> 2. user type logon and password.
> 3. application control it with information stored into DB and authorize user
> to go further, so a session is created and user is redirected to
> https://.../welcome.php
>
> what avoid hacker to directly type https://.../welcome.php ?
> how to be sure that it works correctly as in my example ?
you should check the session settings in the beginning of welcome.php
if session is not set correctly redirect to index.php instead
greets
Zoltán Németh
>
> thanks a lot,
>
> Al.
>
> On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
> >
> > Tijnema ! wrote:
> > > On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Tijnema ! wrote:
> > >> > Give your server a unique ID, and add that to your check string lets
> > >> say
> > >> > so you store in your cookie the username and the check string.
> > >> >
> > >> > example
> > >> > $user = "tijnema";
> > >> > $server_unique_key =
> > >> > "w#$#%#54dfa4vf4w5$2!@@$<w#$%23%25%2354dfa4vf4w5$2!@@$>
> > >> > ";
> > >> > $check_string = md5($server_unique_key.$user.$server_unqie_key);
> > >> >
> > >> > and check that each time the user does an action.
> > >>
> > >> How, exactly, is that any more secure than a standard session
> > identifier?
> > >>
> > >> While it's good to worry about security, adding pointless activity such
> > >> as this to every request is not going to help. Anything you do is going
> > >> to involve some piece of data being transferred from client to server,
> > >> and can therefore be faked/shared by the client. Get over it.
> > >>
> > >> -Stut
> > >
> > > It is ofcourse possible to share it to another client, but when
> > combining
> > > this with the IP address. This means it can only be used in the same
> > LAN.
> > > To get to the point, using this means you cannot simply fake the
> > > username in
> > > the cookie, which is possible else. session identifiers can be faked
> > too.
> >
> > As I said in another email, you *cannot* use the IP address for any
> > verification without causing usability issues. It is perfectly
> > legitimate for sequential requests from any given user to come from
> > different IP addresses. The biggest user of systems like this is AOL,
> > and that's a fairly large user base you may want to avoid annoying by
> > insisting that they login for every other request.
> >
> > In short, this issue has been discussed to death, not only by the PHP
> > community but also by the web community at large. If you're really
> > paranoid, use SSL to secure all data transferred, but just accept that
> > it's possible that a session may be hijacked. However, unless you're a
> > bank, is anyone really going to bother?
> >
> > -Stut
> >
> > >> On 3/4/07, Alain Roger <[EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >> Ok, but i would be very glad to know how can i REALLY authenticate
> > the
> > >> >> user.
> > >> >> for example, user is logged, so i have in the cookie his login name.
> > >> >>
> > >> >> how can i be sure that it's the same user and not some hacker who
> > >> hacked
> > >> >> the cookie and the session ?
> > >> >> what should be checked and where those data should be stored ?
> > >> >>
> > >> >> because i can store in DB the sessionID, and check it to every DB
> > >> request
> > >> >> user does...but a sessionID can be easily fake.
> > >> >>
> > >> >> So what should I do ?
> > >> >>
> > >> >> Al.
> > >> >>
> > >> >> On 3/4/07, Tijnema ! <[EMAIL PROTECTED]> wrote:
> > >> >> >
> > >> >> > On 3/4/07, Stut <[EMAIL PROTECTED]> wrote:
> > >> >> > >
> > >> >> > > Alain Roger wrote:
> > >> >> > > > I would like to implement a module access rights in my web
> > >> >> > application.
> > >> >> > > > Basically after authentication and authorization. Logged user
> > >> has
> > >> a
> > >> >> > > > particular profile which allow him to have access to some
> > >> part of
> > >> >> > the
> > >> >> > > web
> > >> >> > > > application.
> > >> >> > > >
> > >> >> > > > after reading the security guide from *php*sec.org webpage,
> > i'm
> > >> >> > confused
> > >> >> > > > regarding how to store user login and password.
> > >> >> > > > I mean the encrypted password stored in database is compared
> > to
> > >> >> > > encrypted
> > >> >> > > > password that user type.
> > >> >> > > >
> > >> >> > > > But where to store login and password once user is logged ?
> > >> >> > > >
> > >> >> > > > when i read the security guide it seems that it is not secured
> > >> >> > enough to
> > >> >> > > > store them in cookies or in sessions data...
> > >> >> > > > both can be hacked... So what is the best solution ?
> > >> >> > > >
> > >> >> > > > i will use those stored data to check if logged user can have
> > >> >> access
> > >> >> > to
> > >> >> > > a
> > >> >> > > > particular part of the web application.
> > >> >> > > >
> > >> >> > > > What is your point of view in such domain ?
> > >> >> > >
> > >> >> > > Ok, once the user has logged in there is no need to store the
> > >> >> > password.
> > >> >> > > Simply store the username or other user details (but not the
> > >> >> password)
> > >> >> >
> > >> >> > > in the session - that's as secure as it's gonna get.
> > >> >> > >
> > >> >> > > *Never* store a password in a cookie. *Ever*.
> > >> >> > >
> > >> >> > > -Stut
> > >> >> >
> > >> >> >
> > >> >> > That's right, never store a password in a cookie or session, maybe
> > a
> > >> >> > little
> > >> >> > extra security could be added by locking the cookie to a IP
> > address,
> > >> >> but
> > >> >> > even more secure isn't possible.
> > >> >> >
> > >> >> > Tijnema
> > >> >> >
> > >> >> > --
> > >> >> > > PHP General Mailing List (http://www.php.net/ )
> > >> >> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >> >> > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Alain
> > >> >> ------------------------------------
> > >> >> Windows XP SP2
> > >> >> PostgreSQL 8.1.4
> > >> >> Apache 2.0.58
> > >> >> PHP 5
> > >> >>
> > >> >
> > >>
> > >>
> > >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
--- End Message ---
