[nycphp-talk] Where to store credentials and/or keys
inforequest
1j0lkq002 at sneakemail.com
Mon Aug 14 18:25:25 EDT 2006
csnyder chsnyder-at-gmail.com |nyphp dev/internal group use| wrote:
>On 8/14/06, Dan Cech <dcech at phpwerx.net> wrote:
>
>
>>Chris Shiflett wrote:
>>
>>
>>>If you own neither, I have an old article on my web site that explains
>>>it briefly (near the end):
>>>
>>>http://shiflett.org/articles/security-corner-mar2004
>>>
>>>
>>That is quite a neat trick, and definitely a good one to add to the bag.
>>
>>Dan
>>
>>
>>
>
>Agreed, nice hack. :-)
>
>If you use this method you should probably also disallow calls to
>phpinfo() using the disable_functions configuration directive in
>php.ini, see http://us3.php.net/manual/en/features.safe-mode.php#ini.disable-functions
>
>
Did I read that wrong, or is this only possible from inside php.ini and
so not available to many shared hosting users?
Also, never underestimate the value of obfuscating the filename. Before
anyone shouts "security thru obscurity is not security" let me state
that obscurity is, indeed a form of security, although not a recommended
means of providing security when there are better options available.
Don't take my word for it, read the details of the security gurus. Of
course if Chris or somebody slaps me here I'll defer.
Including a dbconnect.inc or whatever with incorrect (and never used)
details while actually using dbconnect data that was encoded into some
other file with a non-descript name might go a long way to deterring the
script kiddies and opportunists. Repeating the obscurity thing, best
first know why your best bet includes that obfuscation tactic, so you
can 'splain yourself if you get hacked. I might use this to protect
commercial data, but not ss#s and the like.
-=john
--
-------------------------------------------------------------
"If you think this stuff is confusing, you should try optimizing websites for search engine exposure." john andrews SEO http://www.johnon.com
More information about the talk
mailing list