RE: [PHP-DB] SQLite security

[Ed Lazor]

> Shared hosting vulnerabilities have nothing to do with SQLite security.
> phpMyAdmin seems to be a popular choice for MySQL admin and I reckon
> there must be a few people who use it in shared hosting situations.

Most of the shared hosting options I've seen lately list phpMyAdmin as one
of the benefits of going with their service...

-Ed

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DB] SQLite security

[Adam Q]

You can use Mcrypt, OpenSSL or any other crypographic provider to 
encrypt
the information however for your application to be able to access the
information you would also have to store the encryption key, reducing 
the
protection offered.
Any PHP MySQL connection script has the DB password in it somewhere so 
this is not an issue I think.
phpMyAdmin allows you to put the password into a config file...
But you can't download a MySQL database by typing in a URL.

I think encryption for SQLite is essential for PHP. It makes it almost 
useless in a webscripting language.
Suppose you wanted to create an open source, easily portable, file 
based guestbook in PHP. I would never use SQLLite under the current 
circumstances... Although I would love to. It seems like the perfect 
solution.

But the database needs a password otherwise it is just too much of 
a security risk.

SQLite is intended for applications that need a database but don't 
need a
full fledged solution such as PostgreSQL
I can't think of one (1) web based application where I would recommend 
SQLite - if I can't specify a password for access.
Maybe for PHP-GTK, but that is not web based (and PHP is used a great 
deal for web scripting).

Remember regardless of the database you use if you are using a shared
hosting provider it is possible othere hosting clients will be able to
access your database regardless of the engine you use.
Shared hosting vulnerabilities have nothing to do with SQLite security.
phpMyAdmin seems to be a popular choice for MySQL admin and I reckon 
there must be a few people who use it in shared hosting situations.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DB] SQLite security

[Jason Sheets]

SQLite security is based primarily on filesystem security, placing the
database outside the web root (i.e. /home/user/private/SQLITE.db instead of
/home/www/SQLITE.db) and including an option in your base configuration or
include file to point to the database file.

You can use Mcrypt, OpenSSL or any other crypographic provider to encrypt
the information however for your application to be able to access the
information you would also have to store the encryption key, reducing the
protection offered.

If I were you I'd follow the first approach, in my opinion the second
approach's overhead does not justify the minimal security gained.

SQLite is intended for applications that need a database but don't need a
full fledged solution such as PostgreSQL.

Remember regardless of the database you use if you are using a shared
hosting provider it is possible othere hosting clients will be able to
access your database regardless of the engine you use.

Jason

-Original Message-
From: Adam Q [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 16, 2004 7:34 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DB] SQLite security

I would like to use an SQLite DB for the prefs for an open source PHP
project, but I can't find any way to be sure the DB file is going to be
secure... Is it possible to encrypt a SQLite DB file?

With the current setup, if I include a .htaccess for the DB dir, this will
only work for Apache - not IIS.
I know I can include a warning about how important it is to place the files
outside the HTTP directory tree and .htaccess files are good, but it is just
too easy to download an SQLite DB... I can't really see any PHP use that
would be OK for this really.
if I put the db file "SQLITE.DB" into /www/db Anybody can d/l it by typing
http://myserver.com/db/SQLITE.DB

I though I might even be able to prevent d/l by naming the DB file with a
"." at the start but it makes do difference.

... and if the project is open source it is just too much of a security risk
as everybody knows where the file is going to be on a default installation.

Otherwise I'm stuck with the standard PHP prefs file "confing.inc.php" 
(- which is safe from prying eyes):


But updating this on pref changes is no fun compared to SQLite



Please somebody tell me I'm wrong,
Cheers,
Adam

--
PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php