Credentials rejected on POST

This is well documented.

Windows Authentication is suitable for Intranet scenarios since it is
connection-based authentication. If you pass through a proxy server or
router of some sort that doesn't respect this (frequent on the Internet), it
will cause you problems.

My suspicion is that the POST operation made the server think you closed
your originally authenticated connection somehow (recall you've got a proxy
in there, depending on your ISP, mucking with your connection status as
well).

Simplest solution to setup is Basic over SSL. Other solutions require a bit
more setup (using Kerberos, Digest, or Passport).

Think of it this way --

Windows Authentication uses a challenge which proves the user knew their
password without transmitting it in clear text. Since this challenge passes
over the wire in clear text, what prevents another user from simply sending
a request with that same clear-text challenge and masquerade as you (i.e.
traditional replay attack)??? NTLM solves that by locking the
authentication to the connection that correctly answered the challenge... so
another user, with the same challenge, cannot masquerade as you on another
connection.

And the reason that basic needs to be over SSL? Because Basic auth just
passes a base64 encoding "username:password" over the wire, and it decorates
every request that needs authentication. It has no provisions to avoid a
replay attack (you just send a request with that Authorization string, and
you masquerade as that user -- which is beautiful for server delegation but
also bad for security), so you have to solve that weakness by encrypting its
communications.

What about Kerberos, which doesn't need SSL, doesn't transmit the password
in cleartext, and is not connection-bound? Without going into too much
detail, Kerberos basically makes the user answer a one-way hash with their
password such that it proves to the KDC that the user knew the password
(without transmitting the password over the network), who then issues the
user a "ticket" that proves this KDC validated the user. Thereafter, the
ticket is used for authentication to all participating servers (all in clear
text). To prevent spoofing, the IP address of the user is kept in the
ticket (this is why Kerberos doesn't work across NAT -- because your client
PC's internal IP is in the Kerberos ticket [part of that "details" I skipped
over], and the server only see the NAT's IP [by-design, since that's part of
what NAT does], which is different). Since IP Spoofing is doable, to
prevent replay attack, a "freshness" timestamp is also kept in the ticket
[part of that "details" I skipped over], and servers reject stale tickets
(so theoretically, there is a window of attack where an attacker can
IP-spoof AFTER the original user has logged off but BEFORE the "freshness"
expires to pretend to be a user, but this is addressed by keeping a really
short "freshness" window, amongst other strategies). But the big "problem"
with Kerberos??? Setup - you need a domain, domain controller, and Active
Directory. All servers that agree to accept a Kerberos ticket must trust
the KDC that issues the ticket (else, someone can setup their own rogue KDC
that issues bogus tickets and get access to resources). Windows establishes
this trust by joining the machine to a domain (since domain members trust
the domain controller, who conveniently is also the KDC).


I hope you understand that "entering credentials" is barely the tip of the
iceberg when it comes to security. Most people do NOT realize how difficult
it is to correctly authenticate, authorize, and trust a given identity, nor
the reason why the existing protocols exist -- each has their pros and cons.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Iain" <idownsXXXX.TakeThisOut@dircon.co.uk> wrote in message
news:OQN3CsFuDHA.3436@tk2msftngp13.phx.gbl...
To my considerable embarrasement, I have no sooner posted this than found an
answer.

It appears that if I disable Integrated Windows Authentication the problem
goes away.

I imagine that it is to do with me being logged in locally as a different
user than I need to log into remotely (if you follow me).

But I'm not clear why the POST should act differently, and I'd much prefer
to use Windows Authentication for security and all that.

Can anyone point further?

Iain
"Iain" <idownsXXXX.TakeThisOut@dircon.co.uk> wrote in message
news:Oop0uoFuDHA.640@tk2msftngp13.phx.gbl...
 > I've a web site (asp with WebClasses) which is secured (the virtual
 > directory has restricted access, the anon user is turned off).
 >
 > When I enter the site and provide my credentials, everything works fine.
 >
 > the first point I hit a submit button (that is do a POST rather than a
GET)
 > my credentials are rejected and the logon box pops up.
 >
 > 3 strikes and I'm out.
 >
 > There's a few things that bug me about this. Firstly, it only seems to
 > happen to me. That is other users have no trouble getting in. I also
find
 > that if I dial in (through a different ISP) then this does not seem to
 > happen.
 >
 > Secondly, I have recently moved the site to brand new servers (2003 vs
200)
 > and I'm oeprating from newly built systems (XP and 2003).
 >
 > Thirdly, I'm resonably convinced that at least for a brief time this was
 > working.
 >
 > I believe I'm doing something incredibly stupid. But clearly, I'm too
 > stupid to see what!
 >
 > Has anyone come across somethign like this?
 >
 > Iain
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Credentials rejected on POST 

Thank you for a very informative answer David.

Clearly SSL is an option with Basic, but the effort (and cost) of a cert is
not worth while (nor the effort of issueing a self signed cert and telling
the users not to worry).

What I find odd about this is that wehn I do the POST I get asked for my
password again and again and again - and then it strikes out.

if I look at the logs then I find the GET operation contains my User name,
but the POST operations do not - as if something has stripped it out on the
way to the server.

I have tried to report this to my ISP (I don't think this should happen),
but with very little effect. COuld you point me to a KB article or some
other reference which will persuade them to reconfigure their system.

They should know better; they are one of the UK's biggest ...

thanks again

Iain
 >> Stay informed about: Credentials rejected on POST 

You note that this happens when dialing in using certain ISPs. I have also
noted that Windows Authentication can be broken depending on ISP networking
configuration. I should think that is clear enough of what you need to ask
for and from whom.

To go further, you are going to have to give me exactly what type of 401
error you get for the POST operation. I need to distinguish between 401.1 ,
401.2 , 401.3 , 401.4 , and 401.5 coming back from IIS ... because they all
end up causing IE to pop up th. login dialog, and after three tries, IE will
strike out. The exact 401 type will indicate what you next step needs to
be.

IE is only going to show you the last 401 response it got (after you strike
out). We also need to know the intervening ones that are causing each login
dialog box popup, and the easy way to get them is to do a network sniff of
all requests coming to/from your client PC.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Iain" <idownsXXXX RemoveThis @dircon.co.uk> wrote in message
news:eSMGuYYuDHA.3140@TK2MSFTNGP11.phx.gbl...
Thank you for a very informative answer David.

Clearly SSL is an option with Basic, but the effort (and cost) of a cert is
not worth while (nor the effort of issueing a self signed cert and telling
the users not to worry).

What I find odd about this is that wehn I do the POST I get asked for my
password again and again and again - and then it strikes out.

if I look at the logs then I find the GET operation contains my User name,
but the POST operations do not - as if something has stripped it out on the
way to the server.

I have tried to report this to my ISP (I don't think this should happen),
but with very little effect. COuld you point me to a KB article or some
other reference which will persuade them to reconfigure their system.

They should know better; they are one of the UK's biggest ...

thanks again

Iain
 >> Stay informed about: Credentials rejected on POST