Hey there. I am connecting to a MySQL database for my first real Phalcon app, and I can't help but notice that the login and password for the database user are hardcoded in plain text in app/config/config.php. Is there any way to obfuscate that somehow? So that if someone manages to get into the file system they can't use this information to gain access to the database. Thanks!
The best practive to handling this is having another configs for production that is not included to you version control (GIT/SVN) too.
you should have two config file like developemnt.php and production.php that development.php is inculded to your project files but production.php only exists on your production server the use it based on your app environment.
there are many ways to implement this. for example:
if (hostname() == 'my-laptop') {
$config = include __DIR__ . '/config/development.php'; // in your project files
} else {
$config = include __DIR__ . '/config/production.php'; // only exist on your production server
}
$di = new Phalcon\DI\FactoryDefault();
$di->set('config', $config);
If a person has access to your filesystem, your server is compromised and it doesn't matter where you keep your files - they'll still be able to find the file. If the server is compromised, and it also holds your database, then it doesn't matter if they can read your credentials - they have access to your database anyway. So, there's no real need to worry about hiding your credentials from someone that has access to your filesystem.
One legitimate, but in my opinion overly paranoid, concern could be what happens if the Phalcon AND mod_rewrite modules both die, but Apache keeps running. In that case, a web user could have access to the config.php file and have it delivered as raw text. However, the likelihood of both those modules not running, and Apache still working, is practically zero. It may even be impossible - I'm not that much of an Apache expert. Even if it did happen and your credentials got out, you could (and should) lock down your database to only be accessible from known IPs, or from "localhost".
In short, don't worry about it, just make sure the database itself is secure.
Due to the separation of the bootstrap file and the application directory, theoretically all your configuration files and application should/would be outside of the public HTML directory scope too ;)
If a person has access to your filesystem, your server is compromised and it doesn't matter where you keep your files - they'll still be able to find the file. If the server is compromised, and it also holds your database, then it doesn't matter if they can read your credentials - they have access to your database anyway. So, there's no real need to worry about hiding your credentials from someone that has access to your filesystem.
One legitimate, but in my opinion overly paranoid, concern could be what happens if the Phalcon AND mod_rewrite modules both die, but Apache keeps running. In that case, a web user could have access to the config.php file and have it delivered as raw text. However, the likelihood of both those modules not running, and Apache still working, is practically zero. It may even be impossible - I'm not that much of an Apache expert. Even if it did happen and your credentials got out, you could (and should) lock down your database to only be accessible from known IPs, or from "localhost".
In short, don't worry about it, just make sure the database itself is secure.
To be honest here I don't think there is a better way to secure a database through a file system that is connected to that DB.
That is why always choose to work with a development server on which case the cloned database structure may not have the same copy of data in the production server.
An option would be to create a user with less privileges to the database but again such user will have no business accessing the file system. That is where I would still recommend woking with a development server that has different passwords to that in the production and if possible with all tables truncated.
Remember security vulnerability has no one single solution to provide end to end measures. Just try out many options that make system more secure.