How safe is a .htaccess file?
in [General]
|
From: Nathan Rixham on 19 Aug 2010 13:29 tedd wrote: >> tedd wrote: >>> Hi gang: >>> >>> The subject line says it all. >>> >>> How secure is a .htaccess file to store passwords and other sensitive >>> stuff? >>> >>> Can a .htaccess file be viewed remotely? >> >> Semi-safe, >> >> .htaccess is prevented from being served by configuration options >> (which come as default), however these can be overwritten so best to >> check by doing a GET on the resource URI. >> >> This doesn't prevent them from being exposed via other processes >> though, for instance a poorly coded >> 'download.php?path=/path/to/.htaccess' could still expose the file. >> >> Typically, its obviously better to store only a hash of a password >> rather than the pass in plain text, choosing the strongest algorithm >> you can; password security is of course relative though, a sha-512 of >> 'password1' is far from secure. >> >> A good way to approach encryption for files is to openssl_seal them >> using a public key which is only available to your application - this >> doesn't negate insecure code, but it at least ensures the raw files >> are encrypted securely enough to negate any of these worries. (just >> keep your private key safe, preferably in a pkcs12 w/a strong 64char+ >> pass) >> >> Best, >> >> Nathan > > Nathan: > > I keep in running in circles because I keep getting differing > recommendations as to how to keep data secure. > > If you read Chris Shiflett's book on "Essential PHP Security" -- he says > to keep everything in a database. This means keeping both encrypted data > AND the keys for decryption in the database. > > I contacted Chris specifically and told him of what I was doing (all the > steps) and he approved. However, he said the main weakness in all > security practices is how one protects access to the database. > > So that is my quest. How can I protect the username and password for the > database? Keep in mind that my scripts must also be able to read and use > them in accessing the database. So they must be accessible to scripts. > > I figure using SetEnv to set the user and password in a .htaccess file > is about as secure as I can make it, but now you say even that could be > exposed. > > So specifically, how would you hide the username and password for access > to a database WITHOUT using an "out of root" solution? Please be specific. Hi Tedd, Firstly, advising to keep the keys to your car in the ignition at all times is pretty bad advise - I'll let you relate that to Chris's advice yourself :-) If your stuck in an environment where third parties have access to the files on the file system and you need to put your username/password (real keys to the data) on that filesystem, then I have to point out that no file extension is more secure than another, there's no difference between doing `cat .htaccess` and `cat config.php` you'll still see the output - there's is a measure of difference however between putting it in a web source-viewable file and non-source-viewable file, but again your only a config setting away from being exposed to the world. Given the aforementioned and that the data is sensitive, I'd strongly recommend moving to a different hosting environment: - which is secure filesystem wise and only you have access to your files - where the db server (or data tier) is on a private lan (preventing the db server from public web attacks) - where access to the db server (or data tier) is via a secured connection [1] (encrypting data across the wire to prevent man in the middle attacks and packet inspection) In addition to application specific security measures such as encrypting all sensitive data *before* sending to the database and storing the encryption keys in a secure lockbox far away from the db or at least in a pcks12 password protected file outside of the web root. Now, to answer your specific question, specifically :p If available I would use ioncube or suchlike to encrypt the source of my PHP files (with the username pass in a php file as standard), and if I still didn't feel like that was secure enough then I would: create an pcks12 wrapped x509 certificate for my application: http://pastebin.com/THW00RHt (fill in lines 34+36 stick on web server, view in browser cert will dl) Then I'd store the produced certificate.p12 on the file system (preferably outside of web root, or with access restricted by .htaccess config) I'd then create a crypto class which provided methods to seal and open (encrypt/decrypt) data using the keys from the x509 certificate, and which could read the .p12 wrapped x509, like this: http://pastebin.com/4FSx1XDa I'd then instantiate the crypto class in my application as such: $crypto = ApplicationCrypto::instantiate( file_get_contents('certificate.p12'), 'PASSWORD-FOR-PKCS-HERE' ); Then I'd load my database settings in to an object, serialize it, encrypt the serialization and save it to a file on the filesystem as such: $dbSettings = (object)array( 'username' => 'dbuser', 'password' => 'dbpass', 'host' => 'dbhost', 'database' => 'dbname' ); $sealed = $crypto->seal( json_encode( $dbSettings ) ); file_put_contents( 'dbconfig.x' , json_encode($sealed) ); Then to get the database settings back and use them I'd do the following: $crypto = ApplicationCrypto::instantiate( file_get_contents('certificate.p12'), 'PASSWORD-FOR-PKCS-HERE' ); $sealed = json_decode( file_get_contents('dbconfig.x') ); $dbSettings = json_decode( $crypto->open( $sealed->sealed , $sealed->key ) ); Further steps are possible, such as storing $sealed->key in a different file or file system (as it's double key encryption, both the private key from the certificate and a unique per item key is used). But honestly, that's what I'd do - as a side note, generally the code sealed information is encrypted strongly enough to be made public since you need both keys, the decryption process, and the certificate wrapped in a password protected p12 to turn it back in to anything readable. Hope that helps a little, Best, Nathan [1] http://dev.mysql.com/doc/refman/5.1/en/secure-connections.html
From: "Jan G.B." on 24 Aug 2010 09:08 2010/8/19 Andre Polykanine <andre(a)oire.org>: > Hello Nathan, > > Sorry, could you provide any links to read for a security noob?) > Actually, I know that the md5 is decryptable (there are bases with > words encrypted in md5), but I thought the SHA1 was secure... > -- > With best regards from Ukraine, > Andre > ----- Original message ----- > From: Nathan Rixham <nrixham(a)gmail.com> > To: tedd <tedd(a)sperling.com> > Date: Thursday, August 19, 2010, 12:03:12 PM > Subject: [PHP] Re: How safe is a .htaccess file? > > tedd wrote: >> Hi gang: >> >> The subject line says it all. >> >> How secure is a .htaccess file to store passwords and other sensitive >> stuff? >> >> Can a .htaccess file be viewed remotely? > > Semi-safe, > > .htaccess is prevented from being served by configuration options (which > come as default), however these can be overwritten so best to check by > doing a GET on the resource URI. > > This doesn't prevent them from being exposed via other processes though, > for instance a poorly coded 'download.php?path=/path/to/.htaccess' could > still expose the file. > > Typically, its obviously better to store only a hash of a password > rather than the pass in plain text, choosing the strongest algorithm you > can; password security is of course relative though, a sha-512 of > 'password1' is far from secure. > > A good way to approach encryption for files is to openssl_seal them > using a public key which is only available to your application - this > doesn't negate insecure code, but it at least ensures the raw files are > encrypted securely enough to negate any of these worries. (just keep > your private key safe, preferably in a pkcs12 w/a strong 64char+ pass) > > Best, > > Nathan > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi Nathan, I'm not a crypto expert.. but I'll try to explain it: The weakness of MD5 is mainly because MD5 collisions are possible. That means, that different strings can have the same MD5-hash... When you use "test" as a secret password, then no hashing algorythm at can be considered as "safe". The first two passwords a cracker will try might be "1234" and "test".. No big deal. Databases of MD5-hashes exists. And so can exist Databases of SHA-* hashes. To get around these databases you can just "salt" your hash.. that way the Hash of the word "test" will not be the same as the hash in the database without *your* salt. No matter if you use MD5 or SHA256 $ echo -ne test | md5sum 098f6bcd4621d373cade4e832627b4f6 - $ echo -ne test-mySecretSalt | md5sum c62fb41567c476e36ba46e5b53ae6d59 - Only the first string will be available in a hash-database. So you see - as long as a cracker only get's your salted hashes WITHOUT the used salt, it's pretty safe.. as long as you don't think about ignore collisions! Back to topic: - as mentioned before the biggest risk in authentication via .ht* files is that one can try to get these files via a bug in an application.. (e.g. ?read_file=.htaccess%00) - that's why you don't want to use plain text-passwords in .htaccess files. most used is the htdigest algorythm. Be sure to use a STRONG password: long string with letter, numbers and more chars. - if you're curious, get a copy of "John the Ripper password cracker" and try to decode your passwords.. that's what the bad guys use once they get your .htaccess file. Regards Regards
From: "Brad Broerman" on 24 Aug 2010 09:51 One thing I would do, and I have done this in many of my applications: a) Store the username / password in a database. b) Encrypt passwords (with a salt) with AES-256 using a key stored in a file OUTSIDE the document path. c) Add code to the beginning of the included file to ensure it is only executed by approved files. <?php if( 0 == preg_match( "/maplerunfarm-secure\/admin.php/", $_SERVER["SCRIPT_FILENAME"] ) ) { exit("Error: invalid inclusion of file. Please contact your system administrator"); } $CONST_SECURE_KEY = "DKTAZ+2EFaSHexdE0hbKJKiO/mQeF1hd"; ?> -----Original Message----- From: Jan G.B. [mailto:ro0ot.w00t(a)googlemail.com] Sent: Tuesday, August 24, 2010 9:09 AM To: Andre Polykanine Cc: Nathan Rixham; tedd; php-general(a)lists.php.net Subject: Re: [PHP] Re: How safe is a .htaccess file? 2010/8/19 Andre Polykanine <andre(a)oire.org>: > Hello Nathan, > > Sorry, could you provide any links to read for a security noob?) > Actually, I know that the md5 is decryptable (there are bases with > words encrypted in md5), but I thought the SHA1 was secure... > -- > With best regards from Ukraine, > Andre > ----- Original message ----- > From: Nathan Rixham <nrixham(a)gmail.com> > To: tedd <tedd(a)sperling.com> > Date: Thursday, August 19, 2010, 12:03:12 PM > Subject: [PHP] Re: How safe is a .htaccess file? > > tedd wrote: >> Hi gang: >> >> The subject line says it all. >> >> How secure is a .htaccess file to store passwords and other sensitive >> stuff? >> >> Can a .htaccess file be viewed remotely? > > Semi-safe, > > .htaccess is prevented from being served by configuration options (which > come as default), however these can be overwritten so best to check by > doing a GET on the resource URI. > > This doesn't prevent them from being exposed via other processes though, > for instance a poorly coded 'download.php?path=/path/to/.htaccess' could > still expose the file. > > Typically, its obviously better to store only a hash of a password > rather than the pass in plain text, choosing the strongest algorithm you > can; password security is of course relative though, a sha-512 of > 'password1' is far from secure. > > A good way to approach encryption for files is to openssl_seal them > using a public key which is only available to your application - this > doesn't negate insecure code, but it at least ensures the raw files are > encrypted securely enough to negate any of these worries. (just keep > your private key safe, preferably in a pkcs12 w/a strong 64char+ pass) > > Best, > > Nathan > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi Nathan, I'm not a crypto expert.. but I'll try to explain it: The weakness of MD5 is mainly because MD5 collisions are possible. That means, that different strings can have the same MD5-hash... When you use "test" as a secret password, then no hashing algorythm at can be considered as "safe". The first two passwords a cracker will try might be "1234" and "test".. No big deal. Databases of MD5-hashes exists. And so can exist Databases of SHA-* hashes. To get around these databases you can just "salt" your hash.. that way the Hash of the word "test" will not be the same as the hash in the database without *your* salt. No matter if you use MD5 or SHA256 $ echo -ne test | md5sum 098f6bcd4621d373cade4e832627b4f6 - $ echo -ne test-mySecretSalt | md5sum c62fb41567c476e36ba46e5b53ae6d59 - Only the first string will be available in a hash-database. So you see - as long as a cracker only get's your salted hashes WITHOUT the used salt, it's pretty safe.. as long as you don't think about ignore collisions! Back to topic: - as mentioned before the biggest risk in authentication via .ht* files is that one can try to get these files via a bug in an application.. (e.g. ?read_file=.htaccess%00) - that's why you don't want to use plain text-passwords in .htaccess files. most used is the htdigest algorythm. Be sure to use a STRONG password: long string with letter, numbers and more chars. - if you're curious, get a copy of "John the Ripper password cracker" and try to decode your passwords.. that's what the bad guys use once they get your .htaccess file. Regards Regards
From: Peter Lind on 24 Aug 2010 09:50 On 24 August 2010 15:43, Gary <php-general(a)garydjones.name> wrote: > Jan G.B. wrote: > >> The weakness of MD5 is mainly because MD5 collisions are possible. >> That means, that different strings can have the same MD5-hash... > > http://en.wikipedia.org/wiki/MD5#cite_note-1 It's worth noting that that essentially does not touch upon whether or not MD5 can be considered safe or not as a means to store password information. The researchers have discovered ways of crafting inputs to easily find colliding hashes - they have not discovered any easy means to craft an input that will collide with a given hash. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: "Bob McConnell" on 24 Aug 2010 10:02
From: Peter Lind > On 24 August 2010 15:43, Gary <php-general(a)garydjones.name> wrote: >> Jan G.B. wrote: >> >>> The weakness of MD5 is mainly because MD5 collisions are possible. >>> That means, that different strings can have the same MD5-hash... >> >> http://en.wikipedia.org/wiki/MD5#cite_note-1 > > It's worth noting that that essentially does not touch upon whether or > not MD5 can be considered safe or not as a means to store password > information. The researchers have discovered ways of crafting inputs > to easily find colliding hashes - they have not discovered any easy > means to craft an input that will collide with a given hash. That's a simple matter of brute force, which can be done once and saved for instant use later. However, putting a salt into your algorithm pretty much eliminates the chances of success using that attack. Bob McConnell |