Page 1 of 1
Login script for directory
Posted: Thu Dec 15, 2005 9:52 am
by matthijs
There have been a few questions already on this topic, however I didn't find a satisfactory answer.
My problem is as follows:
I have a directory with some files I want to password protect. To do that there are a couple of options.
1- Using htaccess I can do somethink like:
Code: Select all
AuthName "MysiteLogin"
AuthType Basic
AuthUserFile /home/httpd/vhosts/mydomain.com/httpdocs/.htpasswd
Require valid-user
together with an htpasswd file in which I have the login and (encrypted) password.
2- I also could use some basic phpscript as outlined in this thread
viewtopic.php?t=41522
Code: Select all
<?
if($_SERVER['PHP_AUTH_USER'] == "William" && $_SERVER['PHP_AUTH_PW'] == "mypass") {
echo "You are now loggedin!";
} else {
header("WWW-Authenticate: Basic realm=\"".$login_text."\"");
header("HTTP/1.0 401 Unauthorized");
echo "Authorization Required.";
exit;
}
?>
3- Or use the
challenge-response system written by Maugrim_The_Reaper.
One of the files I want to protect is a script with which I can upload files to the server, so my quess is that it's pretty important to protect that file well. However, a simple to use system (like 1 or 2) has its advantages (not having to set up the db-tables, etc). So, what do you think would be the best option? And also, can a protection with a htaccess file be (relatively) easy Brute-force attacked?
Posted: Thu Dec 15, 2005 9:59 am
by onion2k
So long as you pick your password well there's no need to worry about brute force. I'd go with the first option. It's very secure. However.. the path in your .htaccess example looks like the .htpasswd file is inside the web root directory .. that gives teh h8x0rz an opportunity to steal the file. Put it outside of the web root.
Posted: Thu Dec 15, 2005 10:22 am
by matthijs
Thanks for the suggestion. So when is brute force possible then? Aren't md5 passwords already being looked up in libraries?
Off course, in this case I have the choice of making a strong password with many different ^%$rt_2435agg signs myself, instead of a random user picking his own 4 letter word.
And indeed the htpasswd file was in the same directory, hadn't thought about that. Thanks for the tip!
I like the first option with the htaccess files for it's simplicity. Just upload the htacces file to the directory, and done.
Posted: Thu Dec 15, 2005 11:20 am
by Maugrim_The_Reaper
Its true MD5 libraries are on the up and up, however in order to look up a collision you first need to know the MD5 hash you want a collision for...
First option would work perfectly for a shortlist of usernames/passwords.
Posted: Thu Dec 15, 2005 11:22 am
by onion2k
matthijs wrote:Thanks for the suggestion. So when is brute force possible then? Aren't md5 passwords already being looked up in libraries?
Anything can be brute forced given enough time. It'd be possible to craft a system that refuses someone's attempts after getting it wrong a few times in a row if you were really paranoid. In reality so long as you have a suitable password (8 or more characters, lots of different letters, numbers and symbols) then it'd simply take too long to crack to be worthwhile trying.
As for MD5 libraries .. yes there are a few in production .. but they're only any use if the hacker has a copy of your password's hash to look up in the library. Not relevant in this scenario. Besides, if you salt your passwords then a library is next to useless.
Posted: Thu Dec 15, 2005 3:54 pm
by matthijs
Thanks for the help and info. I learn a lot here

Posted: Fri Dec 16, 2005 4:22 am
by Maugrim_The_Reaper
Just keep asking questions...

Posted: Fri Dec 16, 2005 5:02 am
by shiflett
Regarding brute force, a good protection is to throttle your authentication form:
http://phpsecurity.org/code/ch07-2
This makes brute force attacks prohibitively time consuming. Relying on your users to create strong passwords is not my favorite approach, and this is also part of the reason why I've always salted my MD5s.
Posted: Fri Dec 16, 2005 6:18 am
by Maugrim_The_Reaper
Is it necessary to set a 15 second restricton though? I can quite easily with two fingers click the back button, type a second password attempt and submit - that's a 5 second process in most cases I can think of. Seems more likely to cause a useability problem... What about a sleep() somewhere as an alternative?
I rarely use salts in that way - the problem with an open source application is who sets the salt, and who pays the price when a user changes it by accident and wipes out all their user accounts from being validated.

That would be me inevitably...
I'm going to stop nitpicking now over code demonstrating a secure practice that can be done in several ways...
Posted: Fri Dec 16, 2005 7:42 am
by matthijs
Good points.
About the argument Maugrim brings forward on not wanting to use a salt in OS apps:
Most applications come with an installer. Wouldn't it be very easy to generate a random salt when running the install script for the first time? Then you write that salt, together with the password someone chooses to the database or a file? And then use that salt for the login system?
Something like:
Code: Select all
$salt = md5(uniqid(rand(), TRUE));
(didn't make that up myself Chris

Posted: Fri Dec 16, 2005 10:36 am
by shiflett
Maugrim_The_Reaper wrote:Is it necessary to set a 15 second restricton though?
Nope, most examples in the book err on the side of security, and the first chapter mentions that there is often a balance to be made between security and usability (they're not mutually exclusive, but it can seem that way sometimes). The lowest limit I would suggest is somewhere around 3 seconds.
Of course, it all depends upon how you present it. Never underestimate the value of friendly error messages. "Whoa, slow down!" :-)