members area login

[Gerrit]

For a project I will start working on soon, I'm going to need a members area on a website.
The client expects at least 1,000 members, it could grow to 5,000.
I have been thinking of using .htaccess/.htpasswds for storing the usernames/passwords.
The members will have to be entered manually after screening and approval

Are there any disadvantages by using the .htaccess method? Are there limits to the .htpasswds files? Is a big password file slowing down the login and/or loading of pages?
Would a PHP/MySQL login script be easier/faster?

Any thoughts would be be appreciated - this is a new area for me. :)

[Pauly]

Moved to correct forum. Apologies but I haven't a clue, I'm just a designer :lol:

[Tyler]

I think .htaccess/.htpasswds can be hacked much easier then PHP if done correctly. Personally, I would go for the PHP/MySQL approach :)

[the_pm]

PHP/MySQL with the MD5 hash would be most appropriate (or double hash, salted, if you're paranoid). .htaccess/.htpasswd works just fine, and you most likely never have any problems with people hacking in, particularly if usernames are not published, which essentially means you have a double-key system (you have to crack both the username and the password).

I'm not the programming type myself, but I have to believe this is so common, you can probably get just about any PHP programmer to fork over the markup they're keeping in their snippets library. :)

[Dan]

md5'ing an md5 is a little redundant--if someone has access to your database that shouldn't, encryption should be the least of your worries :)

htaccess won't really do for this situation, IMHO, since you'd be manually adding to the file. And if you have a script adding to it, you'd be better off just using a straight PHP system.

The only benefit to htaccess is that it protects an entire directory, whereas php only protects the script that is running.

[BigBison]

Begging to differ. HTTP offers both basic and digest authentication, with digest being preferred. Either of these solutions makes use of the proper HTTP AUTH headers to determine who's logged in, rather than storing it in a cookie like this site:

Cookie bbsessionhash=925c4a3d6e1b30835ff13198de54c270;
bblastvisit=1145338545; bblastactivity=0; bbuserid=##;
bbpassword=55bdd1cbc510940ab475f26d8a106d3b

That's called "storing state on the client" and the real downside to this is that if you use it you give up the ability to cache, which is why this site also sets a pragma:nocache header. If your login status is stored in an AUTH header not a cookie, you can use HTTP caching. So directory-level protection is hardly the only benefit to using .htaccess-based authentication.

Tyler, I think your assumption is a bit off. I've heard of countless, innumerable instances of PHP scripts being hacked, yet I've not heard of a single properly-implemented HTTP digest-authentication site being hacked. Why reinvent the security wheel, when you can leave it up to your httpd?

[jos]

I have no knowledge about .htaccess, BUT if you have 1000-5000 users that all need their own username/password I would definitly advise a PHP/MySQL Login script.

Tons of these scripts on the web (good ones too) and users can register themselves (if you code it that way) If you're going to google for this make sure you google for 'secure login script' or something like this. Those ussually have protection to alot of 'php hacks'

[BigBison]

2006-04-25: Google, HP, IBM, KDE, Microsoft, Mozilla, Nokia, Opera, Sun Microsystems, VeriSign, Yahoo! and many other W3C Members and research organizations gathered with leaders of the online finance community in New York City, USA, to address pressing Web security issues at the March 2006 W3C Workshop on "Usability and Transparency of Web Authentication." The Workshop report, including suggested next steps, is now available. W3C thanks Citigroup for hosting and Cisco for network services.

http://www.w3.org/News/2006#item73
http://www.w3.org/2005/Security/usability-ws/report

[BigBison]

Have you ever gone to a site which requires you to re-authenticate each time you go into a different directory? My desktop wireless AP does that, I'm not authenticating into a session where I can do anything, it asks me to authenticate each step of the way which is an unnecessary bother.

This first article explains how to implement HTTP authentication properly in a way which works site-wide, so that when a user is logged in to a members-only area the web application can still access their AUTH header for public areas of the site:

http://www.berenddeboer.net/rest/authentication.html

This way public pages may be personalized for individual logged-in users without using cookies, such that the same common page is cached by everyone, logged in or not.

This next article explains how to use XmlHttpRequest() to implement HTTP authentication without the user seeing the popup login dialog box, provided they have JavaScript enabled:

http://www.peej.co.uk/articles/http-auth-with-html-forms.html

It's interesting, but I'm not sure that the downsides aren't worse than just displaying the awful-looking browser popup login dialog.

[BigBison]

Using cookies for authentication is also bad in terms of machine-readability, and therefore accessibility. Elliotte Harold explains:

...

You see, feed readers like NetNewsWire and Vienna don’t support these non-standard logins. In fact, no software does. Because every login page that uses cookies requires a different form, there’s no standard way to ask the browser or any other client for the user name and password. A human has to read the site and figure out where to put the username and password. Yes, there are a few standard form element names that can help autofill tools figure this out, but a person still has to navigate to the right page.

This works as long as browsing is the metaphor. However it falls apart as soon as we move to non-browser tools such as feed readers. Standard HTTP authentication does work in most major feed readers. However cookie based authentication doesn’t. Even if the feed reader knows how to handle cookies, there’s no way for it to login to the website in the first place to get the necessary cookie. It can ask the user for the username and password, but it can;t figure out where (i.e. on which other page) to submit this to the server.

The only user authentication that works for feed readers and any other non-browser, automated client is HTTP authentication. HTTP authentication is completely standard. The challenge comes from the page being authenticated, not from some other page somewhere else on the web site. The feed readers know exactly how to recognize and respond to a request for credentials because every site does it exactly the same way. (OK, that’s not quite true. There are actually three or four different ways; but they’re all related, all standardized, and all easily recognized and handled by the HTTP libraries the feed readers use.)

Right now feed readers are a distinct minority of the audience, but that’s shifting. I only noticed this because I’m already receiving request for feeds from my Amazon blog within a few days of launching it. As feed readers grow in popularity and new uses continue to be found for them, more and more sites are going to need to provide not just feeds but password protected feeds; and the only way to do this reliably is by using HTTP authentication as it was designed: sessionless and no cookies.

http://cafe.elharo.com/web/why-cookies-are-bad-for-you-3/