Is it a secure way to declare DB parameters in htaccess rather than in a PHP file?

This is a reasonable approach. The benefit of this approach is that it avoids storing your password in the source code. This is a good thing: you should not hardcode passwords in your source code.

(Of course, with this suggestion, the database password is not stored in the .htaccess file; instead, it is stored in a separate configuration file. But the difference is inconsequential.)

Important: Make sure that sql.cnf is not stored within your web root. If it is stored in your web root, maybe anyone who knows the right path to it will be able to request it just by sending a GET request.

• There is an additional risk with storing passwords in a sql.cnf file within your webroot, which is a bit obscure but can be easily avoided by placing the file outside of your web root. Consider: if you are editing sql.cnf using a text editor, and your connection drops while you are editing it, your editor will automatically save a copy of the sql.cnf file in some backup file: e.g., sql.cnf~ (in the same directory). Now the backup file has a different extension, so if someone tries to fetch that file, the Apache server will happily serve up a copy of the file in plaintext, revealing your database password. See 1% of CMS-Powered Sites Expose Their Database Passwords for details.

For more reading on the general principle:

• Should a closed source website keep a secret key in its source?

• where to store a key for encryption

• How do open source projects handle secure artifacts?

The recommendation is predicated on the fact that PHP files will be world-readable but .htaccess files / httpd.conf won't. The author rightly points out that using encryption to hide these values doesn't help - since that means the encryption key needs to be accessible to PHP code. But storing the values in the environment only avoids some issues which are also avoidable by other means. Values in an httpd.conf file will be readable by any PHP code run on the server. Moving them into a vhost defn narrows the visibility. You can keep them as PHP code within the document root by simply prepending the filename with '.ht'.

Certainly it's good practice to maintain the tokens indepently of the bulk of the code. Since

• they will have a different lifespan than the code (i.e. may need changed independently of the code and vice versa)
• should not be exposed via code management facilities such as the version control system
• should vary depending on where the code is deployed (i.e. different tokens for test / stage / live)

However using the webserver config is only one way to achieve this - there are other valid approaches.

Regardless of which route you take, the security of the solution will come from considering all aspects - file permisssions / accessibility of the file, restrictions on DB connection, access controls at the DB