views:

55

answers:

4

Hello, I'm thinking about storing list of passwords for users (eventually more info about them) of small-scale (max. 20 users) app in PHP file in directory like public_html_root/system/config/

<?php if($calledByApp !== true) die();
  $pwds['username1'] = 'hispassword';
  $pwds['username2'] = 'herpassword';
  $pwds['username3'] = 'anotheroned';
?>

Now. hispassword is actually hashed version

$hashedpasword = sha1($password.sha1($salt));

This way, if file is included, it checks for $calledByApp, which is set upon starting from entry point - i.e. index.php in root, so we could say it's safe this way. If it's called directly from browser - it won't get served as text file, but rather as PHP file - and it will die also, since $calledByApp will return null or false.

Also, if another user is stored/deleted, the file gets rebuilt, so it reflects all users. And after including this file, we have all users in pretty array, so if we call

if (is_string($pwds[$sanitized_username]) 
&& ($pwds[$sanitized_username] === $sanitized_sha1_userpassword))

we'll do login.

My question is: Is this safe enough?

Clarification: DB for users seems to be a bit overkill - another table for max 20 users. Also, while this doesn't check if user is real, it won't do anything with DB - looks like added security too.

A: 

It's always safer to store the encrypted passwords in a database.

If you are using a database then I would store user data in there. If not then I would look to start using one.

Lizard
Yeah, well, I should clarify, that it seems to be a bit overkill - another table for **max** 20 users. Also, while this doesn't check if user *is* real, it won't do anything with DB - looks like added security too.
Adam Kiss
@Adam you could use sqlite. It's pretty lightweight.
Gordon
@Gordon - am I not screwed if no SQLite on server?
Adam Kiss
@Adam well, yes, you cannot use it then. But it's not like you *have* to use it anyway. I just wanted to suggest one that you wouldn't have to be concerned about being overkill, since it's a flatfile anyway.
Gordon
@Gordon, yes, good suggestion. I'm just taking all possibilities to account :] And situation is, that I met with pretty strange and f*cked up hostings nowadays...
Adam Kiss
+5  A: 

If for some reason mod_php has a hiccup it could result in httpd showing the uninterpreted file; store the script outside of the document root in order to fix this.

Ignacio Vazquez-Abrams
Well, of course it won't be in root (e.g.`myapp.com/admin`), more like i wrote up there (edited v.)
Adam Kiss
+3  A: 

I would rather place that file outside of document root instead of relying on the PHP interpreter not failing for any reason.

kemp
Well, of course it won't be in root (e.g.`myapp.com/admin`), more like i wrote up there (edited v.)
Adam Kiss
I mean completely outside of the tree accessible from the web browser, not in a subdir of your root.
kemp
+1  A: 

No - this is a really bad idea.

By making your souce code files writeable you open a whole avenue for attacking your system. Embedding data into source code is a messy practice - not least because it will not scale. What happens if the file is locked for an update when a script tries to include it? What happens when the connection to the browser is lost part way through writing the file?

If you're quite sure that you'll only ever have a very small number of users and a low level of concurrency then abetter solution by far would be to have a seperate directory, with all http access denied, containing one file per user, named with the username (or a hash of it if you prefer) containing the hashed password.

C.

symcbean