Re: How secure is Digest Mode compared to Integrated Authenticatio



Secure authentication protocols like Integrated does not support
DefaultLogonDomain. Why? Because the protocol never passes username/
password to IIS, meaning IIS cannot choose the DefaultLogonDomain to
logon the username.

Editing the metabase, like the Registry, is not meant for most users.
ONe will need at least the following info:
- built-in tools like ADSUTIL.VBS ( http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/iissdk/html/5e7f8cde-4a01-42bd-acaf-
f8f7d091ef7c.asp )
- tools like MBExplorer which makes editing the metabase easy ( http://
www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-
b628-ade629c89499&DisplayLang=en )
- documentation on MSDN detailing what every property means ( http://
msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/
bb9c0d25-d003-4ddd-8adb-8662de0a24ee.asp )

I believe making users specify username@xxxxxxxxxx is pretty
reasonable, especially if it also corresponds to their email address.
I believe that getting used to specifying one's domain is critical --
how else do you distinguish between all the Davids in the world if
they all got used to logging in with their name on all the systems in
the world? We live in a connected, global society.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Jan 30, 5:08 am, K12-Jammer <K12Jam...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
I agree that Integrated is the way to go. I believe that I could do this
using the metabase property DefaultLogonDomain but haven't been able to
figure out how to actually do that. Documentation on editing the metabase
seems hard to find and everytime I bring it up somewhere people ask about
other things that don't seem relevant.

So for now by boss is willing to go the route of specifying the domain
manually by using the usern...@xxxxxxxxxxxxxx method of user identification.
Guess that isn't so bad. People will get used to it.

Have a great day.

--
Jim R



"David Wang" wrote:
Well, if your concern is to not lose user password, Digest can be
sufficient for that since it never passes the password over the
network in any form.

However, Digest is still weak against attacks like man-in-the-middle,
replay, snooping, delegation, spoofing. In particular, a snooping/
replay attack can be just as damaging.

It is unfortunate that the more secure authentication protocols
require more investment in security setup/infrastructure to utilize,
but that is the cost of establishing a chain of trust for machines,
which humans implicitly create on their own.

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Jan 29, 7:53 am, K12-Jammer <K12Jam...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
David,

Thank you for your summary statement and for your reference to the w3.org
document which delineates the weaknesses of Digest mode. I will surely read
that document.

I think that your summary statement, however, will dictate that I not use
Digest mode.

In my situation, the actual secure documents are much less valuable than
password integrity is. It won't ruin my organization if an outsider sees one
of these "secure" documents but I don't want them to be able to get my users
passwords.

Thanks for being so knowledgeable on this stuff.
--
Jim R

"David Wang" wrote:
Why don't you have two websites pointing to the same content on the
webserver. Both websites are identical in behavior except one is facing
Internet and other is Intranet. Configure Integrated authentication on
the Intranet facing website, and debate over the properly setting of
the Internet-facing website.

In other words, is your requirement that:
a. users must authenticate with the same protocol over Intranet and
Internet OR
b users must authenticate with *some* protocol from the Intranet and
Internet.

These are two different types of requirements. One is a requirement for
authenticated users. The other is a requirement for a certain
authentication protocol.

FYI: All authentication protocols have their advantages and
disadvantages, and "one size fits all" approach rarely fits for any
given protocol. If there was a protocol that works in all cases, why
would multiple protocols remain???

For example, the spec for Digest Authentication makes clear its
plus/minus in relation to Basic authentication -- in particular, read
section 3 on bottom of page 12 through 15 for weakness in Digest.
http://www.w3.org/Protocols/rfc2069/rfc2069

Short summary:
- Digest is barely better than Basic in that it doesn't pass the
username:password in cleartext but rather a hash of the
username:password in cleartext. It still suffers all other security
flaws of Basic (man-in-the-middle, replay, snooping, delegation,
spoofing).
- Integrated authentication auto-negotiates between two protocols, NTLM
and Kerberos. Both protocols have strong defense against
man-in-the-middle, replay, snooping, and spoofing attacks, and Kerberos
can support delegation properly while NTLM cannot (hence NTLM has the
well-known double-hop failure).

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Jan 25, 12:26 pm, K12-Jammer <K12Jam...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
While researching authentication on IIS I saw there were 3 options for
authenication: Basic, Digest and Integrated Authentication.

My requirements are that this works both on the Intranet and Internet. I
would also prefer that the user enter only his short username and password
(eg bsmith) rather than the long username and password (eg.
bsm...@xxxxxxxxxxxx). So, I am limited to use of Basic and Digest.

From a security perspective I know that Basic is not acceptable because it
passes passwords in clear text. I will give it a security rating of 1 and
wont use it.

Integrated Authentication I will give a security rating of 9 but can't use it.

What relative rating would you say that Digest is? What are the dangers of
digest from a security perspective.

Thanks for your opinions and/or knowledge.

Jim

1. Basic

--
Jim R- Hide quoted text -- Show quoted text -- Hide quoted text -

- Show quoted text -


.



Relevant Pages

  • Re: How secure is Digest Mode compared to Integrated Authenticatio
    ... document which delineates the weaknesses of Digest mode. ... Configure Integrated authentication on ... b users must authenticate with *some* protocol from the Intranet and ... From a security perspective I know that Basic is not acceptable because it ...
    (microsoft.public.inetserver.iis.security)
  • Re: How secure is Digest Mode compared to Integrated Authenticatio
    ... However, Digest is still weak against attacks like man-in-the-middle, ... It is unfortunate that the more secure authentication protocols ... Internet and other is Intranet. ... b users must authenticate with *some* protocol from the Intranet and ...
    (microsoft.public.inetserver.iis.security)
  • Re: How secure is Digest Mode compared to Integrated Authentication
    ... Internet and other is Intranet. ... Configure Integrated authentication on ... b users must authenticate with *some* protocol from the Intranet and ... section 3 on bottom of page 12 through 15 for weakness in Digest. ...
    (microsoft.public.inetserver.iis.security)
  • RE: Passwords with Lan Manager (LM) under Windows
    ... A device's security associations are contained in its Security Association Database ... Internet Protocol Security (IPSec) provides application-transparent encryption services for IP network traffic as well as other network access protections for the Windows 2000 operating system. ... As for "article you reference does indeed use the phrase "IPSec Authentication," but as any who reads it ...
    (Pen-Test)
  • Re: [fw-wiz] Proxies, opensource and the general market: whats wrong with us?
    ... At the moment I am trying to offload non protocol-related http checks to ... authsrv is the part that required several ... Multiple groups per user are allowed, authentication ... I decided to document that and make it a part of protocol specification. ...
    (Firewall-Wizards)