StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You have two distinct problems: authenticating a registered user and provisioning a new user account.</p> <h2>Authenticating the user</h2> <p>This is the easy part. You have several choices:</p> <ul> <li>HTTP authentication (<a href="http://en.wikipedia.org/wiki/Basic_access_authentication" rel="nofollow noreferrer">basic</a> or <a href="http://en.wikipedia.org/wiki/Digest_access_authentication" rel="nofollow noreferrer">digest</a>). Basic is a joke, so it really leaves only Digest as a serious alternative.</li> <li>HTTP NTLM/Kerberos authentication (aka. Windows Integrated Authentication) is bulletproof, provided your clients are joined to the NT domain (unlikely).</li> <li>SSL/TLS Mutual authentication</li> <li>HTTP 'Forms' authentication. Not worth mentioning.</li> <li>Basic or Forms authentication over a secure channel (<strong>HTTPS</strong>)</li> </ul> <p>So the real options left are Digest, SSL mutual or Basic/Forms over encrypted channel.</p> <p><strong>HTTP Digest</strong> is very easy to implement on the client side, simple add the user name/password to the <a href="http://msdn.microsoft.com/en-us/library/system.net.credentialcache.aspx" rel="nofollow noreferrer"><code>CredentialCache</code></a> used with the <a href="http://msdn.microsoft.com/en-us/library/system.net.webrequest.aspx" rel="nofollow noreferrer"><code>WebRequest</code></a> and you're done. Reuse the CredentialCache instance between calls to benefit from pre-authentication. Unfortunately things are not as rosy on the server side: Digest authentication is supported properly only when integrated with AD, see <a href="http://technet.microsoft.com/en-us/library/cc754104%28WS.10%29.aspx" rel="nofollow noreferrer">Configure Digest Authentication</a>.</p> <p><strong>SSL/TLS Mutual authentication</strong> is supported by both client and server, but again, the server side really supports it only when integrated with AD, not a real option (see <a href="http://technet.microsoft.com/en-us/library/cc732996%28WS.10%29.aspx" rel="nofollow noreferrer">Configure Client Certificate Mapping Authentication</a>).</p> <p>This is why I believe the only realistic options for an application that is not intended to be used over VPN in a corporate environment is to use Basic or Forms authentication over a secure channel (HTTPS). For Basic you must present the password din clear text, and same for Forms (in its common, unmodified incarnation), so the client must have access to the clear text password, and same goes for the server. One way hashing will not work, you need proper encryption secure storage. </p> <p>Now is true that for you can 'enhance' the forms authentication scheme to do pretty complicated stuff, basically designing a Digest equivalent in the HTTP form exchange, but I believe such is beyond the scope of this discussion. And if you venture down that path, you should <em>really</em> know what you're doing, or use a well established solution (I'm not aware of any).</p> <p><strong>Storing the Password:</strong> For Basic/Digest/Forms the client does not store the password, since the password is actually provided by the user. At most, the password may be saved to avoid re-typing, and this should be done like any user specific secret stored on the client, encrypted with DPAPI via the <a href="http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx" rel="nofollow noreferrer">ProtectedData</a> class. On the server side, if a user table is used then the passwords should be stored as a one way hash. For Basic and Form any hash scheme will work (preferable salted). But for Digest the hash <em>must</em> be the HA1 hash from the digest scheme: <code>md5(username:realm:password)</code> so that the server can finish the authentication handshake. Although doing this requires some pretty invasive rewriting of the out-of-the-box membership providers that come with ASP, is it still my recommended way.</p> <h2>Provisioning the user</h2> <p>This is a bit trickier because it involves establishing the initial trust. If you go over all the schemes mentioned above, you'll see that none but Basic/Forms over HTTPS can do this in-band: any other solution requires an initial deployment of the user account set up by out-of-bands means (where out-of-bands refer to the scheme used). Mutual SSL requires certificate provisioning, NTLM/Kerberos requires AD user provisioning, Digest requires provisioning of user password. For Basic/Forms and Digest there is a convenient 'out-of-band' solution: a secure HTTPS channel on which an account creation form is submitted. For SSL/TLS certificates and for AD things are more complicated.</p> <h2>OpenID/OAuth</h2> <p>A completely different approach is to delegate authentication. Use OpenID with providers like Google or Yahoo and OAuth with providers like Facebook or Twitter. This works phenomenally well with web apps (StackOverflow itself uses such a scheme, as you may have noticed see <a href="http://blog.stackoverflow.com/2010/04/openid-one-year-later/">OpenID, One Year Later</a>). There are libraries and integration providers that really make this as easy as 3 clicks and one line of code, like <a href="http://www.janrain.com/products/engage" rel="nofollow noreferrer">JanRain</a>.</p> <p>The only problem with OpenID and OpenAuth is that is an <em>interactive</em> scheme. It only works if the user is actively participating in the login/authentication process and thus eliminate all the automated solutions. If your application is doing any sort of background operations (eg. running as a service) or if is using an application ID to 'phone-home' without user involvement then OpenID/OAuth do not work.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload