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.
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.