다음을 통해 공유


Where to put the credentials?

Jon Udell looks a bit into credential management on Windows and gets a bit confused at what he finds. The problem is that there are domain/computer credentials and “Internet” credentials and they overlap a little bit. Domain/computer credentials are credentials that are useful for accessing resources controlled by a domain or computer, usually stuff like file shares and printers, the stuff windows has been using since Windows NT 4 (and earlier). “Internet” credentials are lot more varied. The two interesting types in this case are HTTP level authentication and forms based authentication. Forms based authentication is the type where you fill out a form on a web page and that logs you into a site. It’s the main way that people authenticate on the Internet Web today.

HTTP level authentication happens at a lower layer of the protocol stack then forms based authentication, and is recognizable as a type that results in a popup asking for credentials. In windows pervasive intranets this type of authentication is more common, especially since we can often avoid having to ask the user for their credentials, since they signed into the computer with them. HTTP level authentication supports a couple of different schemes, some of which are more secure then others. The schemes Kerberos and NTLM allow IE to use the domain/windows credentials to satisfy an HTTP auth challenge. This is where the two types of credentials mix a little.

The Credential Management feature that Udell is noticing is tied to the domain/windows notion of credentials (although ironically the main credential it tends to hold is passport’s one). You can be not joined to a domain, add credentials for that domain and have a single sign on type experience when communicating with resources (file shares/databases/websites) that belong to that domain. It’s a pretty handy feature in the windows networking world, especially, I’ve found, with a laptop that I bring to work but is not joined to the work domain, and authentication between machines in my house. The Credential Management APIs (starting in Windows XP) and the Data Protection APIs are a pretty secure way to store credential in windows (starting in Windows 2000), but the Windows XP version of WinInet, the component that handles the HTTP protocol and authentication for IE, only uses them for NTLM/Kerberos challenges. Credentials saved from the basic and digest authentication schemes are stored in an older component called PStore. Pstore doesn’t do as good of a job of protecting credentials as the Data Protection and Credential Management APIs do and as the warning on the API documentation suggests, it is likely to change or go away in Longhorn. In that timeframe WinInet will switch to use the better APIs for those types of credentials. As for Udell’s question #1, which asks why we don’t use the better APIs to store basic and digest authentication, my best guess is that the credential manager wasn’t really made to hold that type of credential well (you can’t input them from the GUI UI).  And to answer question #2, this hasn’t changed in Windows XP SP2.

Even with the planned changes I referred to, you are still are far cry from centralized credential management that includes all web credentials. The credentials in the better store may still not show up in the GUI and forms based authentication is a completely different beast altogether. Sounds like a nice feature to integrate all of those in one gui for a user, and maybe an IE or a security pm will here the call and make it so, especially if the users ask for it.

Comments

  • Anonymous
    July 02, 2004
    Excellent answer to a timely question (at least for me). Centralizing credential management would indeed be optimum but I guess we will have to wait on that.
    Thanks for the info....