Authentication Realm problem

Authentication Realm problem

Post by Michael Monge » Tue, 10 Mar 1998 04:00:00



I have two web servers running on an HP-UX server:
Apache 1.2.4 on port 80 and Lotus Domino 4.5 on port 81.
I have secure areas on both servers that use the same
authenticaion realm name.  

With MSIE 4.01 I am only prompted for a password once
and I'm able to get into both secure areas (this is
exactly what I want).

With NS 4.04 I'm prompted for a password twice: once
on the Apache secure area and once on the Domino
secure area.

I don't want users to have to enter their password twice.
Is there any way to disable that behavior for Netscape
browsers ?

Thanks,

Michael Mongeau
Stratus Computer Inc

 
 
 

Authentication Realm problem

Post by Marc Slemk » Tue, 10 Mar 1998 04:00:00



Quote:>I have two web servers running on an HP-UX server:
>Apache 1.2.4 on port 80 and Lotus Domino 4.5 on port 81.
>I have secure areas on both servers that use the same
>authenticaion realm name.  
>With MSIE 4.01 I am only prompted for a password once
>and I'm able to get into both secure areas (this is
>exactly what I want).

Then MSIE is _HORRIBLY_ broken and you should stop using it ASAP.

Quote:>With NS 4.04 I'm prompted for a password twice: once
>on the Apache secure area and once on the Domino
>secure area.
>I don't want users to have to enter their password twice.
>Is there any way to disable that behavior for Netscape
>browsers ?

Not AFAIK.  It is a serious security issue to allow that.

 
 
 

Authentication Realm problem

Post by DetlefEn » Wed, 11 Mar 1998 04:00:00


Hi,

It looks like you just found a bug in MSIE 4.01.

Detlef

 
 
 

Authentication Realm problem

Post by Bill Anderso » Thu, 12 Mar 1998 04:00:00




> >I have two web servers running on an HP-UX server:
> >Apache 1.2.4 on port 80 and Lotus Domino 4.5 on port 81.
> >I have secure areas on both servers that use the same
> >authenticaion realm name.

> >With MSIE 4.01 I am only prompted for a password once
> >and I'm able to get into both secure areas (this is
> >exactly what I want).

> Then MSIE is _HORRIBLY_ broken and you should stop using it ASAP.

WHy? It is following the procedure as he wants it!

Quote:> >With NS 4.04 I'm prompted for a password twice: once
> >on the Apache secure area and once on the Domino
> >secure area.

How are you implementing the authentication?

Quote:> >I don't want users to have to enter their password twice.
> >Is there any way to disable that behavior for Netscape
> >browsers ?

> Not AFAIK.  It is a serious security issue to allow that.

No it is not. He specifically stated he wanted users from either realm to have
access to the other. this is a simple trust relationship. He wants one server
to trust the other. While it is true that if someone gains access to one, he
has access to the other, it is also unavoidable in a trust arrangement.

--
Bill Anderson

"Pluralitas non est ponenda sine neccesitate."
Plurality should not be assumed without neccesity.

 
 
 

Authentication Realm problem

Post by Bill Anderso » Thu, 12 Mar 1998 04:00:00






> >> >I have two web servers running on an HP-UX server:
> >> >Apache 1.2.4 on port 80 and Lotus Domino 4.5 on port 81.
> >> >I have secure areas on both servers that use the same
> >> >authenticaion realm name.

> >> >With MSIE 4.01 I am only prompted for a password once
> >> >and I'm able to get into both secure areas (this is
> >> >exactly what I want).

> >> Then MSIE is _HORRIBLY_ broken and you should stop using it ASAP.

> >WHy? It is following the procedure as he wants it!

> I want the bank to give me 10 million dollars in exchange for my old
> snowshoes.

> Why would the bank be wrong to do that?  It is following the procedure
> as I want it.

Wow, a nonsensical argument ... imagine that.
What would be wrong with that? Banks don't buy snowshoes.
The analogy is not analagous.

- Show quoted text -

Quote:> >> >With NS 4.04 I'm prompted for a password twice: once
> >> >on the Apache secure area and once on the Domino
> >> >secure area.

> >How are you implementing the authentication?

> >> >I don't want users to have to enter their password twice.
> >> >Is there any way to disable that behavior for Netscape
> >> >browsers ?

> >> Not AFAIK.  It is a serious security issue to allow that.

> >No it is not. He specifically stated he wanted users from either realm to have
> >access to the other. this is a simple trust relationship. He wants one server
> >to trust the other. While it is true that if someone gains access to one, he
> >has access to the other, it is also unavoidable in a trust arrangement.

> No, the problem is what IE is doing by default.

> Consider any server at all with any user access to it.  Then
> someone can typically start their own server on another port.  Then
> all they have to do is convince the user to visit a page on that
> server, and they can steal the password information without the
> user even knowing.  It is even worse in IE if the user saves it to
> disk.

I don't know how you configure the machine you run a webserver on, but on mine,
just anyone can not start a webserver and run it on some port. If someone has
that kind of access to your machine, you have a bigger problem.

You also missed that he uses the same authentication for both. In order for the
rogue to authenticate him, it would need to access the authentication scheme.
How would they convince the user to access their page, on their port? Heck, for
that matter you could do the same on a completely different machine and
convince the user to go to your site instead. Then, either the browser will
remember the authentication, or the user will type it in. Either way you get
the user/pass pair.

Quote:> If IE provided a way for him to explicitly say that such things
> should be trusted, there is no problem with that.  The problem
> is that doing it by default is completely broken and a good enough
> reason to ban IE from accessing any site of mine that requires
> authentication for important information or using an important
> login/password pair.

Like I asked him, it depends upon what authentication scheme he is using.
Where can you configure NS to do such a thing?

The point is, there was not enough detail provided to determine what the cause
is, plain and simple. To blame a browser by default is a knee-jerk reaction, or
at least that is what it looks like. Knee-jerk browser wars serve no purpose.
It *may* be that NS is broken, it may be that the server is broken, it may be
that MSIE is broken, it may be his authentication scheme is broken.

--
Bill Anderson

"Pluralitas non est ponenda sine neccesitate."
Plurality should not be assumed without neccesity.

 
 
 

Authentication Realm problem

Post by Tom Hol » Thu, 12 Mar 1998 04:00:00




)
)I don't know how you configure the machine you run a webserver on, but on mine,
)just anyone can not start a webserver and run it on some port. If someone has
)that kind of access to your machine, you have a bigger problem.

Uh, shell access?  You think that web servers shouldn't allow shell access?

)You also missed that he uses the same authentication for both. In order for the
)rogue to authenticate him, it would need to access the authentication scheme.
)How would they convince the user to access their page, on their port?

Left as an exercise for the reader.  Suffice to say that I could get
probably hundreds of hits to a page if I were to put sufficiently
interesting stuff about it in this message.
 -Tom

 
 
 

Authentication Realm problem

Post by Bill Anderso » Thu, 12 Mar 1998 04:00:00



> >You also missed that he uses the same authentication for both. In order for the
> >rogue to authenticate him, it would need to access the authentication scheme.
> >How would they convince the user to access their page, on their port? Heck, for
> >that matter you could do the same on a completely different machine and
> >convince the user to go to your site instead. Then, either the browser will
> >remember the authentication, or the user will type it in. Either way you get
> >the user/pass pair.

> You are really missing the whole point of what is going on.  This
> isn't rocket science, and this sort of thing is defined in the standards
> regarding what proper behaviour is.

> You can't do the same thing with a different server because they have
> to enter the auth info _for that site_ because it has a different
> name.  Because of MSIE's broken support for realms, the client
> will _automatically_ send any cached auth info to a server running on
> a different port.  The user doesn't know it is happening.  The user
> doesn't enter anything.  The user can't stop it.  Any client worth
> anything will not just send off cached passwords to any server
> that asks for them.  That is a basic part of HTTP's basic authorization.

No, I fully know what is going on.
Actually, in IE when you are asked for authentication to a site, it also asks
if you want it to remeber the user/pass pair, so, no it is not the default.
Besides, Michael said "both servers use the same authentication realm" so it is
not a case of different info for a different server. On some of my servers I
have an authentication scheme similar to the one described, and Netscape
(4.04)does *not* challenge me when I go from one to the other.
Thus, depending upon how it was implemented, it is something in his
configuration that Netscape is not playing properly with. If mine under
Netscape works as his under IE, then if IE is broken, so is Netscrape. Much to
my dismay, Netscape's browsers fail to follow the standards as well as
Microslough's browser does.  Hopefully, once we get the source, we can fix that
problem.

- Show quoted text -

Quote:> (well, IE's broken Windows auth is a different matter but that is outside
> of this discussion)

> In many environments, the people accessing the secured information will
> have something in common and there will be a way to convince them to
> go visit an arbitrary URL.

> >> If IE provided a way for him to explicitly say that such things
> >> should be trusted, there is no problem with that.  The problem
> >> is that doing it by default is completely broken and a good enough
> >> reason to ban IE from accessing any site of mine that requires
> >> authentication for important information or using an important
> >> login/password pair.

> >Like I asked him, it depends upon what authentication scheme he is using.

> Erm... if you had read what he had written, there is no "choice" of
> authentication schemes in this case.  He provided more than enough
> information to know what he is using.

> >Where can you configure NS to do such a thing?

> Huh?  This sentence makes no sense.

The sentence make splenty of sense, your understanding of it may vary.
REPHRASE: where do you configure nutscrape to perform the same way?
After looking around in 4.04, I can't find anything like it.

Quote:> >The point is, there was not enough detail provided to determine what the cause
> >is, plain and simple. To blame a browser by default is a knee-jerk reaction, or
> >at least that is what it looks like. Knee-jerk browser wars serve no purpose.
> >It *may* be that NS is broken, it may be that the server is broken, it may be
> >that MSIE is broken, it may be his authentication scheme is broken.

> It may look like a knee-jerk response if you don't have a clue what
> is happening or how the web works.  I do.  I am blaming the
> client because it is broken, not "by default".

I have plenty of knowledge on how the web works. And you said it was broken
because it did it by default:

Quote:> No, the problem is what IE is doing by default.
...
> The problem
> is that doing it by default is completely broken

So, by  you did claim it is broken for a default action. In actuality, the
default is for it to ask you if you want it to 'remember' for you. What could
be described as broken is that there is no way, AFAIK, for it to be told to
'forget'. That is broken.

Apache has several schemes for authentication of a restricted website, from
simple .htaccess files and cookies to DBM hashes and SQL queries. It is a
matter of configuration. I do not know how many different ways a Domino server
has available to it. Given that, no there was no mention of *which* scheme he
implemented.

From the Apache docs:

Quote:> This directive enables or disables the generation of the Expires header for the document >realm in question. (That is, if found in an .htaccess file, for instance, it applies only to >documents generated from that directory.) If set to
> Off, no Expires header will be generated for any document in the realm (unless overridden at >a lower level, such as an .htaccess file overriding a server config file). If set to On, the >header will be added to served documents
> according to the criteria defined by the ExpiresByType and ExpiresDefault directives (q.v.).

> Note that this directive does not guarantee that an Expires header will be generated. If the >criteria aren't met, no header will be sent, and the effect will be as though this directive >wasn't even specified.

This is from the mod_expires Module, one that is not compiled in by default. By
default, Apache will send a realm name to the client. This tells the client
which user/pass pair to send back. MSIE is following the procedure when it
receives the realm name, and will send it *if it was told to remember it*. (And
BTW by default it is not chscked to rememebr it, you must check it yes.)

Just for kicks I implemented a cookie based authentication scheme on two of my
servers, seperate machines. I had the Site1  authenticate based on a cookie
sent from Server2.
Server2 sent the cookie for either site. After authenticating in *either* site,
I had to remove the cookie from my HD in order for NS4.04 to reauthenticate
after visiting the other site.  Granted this is a klude, but it demonstrates
something, namely that by default NS can do this as well. By default, NS will
accept cookies sent from a different server than the one the web page is on.
This is a default action I consider a bit less secure than it could be. Is it
broken because of this?

--
Bill Anderson

"Pluralitas non est ponenda sine neccesitate."
Plurality should not be assumed without neccesity.

 
 
 

Authentication Realm problem

Post by Bill Anderso » Thu, 12 Mar 1998 04:00:00





> )
> )I don't know how you configure the machine you run a webserver on, but on mine,
> )just anyone can not start a webserver and run it on some port. If someone has
> )that kind of access to your machine, you have a bigger problem.

> Uh, shell access?  You think that web servers shouldn't allow shell access?

Ever hear of restricting the shell?

Quote:> )You also missed that he uses the same authentication for both. In order for the
> )rogue to authenticate him, it would need to access the authentication scheme.
> )How would they convince the user to access their page, on their port?

> Left as an exercise for the reader.  Suffice to say that I could get
> probably hundreds of hits to a page if I were to put sufficiently
> interesting stuff about it in this message.
>  -Tom

Of course you could, but if you are trying to duplicate someone else's website,
you will have to do a bit more than talk about it. You would also have to know
what realm name to use to trigger the appropriate response.

--
Bill Anderson

"Pluralitas non est ponenda sine neccesitate."
Plurality should not be assumed without neccesity.

 
 
 

Authentication Realm problem

Post by Marc Slemk » Fri, 13 Mar 1998 04:00:00





>> >I have two web servers running on an HP-UX server:
>> >Apache 1.2.4 on port 80 and Lotus Domino 4.5 on port 81.
>> >I have secure areas on both servers that use the same
>> >authenticaion realm name.

>> >With MSIE 4.01 I am only prompted for a password once
>> >and I'm able to get into both secure areas (this is
>> >exactly what I want).

>> Then MSIE is _HORRIBLY_ broken and you should stop using it ASAP.

>WHy? It is following the procedure as he wants it!

I want the bank to give me 10 million dollars in exchange for my old
snowshoes.

Why would the bank be wrong to do that?  It is following the procedure
as I want it.

Quote:>> >With NS 4.04 I'm prompted for a password twice: once
>> >on the Apache secure area and once on the Domino
>> >secure area.

>How are you implementing the authentication?
>> >I don't want users to have to enter their password twice.
>> >Is there any way to disable that behavior for Netscape
>> >browsers ?

>> Not AFAIK.  It is a serious security issue to allow that.
>No it is not. He specifically stated he wanted users from either realm to have
>access to the other. this is a simple trust relationship. He wants one server
>to trust the other. While it is true that if someone gains access to one, he
>has access to the other, it is also unavoidable in a trust arrangement.

No, the problem is what IE is doing by default.  

Consider any server at all with any user access to it.  Then
someone can typically start their own server on another port.  Then
all they have to do is convince the user to visit a page on that
server, and they can steal the password information without the
user even knowing.  It is even worse in IE if the user saves it to
disk.

If IE provided a way for him to explicitly say that such things
should be trusted, there is no problem with that.  The problem
is that doing it by default is completely broken and a good enough
reason to ban IE from accessing any site of mine that requires
authentication for important information or using an important
login/password pair.

 
 
 

Authentication Realm problem

Post by Marc Slemk » Fri, 13 Mar 1998 04:00:00



Quote:

>> >WHy? It is following the procedure as he wants it!

>> I want the bank to give me 10 million dollars in exchange for my old
>> snowshoes.

>> Why would the bank be wrong to do that?  It is following the procedure
>> as I want it.

>Wow, a nonsensical argument ... imagine that.
>What would be wrong with that? Banks don't buy snowshoes.
>The analogy is not analagous.

It sure is.  You say that it isn't broken if it does what he thinks it
should, while missing the whole point.

Perhaps you aren't familiar with banks here in Canada, but they do buy
snowshoes.

[...]

Quote:

>> Consider any server at all with any user access to it.  Then
>> someone can typically start their own server on another port.  Then
>> all they have to do is convince the user to visit a page on that
>> server, and they can steal the password information without the
>> user even knowing.  It is even worse in IE if the user saves it to
>> disk.

>I don't know how you configure the machine you run a webserver on, but on mine,
>just anyone can not start a webserver and run it on some port. If someone has
>that kind of access to your machine, you have a bigger problem.

If that is the way you want to configure your servers then I am
happy for you.  I have enough experience to be able to tell you
that is _NOT_ the way that most servers are configured, and most people
who think their server is configured that way are wrong.

Quote:>You also missed that he uses the same authentication for both. In order for the
>rogue to authenticate him, it would need to access the authentication scheme.
>How would they convince the user to access their page, on their port? Heck, for
>that matter you could do the same on a completely different machine and
>convince the user to go to your site instead. Then, either the browser will
>remember the authentication, or the user will type it in. Either way you get
>the user/pass pair.

You are really missing the whole point of what is going on.  This
isn't rocket science, and this sort of thing is defined in the standards
regarding what proper behaviour is.

You can't do the same thing with a different server because they have
to enter the auth info _for that site_ because it has a different
name.  Because of MSIE's broken support for realms, the client
will _automatically_ send any cached auth info to a server running on
a different port.  The user doesn't know it is happening.  The user
doesn't enter anything.  The user can't stop it.  Any client worth
anything will not just send off cached passwords to any server
that asks for them.  That is a basic part of HTTP's basic authorization.

(well, IE's broken Windows auth is a different matter but that is outside
of this discussion)

In many environments, the people accessing the secured information will
have something in common and there will be a way to convince them to
go visit an arbitrary URL.

Quote:>> If IE provided a way for him to explicitly say that such things
>> should be trusted, there is no problem with that.  The problem
>> is that doing it by default is completely broken and a good enough
>> reason to ban IE from accessing any site of mine that requires
>> authentication for important information or using an important
>> login/password pair.
>Like I asked him, it depends upon what authentication scheme he is using.

Erm... if you had read what he had written, there is no "choice" of
authentication schemes in this case.  He provided more than enough
information to know what he is using.

Quote:>Where can you configure NS to do such a thing?

Huh?  This sentence makes no sense.

Quote:>The point is, there was not enough detail provided to determine what the cause
>is, plain and simple. To blame a browser by default is a knee-jerk reaction, or
>at least that is what it looks like. Knee-jerk browser wars serve no purpose.
>It *may* be that NS is broken, it may be that the server is broken, it may be
>that MSIE is broken, it may be his authentication scheme is broken.

It may look like a knee-jerk response if you don't have a clue what
is happening or how the web works.  I do.  I am blaming the
client because it is broken, not "by default".
 
 
 

Authentication Realm problem

Post by Holger Rei » Fri, 13 Mar 1998 04:00:00



Quote:(Michael Mongeau) writes:

> >I have two web servers running on an HP-UX server:
> >Apache 1.2.4 on port 80 and Lotus Domino 4.5 on port 81.
> >I have secure areas on both servers that use the same
> >authenticaion realm name.

> >With MSIE 4.01 I am only prompted for a password once
> >and I'm able to get into both secure areas (this is
> >exactly what I want).

> >With NS 4.04 I'm prompted for a password twice: once
> >on the Apache secure area and once on the Domino
> >secure area.

> >I don't want users to have to enter their password twice.
> >Is there any way to disable that behavior for Netscape
> >browsers ?

If you really want to do this you could try to use the
Rewri*gine (mod_rewrite) for transparent proxying
of some pages to port 81. Not tested but it may work.
At least that's what _my_ logic tells me.

Looking to read your success story here ;-)

--
read you later  -  Holger Reif
------------------------------------ Signaturprojekt Deutsche Einheit
TU Ilmenau - Informatik - Telematik                (Verdamp lang her)

Remus.PrakInf.TU-Ilmenau.DE/Reif/    alle 7 Bruecken gehen zu koennen

 
 
 

Authentication Realm problem

Post by Marc Slemk » Fri, 13 Mar 1998 04:00:00


In <35077662.8B47C...@cyberhighway.net> Bill Anderson <ucnt...@cyberhighway.net> writes:

>Marc Slemko wrote:

>> >You also missed that he uses the same authentication for both. In order for the
>> >rogue to authenticate him, it would need to access the authentication scheme.
>> >How would they convince the user to access their page, on their port? Heck, for
>> >that matter you could do the same on a completely different machine and
>> >convince the user to go to your site instead. Then, either the browser will
>> >remember the authentication, or the user will type it in. Either way you get
>> >the user/pass pair.

>> You are really missing the whole point of what is going on.  This
>> isn't rocket science, and this sort of thing is defined in the standards
>> regarding what proper behaviour is.

>> You can't do the same thing with a different server because they have
>> to enter the auth info _for that site_ because it has a different
>> name.  Because of MSIE's broken support for realms, the client
>> will _automatically_ send any cached auth info to a server running on
>> a different port.  The user doesn't know it is happening.  The user
>> doesn't enter anything.  The user can't stop it.  Any client worth
>> anything will not just send off cached passwords to any server
>> that asks for them.  That is a basic part of HTTP's basic authorization.

>No, I fully know what is going on.
>Actually, in IE when you are asked for authentication to a site, it also asks
>if you want it to remeber the user/pass pair, so, no it is not the default.

That has nothing to do with what I am talking about.

>Besides, Michael said "both servers use the same authentication realm" so it is
>not a case of different info for a different server. On some of my servers I

All the realm is is a locally (ie. per server, including port) unique
string that identifies the protected area.  It is not unique
across servers, across different ports on the same host, etc.

>have an authentication scheme similar to the one described, and Netscape
>(4.04)does *not* challenge me when I go from one to the other.

Funny, it does for me.  Just what platform are you running on?

You are telling me that you have two different ports.  For example:

        http://server/restricted/

and

        http://server:8080/restricted/

and if you exit Navigator so that no password information is cached, then
visit the first one, authenticate, then visit the second one you will
gain access to the second one without entering a name or password?

>Thus, depending upon how it was implemented, it is something in his
>configuration that Netscape is not playing properly with. If mine under
>Netscape works as his under IE, then if IE is broken, so is Netscrape. Much to
>my dismay, Netscape's browsers fail to follow the standards as well as
>Microslough's browser does.  Hopefully, once we get the source, we can fix that
>problem.

I think you are misunderstanding the issue here.  Please read what
I write.

- Show quoted text -

>> (well, IE's broken Windows auth is a different matter but that is outside
>> of this discussion)

>> In many environments, the people accessing the secured information will
>> have something in common and there will be a way to convince them to
>> go visit an arbitrary URL.

>> >> If IE provided a way for him to explicitly say that such things
>> >> should be trusted, there is no problem with that.  The problem
>> >> is that doing it by default is completely broken and a good enough
>> >> reason to ban IE from accessing any site of mine that requires
>> >> authentication for important information or using an important
>> >> login/password pair.

>> >Like I asked him, it depends upon what authentication scheme he is using.

>> Erm... if you had read what he had written, there is no "choice" of
>> authentication schemes in this case.  He provided more than enough
>> information to know what he is using.

>> >Where can you configure NS to do such a thing?

>> Huh?  This sentence makes no sense.

>The sentence make splenty of sense, your understanding of it may vary.
>REPHRASE: where do you configure nutscrape to perform the same way?
>After looking around in 4.04, I can't find anything like it.

You can't configure it because it is broken behaviour and should not
be done.  

- Show quoted text -

>> >The point is, there was not enough detail provided to determine what the cause
>> >is, plain and simple. To blame a browser by default is a knee-jerk reaction, or
>> >at least that is what it looks like. Knee-jerk browser wars serve no purpose.
>> >It *may* be that NS is broken, it may be that the server is broken, it may be
>> >that MSIE is broken, it may be his authentication scheme is broken.

>> It may look like a knee-jerk response if you don't have a clue what
>> is happening or how the web works.  I do.  I am blaming the
>> client because it is broken, not "by default".
>I have plenty of knowledge on how the web works. And you said it was broken
>because it did it by default:
>> No, the problem is what IE is doing by default.
>...
>> The problem
>> is that doing it by default is completely broken
>So, by  you did claim it is broken for a default action. In actuality, the
>default is for it to ask you if you want it to 'remember' for you. What could
>be described as broken is that there is no way, AFAIK, for it to be told to
>'forget'. That is broken.

NO!  You are missing the point.  Read what I write instead of
just saying I am wrong.

>Apache has several schemes for authentication of a restricted website, from
>simple .htaccess files and cookies to DBM hashes and SQL queries. It is a
>matter of configuration. I do not know how many different ways a Domino server
>has available to it. Given that, no there was no mention of *which* scheme he
>implemented.

All of those are the exact same from the client's perspective.  Please
go read up on how HTTP works.  There is only one HTTP basic authorization
scheme.  However you happen to get the information about what documents
are restricted and how they are restricted and what users may access
them is irrelevant.

>From the Apache docs:
>> This directive enables or disables the generation of the Expires header for the document >realm in question. (That is, if found in an .htaccess file, for instance, it applies only to >documents generated from that directory.) If set to
>> Off, no Expires header will be generated for any document in the realm (unless overridden at >a lower level, such as an .htaccess file overriding a server config file). If set to On, the >header will be added to served documents
>> according to the criteria defined by the ExpiresByType and ExpiresDefault directives (q.v.).

>> Note that this directive does not guarantee that an Expires header will be generated. If the >criteria aren't met, no header will be sent, and the effect will be as though this directive >wasn't even specified.
>This is from the mod_expires Module, one that is not compiled in by default. By
>default, Apache will send a realm name to the client. This tells the client
>which user/pass pair to send back. MSIE is following the procedure when it
>receives the realm name, and will send it *if it was told to remember it*. (And
>BTW by default it is not chscked to rememebr it, you must check it yes.)

Huh?  That has nothing to do with the issue.  The issue is that IE
is sending the cached information to a _DIFFERENT_ server than the
orignal one.  Sending it to the same server at some later point is fine.
It is sending it to a _DIFFERENT_ server.  It is really very
simple and I'm not sure why you are trying to make it so complex.

The fact that IE can save it to persistent storage simply increases
the time period during which the information can be stolen.

>Just for kicks I implemented a cookie based authentication scheme on two of my
>servers, seperate machines. I had the Site1  authenticate based on a cookie
>sent from Server2.
>Server2 sent the cookie for either site. After authenticating in *either* site,
>I had to remove the cookie from my HD in order for NS4.04 to reauthenticate
>after visiting the other site.  Granted this is a klude, but it demonstrates
>something, namely that by default NS can do this as well. By default, NS will
>accept cookies sent from a different server than the one the web page is on.
>This is a default action I consider a bit less secure than it could be. Is it
>broken because of this?

That is irrelevant because it is simply a matter of your broken
attempt to use cookies.  That is not the issue being discussed
here.  HTTP basic authentication is the issue.  

It appears you don't understand that, which is fine since everyone
has to learn somehow, and are unwilling to learn, which isn't fine.
While I can be a cocky bastard (albeit generally a knowledgeable
cocky bastard), it is normally because I tend to be correct quite
often for some reason and am getting quite tired of someone trying
to bluster their way through a discussion without knowing facts
and trying to confuse the issue by introducing irrelevant issues.

 
 
 

Authentication Realm problem

Post by Bill Anderso » Fri, 13 Mar 1998 04:00:00


Marc Slemko wrote:

> In <35077662.8B47C...@cyberhighway.net> Bill Anderson <ucnt...@cyberhighway.net> writes:

> >Marc Slemko wrote:

> >> >You also missed that he uses the same authentication for both. In order for the
> >> >rogue to authenticate him, it would need to access the authentication scheme.
> >> >How would they convince the user to access their page, on their port? Heck, for
> >> >that matter you could do the same on a completely different machine and
> >> >convince the user to go to your site instead. Then, either the browser will
> >> >remember the authentication, or the user will type it in. Either way you get
> >> >the user/pass pair.

> >> You are really missing the whole point of what is going on.  This
> >> isn't rocket science, and this sort of thing is defined in the standards
> >> regarding what proper behaviour is.

> >> You can't do the same thing with a different server because they have
> >> to enter the auth info _for that site_ because it has a different
> >> name.  Because of MSIE's broken support for realms, the client
> >> will _automatically_ send any cached auth info to a server running on
> >> a different port.  The user doesn't know it is happening.  The user
> >> doesn't enter anything.  The user can't stop it.  Any client worth
> >> anything will not just send off cached passwords to any server
> >> that asks for them.  That is a basic part of HTTP's basic authorization.

> >No, I fully know what is going on.
> >Actually, in IE when you are asked for authentication to a site, it also asks
> >if you want it to remeber the user/pass pair, so, no it is not the default.

> That has nothing to do with what I am talking about.

But it has to do with the original question. And, yes it is quite relevant, see
below for why.
Now, if you are not talking about what the original post was, that statement
may be true ;)

> >Besides, Michael said "both servers use the same authentication realm" so it is
> >not a case of different info for a different server. On some of my servers I

> All the realm is is a locally (ie. per server, including port) unique
> string that identifies the protected area.  It is not unique
> across servers, across different ports on the same host, etc.

But you set it in the configuration. If someone has access to what *you*
configure your realm name (or 'string' if you prefer), they can get your
user/pass pair regardless of browser.

> >have an authentication scheme similar to the one described, and Netscape
> >(4.04)does *not* challenge me when I go from one to the other.

> Funny, it does for me.  Just what platform are you running on?

Linux 2.0.30

> You are telling me that you have two different ports.  For example:

>         http://server/restricted/

> and

>         http://server:8080/restricted/

Yes.

> and if you exit Navigator so that no password information is cached, then
> visit the first one, authenticate, then visit the second one you will
> gain access to the second one without entering a name or password?

No, I did just what was posted originally, I go from one to the other without
quitting Netscape, as it was not stated one was quitting either NS or MSIE.
That would make a difference. I made no assumption that the browsers were
closed before accessing sites.

In my case, I have a link on SiteA that points to SIteB. Both are restricted,
on different ports, and I can go from one to the other seamlessly. that is
desirable, and it works. So far, the only difference I can see that is
different (lacking config details of course) is that both of mine are Apache
servers.

> >Thus, depending upon how it was implemented, it is something in his
> >configuration that Netscape is not playing properly with. If mine under
> >Netscape works as his under IE, then if IE is broken, so is Netscrape. Much to
> >my dismay, Netscape's browsers fail to follow the standards as well as
> >Microslough's browser does.  Hopefully, once we get the source, we can fix that
> >problem.

> I think you are misunderstanding the issue here.  Please read what
> I write.

I could say the same to you, sir.

- Show quoted text -

> >I have plenty of knowledge on how the web works. And you said it was broken
> >because it did it by default:

> >> No, the problem is what IE is doing by default.
> >...
> >> The problem
> >> is that doing it by default is completely broken

> >So, by  you did claim it is broken for a default action. In actuality, the
> >default is for it to ask you if you want it to 'remember' for you. What could
> >be described as broken is that there is no way, AFAIK, for it to be told to
> >'forget'. That is broken.

> NO!  You are missing the point.  Read what I write instead of
> just saying I am wrong.

I QUOTED YOU! YOU specifically said:
---------------------------------------------------------------------
>No, the problem is what IE is doing by default.
...
>The problem is that doing it by default is completely broken

----------------------------------------------------------------------

Now, by English rules, you said the problem is that IE does it by default, and
that it was broken for it to do so. Now, if you wish to claim you never said
that, that is another matter.
Read what you wrote, I did.
BTW that was from a single post...with your name on it ...

- Show quoted text -

> >Just for kicks I implemented a cookie based authentication scheme on two of my
> >servers, seperate machines. I had the Site1  authenticate based on a cookie
> >sent from Server2.
> >Server2 sent the cookie for either site. After authenticating in *either* site,
> >I had to remove the cookie from my HD in order for NS4.04 to reauthenticate
> >after visiting the other site.  Granted this is a klude, but it demonstrates
> >something, namely that by default NS can do this as well. By default, NS will
> >accept cookies sent from a different server than the one the web page is on.
> >This is a default action I consider a bit less secure than it could be. Is it
> >broken because of this?

> That is irrelevant because it is simply a matter of your broken
> attempt to use cookies.  That is not the issue being discussed
> here.  HTTP basic authentication is the issue.

It is not a broken attempt. It is a frequently used technique. It also shows
the original poster yet another method of doing what he wants.

> It appears you don't understand that, which is fine since everyone
> has to learn somehow, and are unwilling to learn, which isn't fine.
> While I can be a cocky bastard (albeit generally a knowledgeable
> cocky bastard), it is normally because I tend to be correct quite
> often for some reason and am getting quite tired of someone trying
> to bluster their way through a discussion without knowing facts
> and trying to confuse the issue by introducing irrelevant issues.

Well, it seems in this case you misunderstood the original post, and therein
lies the bone of contention. Nothing was ever said abouot closing IE or NS and
then trying to access the other site. And since I can do the same thing he
does, and do it in NS, there is a flaw somewhere in your argument that because
MS does it, it is broken and not following the standards, and NS is not. I
leave it to you to find it.

I too can be a stubborn bastard, for the same reasons you can be a cocky
bastard.

Look, the issue is whether or not a given browser is broken because it sends a
response (user/pass) to an authentication request, and whether that action is a
security concern.

Here is how it works. Michael has two servers on the same machine. He wants
users to be able to go from http://site/protected/index.html to
http://site:8080/restricted/index.html without re-authenticating. Now, if the
two of them use the same realm for the challenge. Now, two things can happen
here. Either the browser will remember the proper pair to respond with, or the
user will. In order for this to work, they will need to have the same databse
(file, DBM, whatever) to look at. Alternetively, you could tell either site
that when coming from one secured site, don't challenge again. This would be
similar to (note I did not say exactly like) getting a new page from the same
protected directory.

Now, the security concern of caching the response.
If I am in protected site A, and I want to go to protected site B, I have
already passed the authentication process. So I have the neccessary keys. Now,
if I get up, and someone else sits down at my computer and then continues, you
have a security breach regardless. Remember, without physical security, you
have none. In order to do impede these attempts, I would set an expire,
reauthenticate parameter.
It was claimed that if such exists, one could configure yet another server on
say, port 8082, and get people to go to your rogue server and get user/pass
pairs all day long. Well, if the user is going to the rogue site, thinking he
is going to the normal, secure site, you will get his user/pass regardless of
whether the browser caches it or not. If it does not, he will manually type
them in, and you will get them. Now, unless you have access to the database he
is to authenticate against, he will fail. You still get the goods though. Of
course, if the rogue has access to your security database, you have bigger
problems than a caching browser.

That is my point.

Now, if you can shut down MSIE and still have it not rechallenge, I would say
it is broken (but, OTOH, 4.04 will only make me reauthenticate 3 times before
it does it for me. To get it to stop doing that, I clear memory and disk cache,
very annoying, and very broken IMO). Care to express a bit more detail,
Michael?

--
Bill Anderson
Cyberhighway Internet Services
SYCON
"Pluralitas non est ponenda sine neccesitate."
Plurality should not be assumed without neccesity.

 
 
 

Authentication Realm problem

Post by Chris Gr » Fri, 13 Mar 1998 04:00:00





> > You are telling me that you have two different ports.  For example:

> >         http://server/restricted/

> > and

> >         http://server:8080/restricted/

> Yes.

> > and if you exit Navigator so that no password information is cached, then
> > visit the first one, authenticate, then visit the second one you will
> > gain access to the second one without entering a name or password?

> No, I did just what was posted originally, I go from one to the other without
> quitting Netscape, as it was not stated one was quitting either NS or MSIE.
> That would make a difference. I made no assumption that the browsers were
> closed before accessing sites.

Marc didn't say you should close the browser between visiting A and
visiting B, only that you should close it before starting the whole
experiment, just to make sure that the browser didn't already have
information for one or other realm already cached somewhere.

Really, it's very frustrating trying to follow this discussion when at
least one party is not reading properly and the other is losing his
temper as a result.

Are "fooRealm" on www.foo.com:80 and "fooRealm" on www.foo.com:8080
the same or different realms?  (I think I know the answer to that one.)
Do some browsers behave as if the answer was different, and if so which
ones?  That is what inquiring minds would like to know.

--

  Chris Gray

 
 
 

Authentication Realm problem

Post by Marc Slemk » Fri, 13 Mar 1998 04:00:00


Unless you start saying something instead of just ignoring everything I
say, I don't see much point to continuing this useless thread.

In <35079B6C.A39DC...@cyberhighway.net> Bill Anderson <ucnt...@cyberhighway.net> writes:

[...]

>> >No, I fully know what is going on.
>> >Actually, in IE when you are asked for authentication to a site, it also asks
>> >if you want it to remeber the user/pass pair, so, no it is not the default.

>> That has nothing to do with what I am talking about.

>But it has to do with the original question. And, yes it is quite relevant, see
>below for why.
>Now, if you are not talking about what the original post was, that statement
>may be true ;)
>> >Besides, Michael said "both servers use the same authentication realm" so it is
>> >not a case of different info for a different server. On some of my servers I

>> All the realm is is a locally (ie. per server, including port) unique
>> string that identifies the protected area.  It is not unique
>> across servers, across different ports on the same host, etc.

>But you set it in the configuration. If someone has access to what *you*
>configure your realm name (or 'string' if you prefer), they can get your
>user/pass pair regardless of browser.

Bullshit.

Complete and total bullshit.

To find out what the realm name is, all you have to do is try accessing
a restricted page on the site.  Just having that realm name does _NOT_
let you do anything because the client must not send it to a
different server.  As I have said, they have a _local_ namespace to the
server, not a global one.  Please go read the damn standards and learn
how HTTP works before claming such things.  

What you are saying there is that the client will send the cached
auth info to _ANY_ server that asks for it.  Even IE isn't broken enough
to pull that crap.  Well, not in most versions.

[...]

>> and if you exit Navigator so that no password information is cached, then
>> visit the first one, authenticate, then visit the second one you will
>> gain access to the second one without entering a name or password?

>No, I did just what was posted originally, I go from one to the other without
>quitting Netscape, as it was not stated one was quitting either NS or MSIE.
>That would make a difference. I made no assumption that the browsers were
>closed before accessing sites.

The point in exiting the client first is to be sure you don't have
cached authentication information.  Please do not put words in
my mouth.  Stop and read what I said.

>In my case, I have a link on SiteA that points to SIteB. Both are restricted,
>on different ports, and I can go from one to the other seamlessly. that is
>desirable, and it works. So far, the only difference I can see that is
>different (lacking config details of course) is that both of mine are Apache
>servers.

The server is irrelevant.

>> >Thus, depending upon how it was implemented, it is something in his
>> >configuration that Netscape is not playing properly with. If mine under
>> >Netscape works as his under IE, then if IE is broken, so is Netscrape. Much to
>> >my dismay, Netscape's browsers fail to follow the standards as well as
>> >Microslough's browser does.  Hopefully, once we get the source, we can fix that
>> >problem.

>> I think you are misunderstanding the issue here.  Please read what
>> I write.
>I could say the same to you, sir.

You could but, like most of the rest of what you are saying, you would
be wrong.

- Show quoted text -

>> >I have plenty of knowledge on how the web works. And you said it was broken
>> >because it did it by default:

>> >> No, the problem is what IE is doing by default.
>> >...
>> >> The problem
>> >> is that doing it by default is completely broken

>> >So, by  you did claim it is broken for a default action. In actuality, the
>> >default is for it to ask you if you want it to 'remember' for you. What could
>> >be described as broken is that there is no way, AFAIK, for it to be told to
>> >'forget'. That is broken.

>> NO!  You are missing the point.  Read what I write instead of
>> just saying I am wrong.
>I QUOTED YOU! YOU specifically said:
>---------------------------------------------------------------------
>>No, the problem is what IE is doing by default.
>...
>>The problem is that doing it by default is completely broken
>----------------------------------------------------------------------
>Now, by English rules, you said the problem is that IE does it by default, and
>that it was broken for it to do so. Now, if you wish to claim you never said
>that, that is another matter.
>Read what you wrote, I did.
>BTW that was from a single post...with your name on it ...

Erm... why the hell do you think you can take my words, take them out
of context, and claim they apply to something completely different
than they do?

I am talking about the behaviour of sending the same auth info to
a server on a different port.  The problem is that IE is doing it
by default.  Doing it by default is completely broken.  I have no
idea where you are making up the idea that I am talking about
anything else.

[...]

>It is not a broken attempt. It is a frequently used technique. It also shows
>the original poster yet another method of doing what he wants.

That's nice, but it has nothing to do with the issue!  You are trying to
claim that clients send cached basic authentication information to
different servers by not using basic auth!?!  

>> It appears you don't understand that, which is fine since everyone
>> has to learn somehow, and are unwilling to learn, which isn't fine.
>> While I can be a cocky bastard (albeit generally a knowledgeable
>> cocky bastard), it is normally because I tend to be correct quite
>> often for some reason and am getting quite tired of someone trying
>> to bluster their way through a discussion without knowing facts
>> and trying to confuse the issue by introducing irrelevant issues.
>Well, it seems in this case you misunderstood the original post, and therein
>lies the bone of contention. Nothing was ever said abouot closing IE or NS and
>then trying to access the other site. And since I can do the same thing he

You are right, you are the only one trying to bring in restarting
the client between accessing the sites.  

>does, and do it in NS, there is a flaw somewhere in your argument that because
>MS does it, it is broken and not following the standards, and NS is not. I
>leave it to you to find it.

I'm afraid that I have trouble accepting your results for several reasons.
First, you have demonstrated that you don't have a clue about how
HTTP works in several issues here.  Second, it does not work for me
using Navigator 4.x.  Third, the standards say quite clearly that it
must not work.

>I too can be a stubborn bastard, for the same reasons you can be a cocky
>bastard.

The difference is that you ignore everything I write while I read what
you write and get sick of trying to repeatedly correct you.

>Look, the issue is whether or not a given browser is broken because it sends a
>response (user/pass) to an authentication request, and whether that action is a
>security concern.

[...]

>It was claimed that if such exists, one could configure yet another server on
>say, port 8082, and get people to go to your rogue server and get user/pass
>pairs all day long. Well, if the user is going to the rogue site, thinking he
>is going to the normal, secure site, you will get his user/pass regardless of
>whether the browser caches it or not. If it does not, he will manually type
>them in, and you will get them. Now, unless you have access to the database he
>is to authenticate against, he will fail. You still get the goods though. Of
>course, if the rogue has access to your security database, you have bigger
>problems than a caching browser.
>That is my point.

You are missing the key point.  They do not go to the other page
_thinking_ they are going to the same site.  They know damn well they
are going to a different one.  If their broken client sends the cached
auth information to another server, then that other server will get it
without them knowing, without them having to enter it (or not enter
it because they know they shouldn't have to, in thise case), etc.

You are trying to argue that because someone could go somewhere
and enter their auth info explicitly when anyone asks for it that is
the same thing as their client automatically giving it away without
them knowing or being able to stop it.  That is nonsense.

>Now, if you can shut down MSIE and still have it not rechallenge, I would say
>it is broken (but, OTOH, 4.04 will only make me reauthenticate 3 times before
>it does it for me. To get it to stop doing that, I clear memory and disk cache,
>very annoying, and very broken IMO). Care to express a bit more detail,

As I have said before, that is completely irrelevant.  You can make up
whatever you want, but it has nothing to do with the issue.  

The issue is if MSIE is broken because it treats webservers on different
ports on the same host as having the same namespace for auth
realms.  You start by making wild claims that because doing so does
what someone wants to do, it isn't fair to judge.  Bullshit.  The
standards are there, the security risks are obvious.  Then you go
on to introduce all sorts of irrelevant things (eg. cookies,
saving auth info to persistent storage, etc.) and ignore everything
I write while demonstrating your ignorance of the way HTTP works
(eg. claiming that using different sources of auth info on the server
make it different, claiming that having the realm name will let you get
the auth info, etc).  Sheesh.  

 
 
 

1. Apache-authentication between realms

Hi,
I have two realms A and B to protect two sets of users in two different
directories. The .htaccess file looks something like:
<Files *>
AuthName "A"
AuthType Basic
AuthUserFile /somepath/passwdA.users
require valid-user
</Files>

and a similar .htaccess for AuthName "B" under a different directory.
A user can have different username and passwords for A and B. So the
user logs into A, then navigates to a B page and is prompted for their B
login.

The problem is when they go back to A. It doesn't remember their
password and they have to log in again. Is this a limitation of the
protocol or is there something I can do about this?

Thanks
Tanya

Sent via Deja.com http://www.deja.com/
Before you buy.

2. UMAX Astra 1200S ???

3. combining realm-based authentication with a cgi form

4. Boot concerns with 2 physical hard drives

5. Authentication across realms

6. Problem : Trackball

7. PPP/PAP Login Failure "Invalid Authentication Realm"

8. new processor

9. apache 1.3.12 null realm problem

10. Problem seting up AIX connection for the mac realm

11. Apache Realms Problem - help please

12. Same realm / different servers

13. SSH Remote access Always getting: Disconnected; authentication error (No further authentication methods available).