User Authentication

I have a site hosted on a Linux / Apache platform and will be password-protecting an area of the site. I have been contemplating doing this with HTTP Basic Authentication. I read some information on the web that stated that when using HTTP Authentication, username and password are transmitted unencrypted across the web, which seems to defeat the whole purpose of the password-protection, except when dealing with users that are non-malicious, or malicious, but inept. Is there a way to implement HTTP Basic Authentication in conjunction with SSI so that username and password are encrypted for transmission?

Do you mean SSL? If so, yes. If SSL is implemented, EVERYTHING (including HTTP Basic Auth usernames and passwords) will be encrypted.

yes, a user's credentials entered after a 401 browser challenge (which brings up the standard browser dialog box asking for username and password) will be passed in the header request as essentially clear-text. Like this:

Authorization: Basic hu748dlAG837842BZzU==

Don't be fooled that the usernameassword string (which is what the junk text represents) is encrypted... it's not. It's in base64 format, so that anyone can easily decrypt it.


===========================================
http://badblue.com/helpphp.htm
Free small footprint web server for Windows
PHP, P2P file-sharing, transcoding and more
===========================================

Rod K,

Yes, you're right of course, I did mean SSL. The thing is, I don't want to put everything behind SSL due to the performance penalty and other issues, I would like to just authenticate the user in that fashion and then have them go back to a regular HHTP connection to continue browsing the site.

ame12,

That kind of defeats the purpose then, doesn't it?

>> I don't want to put everything behind SSL due to the performance penalty and other issues

What performance penalty? What other issues? In 5 years or so, http will be gone, just https that is left.

Look into the method used by PHPLib for handling this very issue without SSL. They use MD5 and a randomly generated key value to create a hash value to be returned from the client to the server. The Password is never sent as clear text.

That's nothing be a horrible hack.

Since no decryption is done server side, all a sniffer would have to do is send what they sniff. I.E. the md5 hash

True a sniffer could get the hash, but the key which is randomly generated, passed to the login page to be used in the MD5 hash generation, is only valid for the current session. Even if a sniffer had all that information, it is only valid for the session that was in progress, unless I'm missing something here.

If i was to the pass the session via a url
example
https://secutesite.com/mysite/index.php$session_id$

Will it be encrypted using SSL
or am I better off the to post the session id via a form ?

Just an FYI.. yes there is a huge performance penalty for implementing SSL (20X on some systems). That's why there's a great business in selling hardware crypto accelerators.

Regarding MD5... depends upon the implementation, but usually MD5 is susceptible to sniffing because it is a flat hash that is compared with the server's version of the same credentials.

Not entirely secure in most cases...


===========================================
http://badblue.com/helpphp.htm
Free small footprint web server for Windows
PHP, P2P file-sharing, transcoding and more
===========================================

>> yes there is a huge performance penalty for implementing SSL (20X on some systems)

Wrong. The performance difference is minimal. There is no reason not to implement SSL for such situation.

>> That's why there's a great business in selling hardware crypto accelerators

This statement doesn't support the performance penalty of SSL.

>>> The performance difference is minimal. There is no reason not to implement SSL for such situation.

Y'know I did a search and... you appear to be absolutely correct in this statement. I've got to back to my IT department and figure out why they are buying these SSL hardware accelerators. The reason they were buying these is - they told me - 10x or 20x delays in SSL... but having done a search I found that typically delays are 22%... not 20x.

Research paper here:
http://www.cs.nyu.edu/artg/research...comparison.html

Thanks for the heads up


===========================================
http://badblue.com/helpphp.htm
Free small footprint web server for Windows
PHP, P2P file-sharing, transcoding and more
===========================================

Not to mention 20%, even 30% is reasonable. 20x is just way too non-sense. Getting better hardware would also make the difference less significant, maybe just 5%.

Everyone's input is greatly appreciated, but is there any consensus on this subject: how to implement a secure form of user authentication? I didn't realize this was going to be uncharted territory. I mentioned a performance penalty with SSL becuase that is what I had heard. My site is already taking aperformance hit because I am using a single PHP template as the basis for the entire site and using includes to incorporate the content for individual pages, so if there is a performance penalty with SSL I think the combination would cripple the site. At this point, the option that seems to be most viable is to create a database of usernames and passwords, then have the user enter their username and password on a form that is submitted through a https connection. If the username and password checks out, place a cookie (that will expire after, say, a day) on their machine that will be checked for by all pages in the protected area of the site. A couple of questions about that approach...how safe would my database be on the server? I actually don't even know where the database is located, I have a virtual hosting account and just connect to the database with a datasource name. Also, I apparently get just one database, so I would be putting various tables in the same database that are not related to each other , such as a table storing usernames / passwords, a table containing a membership directory for the organization, etc. Is that a good idea in general / in this context? Any advice appreciated.

i have a question. is the security issue more on the server or client side? if the issue is with server side snooping then my suggestion below will not be valid, if the issue is more on the client side then...

why not authenticate on an alternative port? would you guess to snoop on port 1603? (this is an example port number ) a redirect could then take you to the approriate page back on the http port.

i would be interested to hear what others think to this approach.

cheers - robert.