User Authentication

Evil Phil

This may belong somewhere else. Anyway I'm developing an HTML editor for websites. Kinda like the ones you'd get with a geocities account (if you remember them). It's for Apache servers running on Linux/Unix.

Would using the .htaccess and .htpasswd files to authenticate users be a good idea or is this considered weak security? If its weak what would be a good method?

Baz_

you might try linking another post from security to here, ecksor would probably know but i dont think he leaves security much.

Static

Is this for work? Is the stuff being protected very sensitive? Who's accessing the material? It depends 8)

Evil Phil

It's an online editing tool for websites. So yeah, the information could be sensitive but its more likely to be John Q Public's home page (complete with pictures of the dog) hosted for free.

dahamsta

Hi Phil,

This may belong somewhere else. Anyway I'm developing an HTML editor for websites. Kinda like the ones you'd get with a geocities account (if you remember them). It's for Apache servers running on Linux/Unix. Would using the .htaccess and .htpasswd files to authenticate users be a good idea or is this considered weak security? If its weak what would be a good method?

It's not weak, it's just problematical. An example is a client of mine, who has lots of dumbass AOL users come into his site. When presented with the HTTP-AUTH dialog box, they panic, probably because they've never been faced with one before. Forms-based auth is easier in this instance, because you can link to help files, and a "forgot your password" utility. With HTTP-AUTH, you usually don't link to that information until /after/ they've screwed up, and dumbass AOL users don't get that far.

It really depends on the level of complexity of the site and that, but you're usually better off going with a forms-based approach IMHO.

adam

Baz_

ROFL, I can see dahamsta has some problems with a certain demographic of the internet.

5<r3|/\| Y0u A0|_ |_005Ar5!!!!

dahamsta

That's not to say /all/ AOL users are lusers. Just a large proportion of them...

adam

ecksor

For a proper answer, you need to answer static's question, but I'll make a few suggestions.

Firstly, strictly speaking, this is weak authentication, because it's password based. If you have a lot of users, you will have poor password management, you will have easy to guess passwords, and all the other associated problems with passwords. Apache can do other auth schemes such as SSL with client certs and kerberos, but the unfortunate fact is that your users will probably not want to use them (and deploying and managing keys properly is expensive). The solution to that depends on how much you are willing to spend and how much control you have over the infrastructure. (In both cases that's probably "not much", and the cost/benefit of doing it is probably not much either). An interesting exercise for you might be to compare your security needs to the needs of something like boards.ie, and then try to find out how often it occurs that a user's password is compromised.

Nextly, the proper solution depends on what you're protecting and from whom? My assumption (which is basically backed up by your post) is that the data being uploaded is not sensitive, as you will end up serving it to the public via the web anyway, so the main thing to concentrate on protecting is the authentication details (the password).

The password can be exposed in a few places, firstly, as Ronin mentioned on the security board, it's hash is stored in a .htpasswd (or whatever you want to name it) file on the server. In most configurations this will mean that other local users can read it and therefore start cracking the hash. Bear in mind that if you allow code to be uploaded which executes as the webserver user, then this can also be used to read the hash. (Of course, if you allow code to be uploaded, then that is probably the least of your difficulties ).

It can also be exposed as it travels across the internet, as basic authentication does send it in clear text. Digest authentication mitigates this, but not all browsers support it. You might want to check out which ones do and decide if this option is acceptable. Be careful about how you allow users to change your passwords if this is of particular concern (perhaps across ssl to prevent casual eavesdropping).

None of this is perfect, but it's probably good enough for what you're protecting (this is a management decision that should be based on a risk assessment).

If you want to get away from the dialog box to protect against that "AOL effect", then David Wheeler suggests a scheme using cookies at http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html

There is an interesting paper on the subject at of web authentication at http://cookies.lcs.mit.edu/pubs/webauth.html

(A good thing to note about that paper is the classification of different adversaries. A lot of what I discuss above doesn't defend against what they call "active adversaries", and I have deliberately ignored the possibility of the "eavesdropping adversary" for all but attacks against the password data).

dahamsta

Interesting links ecksor, thanks for them. You forgot to mention the "inadvertant adversary" by the way - the user who picks up someone's session in an Internet Café for example?

adam

ecksor

I didn't mention a lot of things. David Wheeler's scheme does suggest that you always give the user an option to end the session. After that, there isn't much you can do if the user is just going to hand control over to someone. You can't really adequately protect someone if their workstation isn't trusted either (which could be the case in a net cafe) unless you use smartcard based authentication against a stored cert or something separate to compute one time passwords (and even then the current session can be hijacked). As with previously mentioned PKI solutions, this is expensive to deploy and maintain.

Evil Phil

thanks for the info guys