The Definitive Guide To Website Authentication

From the first answer<p>&#62; The only (currently practical) way to protect against login interception (packet sniffing) during login is by using a certificate-based encryption scheme (e.g. SSL) or a proven &#38; tested challenge-response scheme (e.g. the Diffie-Hellman-based SRP).<p>I'm no security expert but if you take into account man in the middle attack where the attacker can actually change the page/javascript you're not safe even with DH. Attacker can just drop all your fancy code and send the password in the clear and intercept it later...

I'm just a few paragraphs in and already this definitive guide is getting you flunked in audits. It's not a <i>question</i> whether you should disable autocompletes on password fields; it's an audit point.<p>(It is, as an aside, also a terrible idea to ask users to store their passwords in browser autocomplete dictionaries.)

I'd be interested in hearing how other people on HN implement persistent logins. I'm currently working on it, following "Charles Miller's Persistent Login Cookie Best Practice"[1], but hearing some other opinions/techniques would be great.<p>[1] <a href="http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/" rel="nofollow">http://fishbowl.pastiche.org/2004/01/19/persistent_login_coo...</a>

It would be nice to see something about federated security using something like SAML - if you are a large enterprise and you have multiple SaaS providers you really want external services to be using your own internal directory (which is likely to be MS Active Directory) for authentication.<p>Actually, it would be pretty nice if someone could offer this as a easy to use service for people building enterprise oriented SaaS apps. Is anyone already doing this?

I posted this on the StackOverflow page. I'll put it here too. Apologies if it is too long.<p>I think BrowserID[1] (or perhaps more precisely, the Verified Email Protocol[2]), the recent effort by Mozilla's Identity Team[3], deserves a mention here. I'll summarize it this way:<p>1. Mozilla is a nonprofit with values[4] that align well with finding good solutions to this problem.<p>2. The reality today is that most websites use form-based authentication<p>3. Form-based authentication has a big drawback, which is increased risk of phishing. Users are asked to enter sensitive information into an area controlled by a remote entity, rather than an area controlled by their User Agent (browser).<p>4. Since browsers are implicitly trusted (the whole idea of a User Agent is to act on behalf of the User), they can help improve this situation.<p>5. The primary force holding back progress here is deployment deadlock[5]. Solutions must be decomposed into steps which provide some incremental benefit on their own.<p>6. The simplest decentralized method for expressing identity that is built into the internet infrastructure is the domain name.<p>7. As a second level of expressing identity, each domain manages its own set of accounts.<p>8. The form account@domain is concise and supported by a wide range of protocols and uri schemes. Such an identifier is, of course, most universally recognized as an email address.<p>9. Email providers are already the de-facto primary identity providers online. Current password reset flows usually let you take control of an account if you can prove that you control that account's associated email address.<p>10. The Verified Email Protocol was proposed to provide a secure method, based on public key cryptography, for streamlining the process of proving to domain B that you have an account on domain A.<p>11. For browsers that don't support the Verified Email Protocol (currently all of them), mozilla provides a shim which implements the protocol in client-side javascript.<p>12. For email services that don't support the Verified Email Protocol, the protocol allows third parties to act as a trusted intermediary, asserting that they've verified a user's ownership of an account. It is not desirable to have a large number of such third parties; this capability is intended only to allow an upgrade path, and it is much preferred that email services provide these assertions themselves.<p>13. Mozilla offers their own service to act as such a trusted third party. Service Providers (ie Relying Parties) implementing the Verified Email Protocol may choose to trust Mozilla's assertions or not. Mozilla's service verifies users' account ownership using the conventional means of sending an email with a confirmation link.<p>14. Service Providers may, of course, offer this protocol as an option in addition to any other method(s) of authentication they might wish to offer.<p>15. A big user interface benefit being sought here is the "identity selector". When a user visits a site and chooses to authenticate, their browser shows them a selection of email addresses ("personal", "work", "political activism" etc) they may use to identify themselves to the site.<p>16. Another big user interface benefit being sought as part of this effort is helping the browser know more about the user's session[6] -- who they're signed in as currently, primarily -- so it may display that in the browser chrome.<p>17. Because of the distributed nature of this system, it avoids lock-in to major sites like facebook, twitter, google etc. Any individual can own their own domain and therefore act as their own identity provider.<p>This is not strictly "form based authentication for websites". But it is an effort to transition from the current norm of form based authentication to something more secure: browser supported authentication.<p><pre><code> [1]: https://browserid.org/ [2]: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest [3]: http://identity.mozilla.com/ [4]: http://www.mozilla.org/about/manifesto.en.html [5]: http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_10.pdf [6]: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-Session</code></pre>

You should look at two-factor authentication solutions to solve many of these issues. For example <a href="https://www.mepin.com" rel="nofollow">https://www.mepin.com</a> is a two-factor authentication service free to integrate and use for the websites. It supports standard OpenID interfaces, so no proprietary integrations needed.

What about "Keep me logged in for x days"... any opinions on it? It certainly has its own fair share of security issues, if implemented incorrectly. Given that more sites now allow logins via FB, G+, Twitter and what have you, is this still relevant?

This is an admirable hack of SO's intended use. It would be great if there was a site that actually afforded this particular use case. Wikis are too open-ended. Perhaps something in the middle.

There is also authentication using RSA keypairs, ALA glbse.com, they require all requests to the server to be signed by the private key (there is a JavaScript and Python client).

8 out of the 12 issues posed are about passwords. Clearly we need a better alternative there that could be incorporated into the browser. I think mozilla's browserid is a very pragmatic idea that deserves some attention.