0

I have a cache library that stores cached data in normal php files, with the data stored in arrays.

An example of a cache file:

cache_userID.php:

$userCache['userID']=2354654654;
$userCache['userName']=foo;
$userCache['userPass']=salted-and-hashed-pass;

It works like a charm. So I'm thinking of using it to store user data (like the above example) to save DB querying. I've already tested it, and it does result in a noticeably faster page load time then fetching from the DB (which is why I want to do it).

I'm not sure if this is really safe though. The password and other sensitive information is salted and hashed. Would it be possible for anyone to be able to steal this data? With the exception of if they had the FTP details to access the source code (which won't be the case).

German Rumm
  • 5,782
  • 1
  • 25
  • 30

3 Answers3

9

No!

Every extra place you store a password (or password hash which is still sensitive) is another place that they can leak from. This is one of the reasons why SSL pages are not cached: because sensitive information should not be cached.

Good authentication code (like the sort you find in SSH) even goes to the effort of marking the memory region in which the password is stored as unswappable so it can't be written to disk by the operating system.

The risk of sensitive data leaking from this cache may be low but by doing this you have increased the risk. By placing this data in a local PHP file, it can now be accessed by any local file inclusion vulnerability. It may take more than just the local file inclusion to actually echo the passwords out to the screen. Before this cache existed, an SQL injection vulnerability or a complete server compromise was probably required to even access the password hashes, now those and local file inclusion can access the hashes.

It is fine to store other, less sensitive data in multiple places to improve page load speeds but passwords and password hashes should be off limits.

You can avoid having to calculate and look up the password hash on every page load for authenticated users by storing an authentication token. This should be randomly generated (so it's difficult to predict) at login time and should be short-lived. This is exactly what a PHP session ID is and it is perfectly adequate to verify that your users are properly authenticated after the first check where you compare passwords.

It just occurred to me that if you are querying the database and calculating the password hash on every page load, you must have stored the password (or potentially password hash) with the client somewhere, probably in the cookie and this sensitive data is being sent over the internet for every page request. This is bad practice in general and will result in the password (or password hash) being saved on the user's hard drive and potentially intermediate proxies unless you are using SSL for every page.

P.S.

I'm curious why including a local file is noticeably faster than what should be a simple key-value lookup from your database. My guess is you either have horrendous latency on your network or contention on your users table. Either one really needs fixing.

Ladadadada
  • 508
  • 3
  • 15
3

Security-wise: as long as your cache files aren't in a www-accessible location then it should be secure enough (assuming your code has no flaws!). Don't rely on PHP tags hiding your content... the engine can fail and expose this data (although it is rare, it DOES happen).

Performance-wise: Do you really need ALL the data of a user, every time you want to know ANYTHING at all? I wonder why your database would be so slow. Have you set up proper indexes etc.? Probably worth looking into that instead.

rjdown
  • 9,162
  • 3
  • 32
  • 45
  • *although it is rare, it DOES happen* - any sources? Never heard about such a problem except when it happened due to a misconfigured webserver. – ThiefMaster Jun 17 '12 at 14:24
  • 2
    Misconfiguration is the biggest issue. Also if he doesn't name them correctly (e.g. user.cache, user.inc or suchlike) then they are vulnerable. Older versions of php-cgi and mod_php have plenty of exploits that will cause them to fail. You should ensure you protect against this in your apache config, something like http://stackoverflow.com/a/3703496/1301076 – rjdown Jun 17 '12 at 14:35
  • Your answer seems to start by saying "It should be fine" and then goes on to explain why it's not fine at all. – Ladadadada Jun 17 '12 at 14:47
  • I really meant the first paragraph, not the second. – Ladadadada Jun 17 '12 at 15:09
2

As long as the file contains <?php the data will be safe as users cannot see PHP sourcecode unless they have FTP access or there is a security hole allowing them to read arbitrary files.

However, you should protect your cache folder either by moving it outside the document root or blocking any http access to it via the webserver config (e.g. a deny from all in your .htaccess) anyway.

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636