--- Video Populares et Optimates <[EMAIL PROTECTED]> wrote:
> > If you mean to protect your source from your users, that is the case
> > already. Unless someone can compromise your server, they never get
> > access to the source, only its output.
>
> True! But what for the network technicians, sys
>
> If you mean to protect your source from your users, that is the case
> already. Unless someone can compromise your server, they never get access
> to the source, only its output.
>
True! But what for the network technicians, system administrators and web
developers (to be very paranoid) that a
Yes, I've had that thought also. I believe that the question you suggest
will probably the foundation of the main course I'll take. For what
possibilities are there really to hide anything in plain text that anyway
will reside on third-party servers. (rhetorical question)
You can never know what
--- Video Populares et Optimates <[EMAIL PROTECTED]> wrote:
> I'm pondering on a problem here. Being a C/C++, Java and Visual Basic
> developer, the aspect of reverse engineering code from (compiled)
> programs, hasn't occupied my mind that much.
> Now, developing PHP scripts on large scale I have
[snip]
I'm pondering on a problem here. Being a C/C++, Java and Visual Basic
developer, the aspect of reverse engineering code from (compiled)
programs, hasn't occupied my mind that much.
Now, developing PHP scripts on large scale I have started to think
otherwise. How do you all secure your code?
On 30 Jun 2003 at 11:20, - Edwin - wrote:
> > Warning: Error parsing /mydirectory/mysql.ini on line 4 in Unknown
> > on line 0 Array ( [host] => spore.org [uid] => myuserid [passwd] =>
> > mypassword)
> >
> > The error message still remains, though now the test confirms that
> > mysql.ini is bei
"Doug Essinger-Hileman" <[EMAIL PROTECTED]> wrote:
[snip]
>
> This leads to the following output:
>
> Warning: Error parsing /mydirectory/mysql.ini on line 4 in Unknown on
> line 0 Array ( [host] => spore.org [uid] => myuserid [passwd] =>
> mypassword)
>
> The error message still remains, tho
The INI file should be:
[mysql_info]
host=spore.org
uid=myuserid
passwd=mypassword
Also, you'll probably want to do:
$INI = parse_ini_file("/home/revref/mysql.ini");
Doug Essinger-Hileman wrote:
I am just beginning to use php and mysql together (I'm new to both).
I am having trouble getting th
On 30 Jun 2003 at 10:25, - Edwin - wrote:
> > [mysql_info}
>
> I think you meant [mysql_info]? (Check the closing bracket.)
It is correct on the server. My fingers didn't type what my brain
told
them to for this email.
> Notice that you need to do something like this: (based on your
> example)
For some people, putting information outside the docroot isn't possible,
especially when your site is hosted.
On thing you can also try (which is nowhere near the security of outside
the docroot) is to put ocnfig data (user, pass, etc...) inside it's own
php file that is included in outfiles. F
Hello,
"Doug Essinger-Hileman" <[EMAIL PROTECTED]> wrote:
> On 25 Jun 2003 at 16:42, Dan Joseph wrote:
>
> > Store that file outside the docroot. That way there is no chance
> > they can
> > get it from the web site. I myself use an ini file that is no where
> > near the docroot, and use par
On 25 Jun 2003 at 16:42, Dan Joseph wrote:
> Store that file outside the docroot. That way there is no chance
> they can
> get it from the web site. I myself use an ini file that is no where
> near the docroot, and use parse_ini_file() to load the DB
> information in, and then I connect to it.
On Friday 27 June 2003 15:01, [EMAIL PROTECTED] wrote:
> This is true for your own authentication but I mean how to connect to the
> database using md5.
You can't. However starting with MySQL 4 you can connect using SSL encryption,
but that would only be of significance if connection is remote.
On Thursday 26 June 2003 16:22, Jeff Harris wrote:
> http://www.php.net/md5
>
> Set the column type of password to be a char(32). Then, pass the password
> through md5 to mysql to store it. To verify it, pass the password through
> md5 then compare it to what's in the database.
Or, to avoid proble
|Hello Justin or Anybody else
|
|> Store an MD5 of the password, that way you're comparing the two hashes,
|not
|> two passwords... even if someone stumbles into your database, they'll
|only
|> see the MD5'd password. A further step would be encryption, on which
|you
|> will have to do a LOT of re
Hi,
> The only reason that I was so adamant about it was I had a 'heated'
> discussion with a business associate who's server was compromised - and he
> was, lets say, insistant that the fact that there were database
> passwords in
> a php file inside the webroot was the reason it was insecure. I
Hi,
> Why rely on some access restriction when you don't have to? You
> include code
> using a filesystem path. There is no need for it to reside under
> document root.
> Yes, you can make it so that certain things are not served
> directly by the Web
> server, but why take the extra risk? You gai
Hello Justin or Anybody else
> Store an MD5 of the password, that way you're comparing the two hashes,
not
> two passwords... even if someone stumbles into your database, they'll
only
> see the MD5'd password. A further step would be encryption, on which
you
> will have to do a LOT of reading.
I'm not a security expert at all, but...
The short answer to your question is that if you have to ask how to make
your code secure, then chances are, you probably shouldn't be attempting it
at all... but then again, we all have to learn somewhere...
Do a google search, and read thousands of artic
> "Maybe I am missing something totally obvious, but if the server is set up
> to
> properly parse php files - having configs outside of the doc root should not
> make much of a security difference?
> "
>
> Is this a true statement or not? (of course we have to make the assumption
> that server a
Ok :)
The only reason that I was so adamant about it was I had a 'heated'
discussion with a business associate who's server was compromised - and he
was, lets say, insistant that the fact that there were database passwords in
a php file inside the webroot was the reason it was insecure. I just wa
>> Why rely on some access restriction when you don't have to? You include
>> code using a filesystem path. There is no need for it to reside under
>> document root. Yes, you can make it so that certain things are not
>> served directly by the Web server, but why take the extra risk? You
>> gain no
> --- Mike Morton <[EMAIL PROTECTED]> wrote:
>> That is precisely my point - if the user has shell access of any
>> type you are compromised - but if they do not get server access -
>> how could they possibly get the dotabase.inc.php? If that is
>> called directly then it will be parsed, and as l
--- Mike Morton <[EMAIL PROTECTED]> wrote:
> That is precisely my point - if the user has shell access of any
> type you are compromised - but if they do not get server access -
> how could they possibly get the dotabase.inc.php? If that is
> called directly then it will be parsed, and as long as
2) I store the db password and login info in a database.inc.php file.
Is there any way I can prevent a person from getting the db pass even
after he gets this file?
>>>
>>> Store that file outside the docroot. That way there is no chance they
>>> can get it from the web site. I m
>>> 2) I store the db password and login info in a database.inc.php file.
>>> Is there any way I can prevent a person from getting the db pass even
>>> after he gets this file?
>>
>> Store that file outside the docroot. That way there is no chance they
>> can get it from the web site. I myself us
Dan:
>> 2) I store the db password and login info in a database.inc.php
>> file. Is there any way I can prevent a person from getting the db
>> pass even after he gets this file?
>
> Store that file outside the docroot. That way there is no chance they can
> get it from the web site. I myself u
>I am getting started on a project on PHP that requires very very high
>levels of security. I cannot give you exact details but the basics is
>that it deals with credit cards.
>
>I want some advice and tips from experts on the following
>The server will be Red Hat Linux 7.3
>
>1) The site will have
Hi,
> 2) I store the db password and login info in a database.inc.php
> file. Is there any way I can prevent a person from getting the db
> pass even after he gets this file?
Store that file outside the docroot. That way there is no chance they can
get it from the web site. I myself use
And, you can add to this
> Never trust data from the client...always filter it(I use an lib to do
that)!
> Make sure register_globals is off or code accordingly.
Make sure that you're using SSL (https).
Also, (maybe not directly related though...) if possible, separate your web
server from your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Never trust data from the client...always filter it(I use an lib to do that)!
Make sure register_globals is off or code accordingly.
HTH!
~Paul
On Saturday 09 November 2002 01:12 am, Creighton Brown wrote:
> I want to know recommendations securing GET
31 matches
Mail list logo
