By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,304 Members | 3,174 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,304 IT Pros & Developers. It's quick & easy.

Authentication, https and security.

P: n/a
I'm currently authenticating a site I have built using basic http
authentication built into apache. This has zero overhead on php which is a
bonus but it seems to not quite work how I'd like.

Are the username and password in the login box that comes up encrypted?
When I login https://mysite.local:portnum I get the login dialog. As I am
using a self signed certificate I see the dialog stating warning me about
it first before the login box. All is good. However, when I swap http for
https I do not get the security certificate warning, as expected. I still
get the login box which I assume is not encrypted. Not good as the user
and password must have been sent plaintext.

If this is the case, for greater programmig overhead I could ensure that a
php header on all my files delt with access control via http. But what do
I do for images and other non php files?

Any ideas?

Pete
--
http://www.petezilla.co.uk
Aug 16 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
*** Peter Chant wrote/escribió (Tue, 16 Aug 2005 19:52:27 +0100):
Are the username and password in the login box that comes up encrypted?
Try the Live HTTP Headers extension for Mozilla/Firefox. You'll see that
user and password are sent as plain text within headers on every page
request. Which, BTW, is the case of most authentication systems.

When I login https://mysite.local:portnum I get the login dialog. As I am
using a self signed certificate I see the dialog stating warning me about
it first before the login box. All is good. However, when I swap http for
https I do not get the security certificate warning, as expected. I still
get the login box which I assume is not encrypted. Not good as the user
and password must have been sent plaintext.


Make sure all page contents are encrypted. To all effects,
https://www.example.com/ and http://www.example.com/submit.png belong to
different web sites.

--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--
Aug 17 '05 #2

P: n/a
Alvaro G Vicario wrote:
*** Peter Chant wrote/escribió (Tue, 16 Aug 2005 19:52:27 +0100):
Are the username and password in the login box that comes up encrypted?
Try the Live HTTP Headers extension for Mozilla/Firefox. You'll see that
user and password are sent as plain text within headers on every page
request. Which, BTW, is the case of most authentication systems.


Even when using https?

Make sure all page contents are encrypted. To all effects,
https://www.example.com/ and http://www.example.com/submit.png belong to
different web sites.


Yes, but I used https://www.example.com:4430 as I was running the server on
port 4430 and I still got the password dialog box when I tried
http://www.example.com:4430 leading me to think that in both cases
authentication was not password protected.
Pete

--
http://www.petezilla.co.uk
Aug 18 '05 #3

P: n/a
*** Peter Chant wrote/escribió (Thu, 18 Aug 2005 08:05:29 +0100):
Are the username and password in the login box that comes up encrypted?


Try the Live HTTP Headers extension for Mozilla/Firefox. You'll see that
user and password are sent as plain text within headers on every page
request. Which, BTW, is the case of most authentication systems.


Even when using https?


HTTPS in only HTTP over SSL. It's a protocol to encrypt HTTP
communications: the underlying HTTP, *once decrypted*, remains the same.

I just meant that, if you're concerned about the security of HTTP
authentication (and you have good reasons to), using HTTPS is a very good
idea.
Make sure all page contents are encrypted. To all effects,
https://www.example.com/ and http://www.example.com/submit.png belong to
different web sites.


Yes, but I used https://www.example.com:4430 as I was running the server on
port 4430 and I still got the password dialog box when I tried
http://www.example.com:4430 leading me to think that in both cases
authentication was not password protected.


I'm not sure about your exact problem but if your form is processed under
HTTPS, it doesn't matter that the form itself is not encrypted.

:-?
--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--
Aug 18 '05 #4

P: n/a
I just meant that, if you're concerned about the security of HTTP
authentication (and you have good reasons to), using HTTPS is a very good
idea.


I think we are talking slightly at cross purposes. Yes I am concerned about
http authentication.

My question is, if using HTTPS is the authentication encrypted?

Pete

--
http://www.petezilla.co.uk
Aug 18 '05 #5

P: n/a
Peter Chant wrote:
I just meant that, if you're concerned about the security of HTTP
authentication (and you have good reasons to), using HTTPS is a very good
idea.


I think we are talking slightly at cross purposes. Yes I am concerned
about http authentication.

My question is, if using HTTPS is the authentication encrypted?

Pete


yes.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Aug 19 '05 #6

P: n/a
In article <4k************@pluto.downsfam.net>,
Kenneth Downs <kn**************@see.sigblock> wrote:
Peter Chant wrote:
I just meant that, if you're concerned about the security of HTTP
authentication (and you have good reasons to), using HTTPS is a very good
idea.


I think we are talking slightly at cross purposes. Yes I am concerned
about http authentication.

My question is, if using HTTPS is the authentication encrypted?

Pete


yes.


OK, why does Internet Explorer 6 complain that "Some of the parts of
this page aren't secure and some are" when I present a form on a page.
I tried explaining this to someone but they decided to mail in the
printed PDF with a check instead.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Aug 19 '05 #7

P: n/a
Michael Vilain (vi****@spamcop.net) wrote:
: In article <4k************@pluto.downsfam.net>,
: Kenneth Downs <kn**************@see.sigblock> wrote:

: > Peter Chant wrote:
: >
: > >
: > >> I just meant that, if you're concerned about the security of HTTP
: > >> authentication (and you have good reasons to), using HTTPS is a very good
: > >> idea.
: > >
: > > I think we are talking slightly at cross purposes. Yes I am concerned
: > > about http authentication.
: > >
: > > My question is, if using HTTPS is the authentication encrypted?
: > >
: > > Pete
: > >
: > >
: > >
: >
: > yes.

: OK, why does Internet Explorer 6 complain that "Some of the parts of
: this page aren't secure and some are" when I present a form on a page.
: I tried explaining this to someone but they decided to mail in the
: printed PDF with a check instead.

Your page refers to something that is accessed but not via https: such as
an image, e.g. src="http://my.server.com/images/whatever.gif". The image
is a non-secure part of the page.

--

This space not for rent.
Aug 19 '05 #8

P: n/a
In article <43******@news.victoria.tc.ca>,
yf***@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
Michael Vilain (vi****@spamcop.net) wrote:
: In article <4k************@pluto.downsfam.net>,
: Kenneth Downs <kn**************@see.sigblock> wrote:

: > Peter Chant wrote:
: >
: > >
: > >> I just meant that, if you're concerned about the security of HTTP
: > >> authentication (and you have good reasons to), using HTTPS is a very
: > >> good
: > >> idea.
: > >
: > > I think we are talking slightly at cross purposes. Yes I am concerned
: > > about http authentication.
: > >
: > > My question is, if using HTTPS is the authentication encrypted?
: > >
: > > Pete
: > >
: > >
: > >
: >
: > yes.

: OK, why does Internet Explorer 6 complain that "Some of the parts of
: this page aren't secure and some are" when I present a form on a page.
: I tried explaining this to someone but they decided to mail in the
: printed PDF with a check instead.

Your page refers to something that is accessed but not via https: such as
an image, e.g. src="http://my.server.com/images/whatever.gif". The image
is a non-secure part of the page.

--

This space not for rent.


Great. Thanks. I'll fix that and things should be OK then.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Aug 19 '05 #9

P: n/a
Kenneth Downs wrote:

My question is, if using HTTPS is the authentication encrypted?
yes.


I think what spooked me was this. I am running on a non-standard port.
When I accidentally use http rather than https to connect to the port I get
back a non-encrypted error message telling me so. However, I still have to
log in to see it. I presume this log in is not unencrypted. I wonder if
there is way to stop this, or to not require log in to see the error
message?

Pete

--
http://www.petezilla.co.uk
Aug 19 '05 #10

P: n/a
>OK, why does Internet Explorer 6 complain that "Some of the parts of
this page aren't secure and some are" when I present a form on a page.
I tried explaining this to someone but they decided to mail in the
printed PDF with a check instead.


Are *ALL* parts of the page https: ? The images included? The
banner ads included?

I don't have IE6, but in firefox, if you look at Tools | Page Info | Media,
you can see the parts of the page being shown. Look for any
not https: .

Gordon L. Burditt
Aug 19 '05 #11

P: n/a
>>> My question is, if using HTTPS is the authentication encrypted?
yes.


I think what spooked me was this. I am running on a non-standard port.
When I accidentally use http rather than https to connect to the port I get
back a non-encrypted error message telling me so. However, I still have to
log in to see it. I presume this log in is not unencrypted. I wonder if
there is way to stop this, or to not require log in to see the error
message?


The page you fill in your login information should be https: . It's
not good enough that the page returned after you press the Log In
button is https: . There seem to be quite a few e-commerce sites
that make this mistake.

Gordon L. Burditt
Aug 19 '05 #12

P: n/a
Gordon Burditt wrote:
The page you fill in your login information should be https: . It's
not good enough that the page returned after you press the Log In
button is https: . There seem to be quite a few e-commerce sites
that make this mistake.


Gordon,

I'm not actually using PHP for authentication, rather basic authentication
via Apache. That way both my php and anything else like documents and
images are dealt with by apache. However, if I errounously log in with
http to the port, it seems that the username and password dialog passes the
information unencrypted.

I could get around this for the php by doing the authentication via php.
However, for the documents and images its harder. I would imagine I would
have to store them outside server root and serve them up via php,
outputting valid mime types on the way. A pain compared to just using
basic authentication on Apache.
Pete

--
http://www.petezilla.co.uk
Aug 19 '05 #13

P: n/a
>> The page you fill in your login information should be https: . It's
not good enough that the page returned after you press the Log In
button is https: . There seem to be quite a few e-commerce sites
that make this mistake.
Gordon,

I'm not actually using PHP for authentication, rather basic authentication
via Apache.


It doesn't matter. If you send it via http, it's not encrypted.
That way both my php and anything else like documents and
images are dealt with by apache. However, if I errounously log in with
http to the port, it seems that the username and password dialog passes the
information unencrypted.
There are a few ways to fix this problem:

(1) Don't even *HAVE* a http server. https only. The browser won't
send login information to a site it can't connect to.

(2) Ok, you can have a http server, but all it should do is send
redirects to the https server. This is much more convenient and
less confusing for users than (1). Or you can have a http
server, but it sends redirects to https for the portion of the
tree that's supposed to be secure.

(3) Don't have any documents on the http server that are supposed
to be on the https server. If you accidently try to connect to the
http server when you meant the https server, you should get a 404
error or a redirect to https. Login information isn't sent by
the browser for pages that don't exist.

Make sure you have absolutely NO http links that should be https
links. For http links that have made their way into search engines,
set up redirects to https. Use a different authentication realm
(which makes the browser ask for a *different* username/password)
and a different set of passwords for the http site as for the https
site. Preferably you let *NO ONE* into the http site.

You aren't using the same document root for http and https are you? Don't.
I could get around this for the php by doing the authentication via php.
However, for the documents and images its harder. I would imagine I would
have to store them outside server root and serve them up via php,
outputting valid mime types on the way. A pain compared to just using
basic authentication on Apache.


Gordon L. Burditt
Aug 19 '05 #14

P: n/a
Gordon Burditt wrote:
The page you fill in your login information should be https: . It's
not good enough that the page returned after you press the Log In
button is https: . There seem to be quite a few e-commerce sites
that make this mistake.
Gordon,

I'm not actually using PHP for authentication, rather basic authentication
via Apache.


It doesn't matter. If you send it via http, it's not encrypted.
That way both my php and anything else like documents and
images are dealt with by apache. However, if I errounously log in with
http to the port, it seems that the username and password dialog passes
the information unencrypted.


There are a few ways to fix this problem:

(1) Don't even *HAVE* a http server. https only. The browser won't
send login information to a site it can't connect to.


I have not got a http server. However, as I am running https on a
non-standard port it is easy to accidentally specify http instead of https.
The https server then respondeds by giving an error message, but not before
asking the user to log on, which I would assume is an unencrypted log on.
(2) Ok, you can have a http server, but all it should do is send
redirects to the https server. This is much more convenient and
less confusing for users than (1). Or you can have a http
server, but it sends redirects to https for the portion of the
tree that's supposed to be secure.
I have not!
(3) Don't have any documents on the http server that are supposed
to be on the https server. If you accidently try to connect to the
http server when you meant the https server, you should get a 404
error or a redirect to https. Login information isn't sent by
the browser for pages that don't exist.

I have no documents on the http server, I'm not running one.
Make sure you have absolutely NO http links that should be https
links. For http links that have made their way into search engines,
set up redirects to https. Use a different authentication realm
(which makes the browser ask for a *different* username/password)
and a different set of passwords for the http site as for the https
site. Preferably you let *NO ONE* into the http site.

You aren't using the same document root for http and https are you?
Don't.

No.
--
http://www.petezilla.co.uk
Aug 21 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.