Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: MYSQL and PHP

Subject: Re: MYSQL and PHP
Date: Tue, 16 May 2006 23:20:14 -0700 (PDT)
But an attacker from the outside will be attacking through the script
(or so I'll assume here).  So, the attacker will still have effective
access to this information, or at least be able to use it, which is
really the point.  So, my question is (though this may be a stupid
one), what security benefits would you get from encrypted user/pass
aside from security through obscurity at the "wrong" point of entry? 
After all, if the script can get at it automagically...

I really see this as the same solution as putting the user/pass in a
non-encrypted way outside of document root.  Out of reach of "common
knowledge," but still trivial to use to attack the system.

Sure, as has been mentioned before, encrypting *may* slow down the
attacker (from the inside).  But, if the key is stored either in the DB
or on another server or... how much more overhead is that going to
incurr?  Is that even practical with a busy server?  etc.

Also, will this even help?  Will "that" particular implimentation
actually improve the situation? or make it worse?  After all, the more
complicated the system, the more likely there are bugs, etc sitting
around.


IMO, put the user/pass in a file (.php) outside of document root.  But,
have several users with a variety of DB permissions, so that any given
query has _only_ the permissions it absolutely needs.

After that, if the web server is properly configured, it's up to the
webapp to sanitize the input and make sure the user is actually the
user, etc.  Unless I'm missing something entirely... maybe... it's
late.



best regards,
Reid


--- bugtraq@cgisecurity.net wrote:

Windows provides a way in ASP.NET to store the user/pass encrypted in
the registry and simply referencing it in your web.config
allows it to automagically work. I'm curious what solutions for php
exist to allow encrypted storage of sql login credentials
so we can avoid the whole storage in cleartext on the filesystem?

- zeno
http://www.cgisecurity.com/ Web Security news, and More
http://www.cgisecurity.com/index.rss [RSS Feed]




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-------------------------------------------------------------------------
Sponsored by: Watchfire

Watchfire named worldwide market share leader in web application security 
assessment by leading market research firm. Watchfire's AppScan is the 
industry's first and leading web application security testing suite, and 
the only solution to provide comprehensive remediation tasks at every 
level of the application. See for yourself. 
Download a Free Trial of AppScan 6.0 today!

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c
--------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>